What is penetration testing?
Penetration testing is a human-led, time-boxed security assessment that finds exploitable vulnerabilities (not just vulnerabilities that exist) by actually exploiting them in contained environments. A scanner tells you a known CVE is present. A pen tester tells you whether CVE chains with a misconfigured IAM role to reach your production database.
Standard penetration testing engagements unfold across a consistent structural timeline. It starts with a scoping call where you define the rules of engagement (ROE), the document specifying exactly what testers can and can’t touch. That scoping decision determines everything downstream: reconnaissance, exploitation attempts, and the final report.
The deliverable is a list of vulnerabilities found in all pre-stated, in-scope assets, organized by exploitability, scored by Common Vulnerability Scoring System (CVSS), and accompanied by clear remediation steps.
Vulnerability Management Buyer's Guide
This guide helps your security and dev teams finally start speaking the same language while giving you everything you need to objectively choose or replace your VM solution.
What is red teaming?
During a red teaming simulation, ethical hackers evaluate your operational defenses by emulating real-world adversary tactics and techniques. Red teaming starts from assume-breach, the premise that an attacker already has a foothold in your environment. So the question shifts from "Can they get in?" to “What would they do next?” “How far can they move?” and “Would our controls detect and stop them?”
That starting premise separates a red team engagement from even the most thorough pen test and changes the methodology required. For example, a red team begins from an assumed foothold, which in a cloud-native environment might be a leaked CI/CD deploy token, a compromised service account, or an over-permissioned IAM role. The enterprise defines a specific objective before the engagement begins. This might be reaching the billing database, demonstrating lateral movement to a production Kubernetes cluster, or exfiltrating a service account credential set.
The red team then works toward that objective while executing tactics, techniques, and procedures (TTPs). These are the specific methods adversaries use, mapped to the MITRE ATT&CK framework. This knowledge base of adversary behaviors maintained by MITRE lets both offensive and defensive teams speak the same classification language. This approach is called adversary emulation, structuring red team behavior to mirror a specific threat actor's known TTPs.
As the red team progresses, enterprises measure whether detection fires at each stage. That measurement is the real product. So it’s best that the blue team is kept unaware of the exercise, leaving them to detect it themselves. The deliverable is a detection gap analysis: what alerted, what didn't, dwell time from first foothold to first alert, and an attack-chain narrative showing exactly how far the team moved before anyone noticed.
Penetration testing vs. red teaming: The differences
There are five core areas of divergence between pen testing and red teaming: objective, timeline, price, team knowledge state, and deliverable format. To understand these differences, think of your cloud security testing program as a software testing pyramid.
Automated vulnerability scanning is your unit test. It’s fast, broad, and great at finding known issues.
A penetration test is your integration test. Here, a human pushes on the system to find what actually breaks in combination.
A red team engagement is chaos engineering. You hand a skilled adversary a realistic foothold and measure whether your detection and response actually fires before they reach the crown jewel.
These all share the same goal at the top, but very different questions at each layer. Now let’s consider where these differences manifest:
| Dimension | Penetration testing | Red teaming |
|---|---|---|
| Primary objective | Uncover the maximum number of exploitable weaknesses | Achieve a specific objective while testing whether detections fire |
| Scope | Breadth-first across defined attack surface | Objective-first with an assume-breach premise |
| Timeline | 1-2 weeks | 4-12 weeks |
| Team knowledge state | Blue team typically knows the engagement is happening | Blue team operates blind with their response measured, simulating real attacker conditions |
| Deliverable | Exploitable vulnerability list with CVSS scores and remediation guidance | Detection gap analysis, dwell time measurement, and attack- chain narrative |
What cloud attack surfaces does network-centric scope miss?
In standard pen testing, in-scope assets are listed using network-centric ROE templates like IP ranges, domains, and application endpoints. But cloud environments introduce an entirely different attack surface. This means organizations must explicitly name cloud assets like IAM configurations, CI/CD pipeline environments, and IaC state repositories. Otherwise testers could default to their usual network-centric templates and miss critical cloud attack paths.
One example that shows why this matters is IAM role chaining. An attacker may never need to compromise a server if a dev-role holding iam:PassRole plus lambda:CreateFunction can pass a prod-admin-role to a new Lambda function. This grants the Lambda function elevated permissions. These let the attacker, riding the compromised dev role, access sensitive resources (e.g, S3, RDS, or Secrets Manager), without directly assuming the privileged role. This entire privilege escalation path exists within the cloud control plane and would rarely appear in a traditional network-focused testing scope.
Toxic privilege combinations (a set of permissions dangerous in combination even when each looks acceptable alone) follow the same logic. iam:PassRole paired with any service invocation permission is the common case, but the pattern repeats across cloud providers wherever permissions accumulate through copy-paste provisioning.
CI/CD pipelines are another major cloud attack surface that traditional network-focused scoping often misses. The compromise of the tj-actions/changed-files GitHub Action shows why: Malicious code exposed CI runner memory through workflow logs, potentially leaking AWS credentials across more than 23,000 repositories.
A scope limited to application infrastructure would likely have missed the pipeline entirely. The same applies to infrastructure-as-code (IaC) state files. These often contain detailed infrastructure configurations and, in some cases, plaintext credentials that can provide attackers with a direct path to sensitive cloud resources.
These are the actual attack surfaces enterprises should be testing for in the cloud. Traditional network-centric templates miss these paths, whereas cloud-native penetration testing maps these relationships to give security teams full visibility.
When should you use pen testing vs. red teaming?
Two distinct questions guide this decision: your internal detection maturity and your specific compliance frameworks.
The detection maturity test: Are you ready for red teaming?
The detection maturity question matters because red teaming stress-tests active detection and response capabilities by emulating real adversary behaviors. Conversely, penetration testing focuses on collaborating with your blue team to locate and remediate structural weaknesses before attackers exploit them.
This is why red teaming particularly requires a tuned SIEM with mapped detection rules before it produces a useful signal. A "tuned SIEM" here means detection rules map to MITRE ATT&CK tactics with verified data sources feeding them, not dead rules firing on missing log sources. The test is whether red team activity would produce alerts your team can actually investigate. Without that foundational setup, a blind simulation cannot yield actionable security data.
Pen testing uncovers exploitable risks at any organizational stage, while red teaming delivers clear insights when your security operations center (SOC) reaches a higher level of maturity. A clean framework for measuring your maturity level is:
Level 1 - Reactive: Security operations show a days-to-weeks mean time to detect (MTTD) and rely on ad-hoc alerts.
Level 2 - Operational: Teams detect anomalies within hours, follow documented processes, and maintain consistent log coverage. This state serves as the baseline where offensive simulation outcomes become actionable.
Level 3 - Adversary-ready: Detection systems trigger within minutes, backed by validated detection coverage, active threat hunting, tested incident response (IR) playbooks, and measurable containment performance.
What do compliance mandates actually require?
While compliance frameworks don’t explicitly mandate blind red team simulations, several frameworks drive pen testing onto your security calendar whether teams plan for it or not:
PCI DSS 4.0 Requirement 11.4: Calls for annual internal and external penetration testing with explicit methodology requirements. Fully enforced since March 2025.
SOC 2: Doesn’t name "penetration testing" in the AICPA Trust Services Criteria, but auditors expect it as evidence for CC4.1 and CC7.1.
HIPAA: The current HIPAA Security Rule requires periodic technical evaluations without naming pen testing explicitly. But the 2025 HHS/OCR NPRM will mandate annual pen testing for environments handling ePHI once it’s finalized.
Compliance drives pen testing cadence; detection maturity drives the decision to add red teaming.
Watch 12-min demo
Learn how Wiz connects the dots across your entire cloud, enabling teams to own the vulnerability management life cycle together through a single, unified lens.
How to scope and measure each exercise
Pen testing and red teaming exercises are scoped and evaluated differently. For pen testing, scoping focuses on spread, the number of exploitable vulnerabilities across the stack. For red teaming, scoping is designed to test attack paths to specific assets. Still, when it comes to scoping, one thing remains constant: Modern exercises must cover cloud assets.
Writing rules of engagement that cover cloud
Four additions make a cloud-native ROE document cover the actual risk surface:
IAM role ARNs or naming patterns: Explicitly named as in-scope
CI/CD pipeline environments: Named by pipeline name, not implied by application scope
Secrets management services: Named explicitly; Secrets Manager, Vault, or Parameter Store
IaC state storage locations: The S3 bucket or backend where Terraform state lives
Cloud provider authorization is a separate requirement. AWS, GCP, and Azure each have formal penetration test authorization procedures that must be completed before testing cloud infrastructure. Start the authorization process early.
How to measure ROE success
Again, the criteria differ when it comes to assessing whether the exercise worked or not.
Pen testing
For pen testing, vulnerability density alone doesn’t tell you much about the success rate. What does is the reduction in known exposure over time. This involves assessing:
Exploit volume: The number of exploitable or successfully exploited weaknesses found
Attack paths and toxic combinations identified: The number of multi-step attack chains where individually low- or medium-risk weaknesses can be combined to achieve high-impact attacks
Risk categorization: The percentage of Critical, High, Medium, and Low vulnerabilities discovered
Remediation: The volume of exploitable risks that are immediately fixed and how quickly
Red teaming
Evaluation success depends on your tracking performance rather than whether simulation teams reach a target. Security leaders measure this performance through a specific detection scorecard:
Detection rate: Measure this core metric using the formula (techniques executed that generated an alert / total techniques executed) x 100. A 40% detection rate means 60% of red team activity was invisible to your blue team. This number tells you more about your security posture than any individual finding.
Dwell time: Track this interval from the initial foothold to the first generated alert to determine your mean time to detect (MTTD) and mean time to contain (MTTC). This timeline gives you a realistic view of real-world operational response speeds.
For context, CISA red team assessments of federal organizations document real environments failing to detect red team activity for days to weeks. Measuring whether containment happens in days, hours, or minutes allows security leaders to benchmark defense performance against advanced threat actors.Playbook adherence: Evaluate how consistently your incident response (IR) teams execute documented protocols during a simulated live-fire incident.
Alert fidelity: Calculate the true positive rate of your monitoring platforms during the exercise. High volumes of false positives during a simulation indicate that your security information and event management (SIEM) rules require tuning to prevent alert fatigue.
Enterprises looking to get value from red teaming must require a detection gap analysis as a deliverable component, rather than a vulnerability list alone. That single deliverable shifts the engagement from measuring "what did testers find" to "what would your team have seen and done if it were an actual attacker.” This is also where less mature teams gravitate towards purple teaming to systematically close detection and containment gaps.
What is purple teaming?
Purple teaming is red and blue teams working simultaneously. Red executes a technique; blue observes whether the detection fires. The table below compares pen testing, red teaming, and purple teaming.
| Dimension | Penetration testing | Red teaming | Purple teaming |
|---|---|---|---|
| Primary objective | Uncover maximum exploitable weaknesses | Achieve a specific objective and test if detections fire | Collaborate to execute techniques and tune detections in real time |
| Scope / Approach | Breadth-first across defined attack surface | Objective-first with an assume-breach starting premise | Simultaneous red and blue team exercises targeting specific techniques |
| Maturity required | Value at any maturity level (Reactive) | High maturity (Adversary-ready with tuned SIEM) | Moderate maturity (Operational floor, basic detection infrastructure) |
| Core deliverable | Exploitable vulnerability list with CVSS scores and remediation steps | Detection gap analysis, dwell time, and attack-chain narrative | New/updated SIEM rules, updated MITRE ATT&CK map, and documented gap logs |
Both teams tune the rule immediately before moving to the next technique.
This isn’t a red team engagement with a debrief tacked on at the end. The debrief model produces documentation after the fact. Purple teaming produces working detection rules during the exercise. The output is new or updated SIEM rules, an updated MITRE ATT&CK coverage map, and a documented gap log your team can act on the same week.
Purple teaming fits between regular pen testing and a full red team engagement on the maturity arc: You need more detection infrastructure than a basic pen test requires, but you don't need the operational maturity a fully blind red team demands.
How Wiz closes the gap between exercises
Both pen tests and red team engagements are point-in-time snapshots. Your cloud environment doesn't hold still between them.
New IAM permissions are granted, IaC misconfigurations reach production through CI/CD, and attack paths emerge long after an assessment ends. This means organizations need a continuous validation layer that monitors cloud changes, identifies new attack paths, and surfaces exploitable exposure as the environment evolves (not just when an engagement is scheduled).
Wiz is that connected layer, showing what attackers can reach right now, not what they reached six months ago in a scoped exercise. The Wiz Security Graph correlates what your last engagement tested against your current posture. It connects cloud resources, identities, and exposed paths into a continuous view that updates as your environment changes.
You can see how attack paths propagate across your cloud environment in real time, not just at the moment a tester ran their tooling.
Wiz Pen Testing findings surface continuously, and the Wiz Red Agent grounds offensive security validation in your live cloud posture. Together with cloud security posture management that runs between engagements, Wiz lets you close the gap that point-in-time exercise leaves open.
Track active cloud attack paths in real time. Get a demo to see how Wiz maps your environment.
Complete Visibility Into Vulnerabilities
Learn why CISOs at the fastest growing companies choose Wiz to identify and remediate vulnerabilities in their cloud environments.
