Red Team Test Runbook: Turn CISA Findings Into Audit-Ready Controls

Your SOC 2 or ISO/IEC 27001 certification confirms you've documented the right controls. But can your team actually detect and respond to an adversary? CISA recently assessed two critical infrastructure organizations, revealing a sobering pattern: one SOC missed initial access, privilege escalation, and lateral movement entirely, while the other detected and contained the threat.

The difference wasn't budget or headcount. It was operational readiness.

This runbook translates CISA's published lessons into a structured test scenario you can run internally. Use it to validate whether your detective controls (SOC 2 CC6.1, CC7.2; ISO/IEC 27001 Clause 8.16) actually work under pressure, and whether your incident response procedures (ISO/IEC 27001 Clause 5.24) hold up when someone's actively probing your environment.

Purpose of This Runbook

This is a tabletop-to-technical exercise template that tests three control areas CISA identified as weak:

• Detection tool effectiveness: Are your SIEM rules tuned, or just installed?
• Cross-functional response coordination: Can your SOC escalate to IT operations without waiting for approvals?
• Cloud access governance: Do you know who has standing admin privileges in your IaaS tenant?

You're not replicating a full red team engagement. You're running a controlled scenario that stress-tests the controls your auditor will ask about during your next SOC 2 Type II or ISO/IEC 27001 surveillance audit.

Prerequisites

Before you run this exercise, confirm:

• You have executive approval to simulate malicious activity in a non-production environment (or a contained production segment with change control).
• Your SOC team does not know the test window to preserve the element of surprise for detection validation.
• You've identified a test account with realistic but non-critical access, like a contractor account or a low-privilege service account you can safely manipulate.
• You have a rollback plan if the test triggers automated containment that affects legitimate services.
• Your incident response plan (ISO/IEC 27001 Clause 5.24) is documented and accessible to responders.

If you're preparing for a SOC 2 Type II audit, this exercise generates evidence for CC6.1 (logical and physical access controls are monitored) and CC7.2 (the entity monitors system components and the operation of those components for anomalies). For ISO/IEC 27001, you're validating Annex A Control 5.24 (information security incident management planning and preparation) and Control 8.16 (monitoring activities).

The Test Scenario Template

Run this as a four-phase exercise over four hours. Document every step with screenshots and timestamps.

Phase 1: Initial Access Simulation (30 minutes)

Simulate credential compromise without actually exfiltrating real credentials. Use your test account to:

1. Authenticate from an unusual geographic location using a VPN endpoint your organization doesn't normally operate from.
2. Attempt authentication outside normal business hours.
3. Trigger multiple failed login attempts, then one successful login.

Expected detective control activation: Your identity provider or SIEM should flag impossible travel, off-hours access, or brute-force patterns. Document whether an alert fired, who received it, and how long until someone investigated.

Phase 2: Privilege Escalation Attempt (45 minutes)

Using the test account, attempt to:

1. Request elevated permissions through your normal access request workflow.
2. Query Active Directory or your identity provider for a list of privileged accounts to test whether your monitoring catches reconnaissance.
3. Attempt to access a restricted file share or cloud storage bucket you know the account shouldn't reach.

Expected detective control activation: Your access request system should log the attempt. Your file integrity monitoring or cloud access logs should flag unauthorized access attempts. Document the alert timeline and whether anyone followed up before the test window ended.

Phase 3: Lateral Movement Indicator (45 minutes)

Simulate lateral movement by:

1. Using the test account to authenticate to a second system it doesn't normally access, like a jump box, a shared file server, or a cloud resource in a different project.
2. Running a network scan from that second system against a small range of internal IPs using a safe, non-disruptive scan tool like nmap with limited flags.

Expected detective control activation: Your EDR or network monitoring tools should detect unusual process execution, network scanning, or anomalous authentication patterns. Document whether your SOC opened a ticket and escalated it.

Phase 4: Cloud Privilege Audit (60 minutes)

This phase doesn't simulate an attack. It audits your standing cloud access:

1. Export a list of all IAM users, service accounts, and roles in your primary cloud tenant.
2. Filter for accounts with admin-level permissions (AWS AdministratorAccess, Azure Owner, GCP roles/owner).
3. Identify accounts that haven't authenticated in 90 days but still hold privileged access.
4. Check for service accounts with overly broad permissions, like a CI/CD pipeline with full s3:* instead of scoped bucket access.

Expected organizational control: You should have a policy for periodic access reviews (SOC 2 CC6.2; ISO/IEC 27001 Annex A Control 5.18). This audit tests whether that policy actually removes unused privileges or just recertifies them.

Customizing the Scenario

Adjust the scenario based on your environment:

If you're primarily SaaS: Replace Phase 3 (lateral movement) with a test of your application-level controls. Attempt to access another user's data through your web application, or try to export a dataset you shouldn't have permission to pull.

If you have a mature SOC: Add a fifth phase that tests your incident response escalation. Once the SOC detects the simulated activity, measure how long it takes to convene your incident response team, assign a severity rating, and initiate containment. Your ISO/IEC 27001 Clause 5.26 (response to information security incidents) requires documented procedures; this tests whether your team can execute them under time pressure.

If you're preparing for audit: Focus on evidence collection during the test. Capture SIEM query results, ticket timestamps, and escalation emails. Your auditor will ask how you validate detective control effectiveness; this runbook produces the evidence they're looking for.

Validation Steps

After the test, debrief with your SOC and IT operations teams. Answer these questions:

1. Detection coverage: Which phases triggered alerts? Which didn't? For any missed activity, was the tool misconfigured, or do you lack visibility into that attack surface?

2. Response time: From first alert to containment decision, how long did it take? CISA's report noted that organizational siloes delayed response. Did your team encounter approval bottlenecks or unclear ownership?

3. Cloud governance: How many privileged accounts did you find with excessive or unused permissions? Your ISO/IEC 27001 Annex A Control 8.2 (privileged access rights) requires that you restrict and control allocation of privileged access rights. Unused admin accounts are a control gap.

4. False positive rate: If your SOC ignored alerts during the test because they assumed it was noise, you have a tuning problem. CISA's first lesson was that untuned tools miss threats. Document your baseline false positive rate and commit to reducing it.

5. Documentation quality: Could a new SOC analyst follow your incident response procedures without asking for clarification? If not, update your runbooks before your next audit.

Schedule this test quarterly. Your SOC 2 Type II report covers a period (usually 6-12 months), and your auditor will ask how you validate control effectiveness over time. Running this scenario every quarter gives you the evidence trail they're looking for.

If you discover gaps, document them in your Risk Treatment Plan (ISO/IEC 27001 Clause 6.2) and track remediation. A missed detection isn't an audit failure if you can show you identified it, assessed the risk, and implemented corrective controls before the auditor arrived.