CISSP Domain 6, Security Assessment and Testing, is weighted at 12% of the exam and is the domain that separates compliance-trained candidates from genuinely security-trained ones. The point of testing is not to produce reports for auditors; it is to know whether your security controls actually work. Domain 6 rewards candidates who can choose the right testing technique for the question being asked, run a coherent program over time, and turn findings into action rather than spreadsheets.
This guide collects the 14 in-depth Domain 6 articles on Threat on the Wire into one structured reference. Use it as a study path or a topic index. Every article assumes you already understand basic security testing concepts and want clarity on how the (ISC)² CBK frames assessment, testing, and audit at the manager level.
What Domain 6 is really testing
CISSP lens: the right answer chooses the testing technique that matches the assurance question. "Are the controls operating effectively?" "Is the system exploitable?" "Is the program improving?" Each question wants a different test.
Domain 6 has three big themes. First, the strategy: how to design an assessment and testing program that produces actionable assurance. Second, the techniques: vulnerability assessment, penetration testing, code review, control testing, audits. Third, the operational tie-back: how testing results turn into prioritised remediation rather than reports nobody acts on.
You will be tested on:
- Assessment and testing fundamentals and the difference between assessment, testing, and audit.
- Vulnerability assessment vs penetration testing - which to use when.
- Security testing in the SDLC: SAST, DAST, IAST, SCA, code review.
- Security testing in agile / DevOps environments.
- Red teaming, purple teaming, and tabletop exercises.
- Internal audits and control testing for evidence collection.
- Logging, monitoring, and detection-control validation.
- Disaster recovery and business continuity testing.
- Third-party security assessments and SOC reports.
- Social engineering testing and security awareness measurement.
- Vulnerability and remediation management.
- Security metrics that executives can use.
- Annual security testing planning and strategy.
How Domain 6 fits into the rest of the CBK
Domain 6 closes the loop on the rest of the CBK. The risk lifecycle in Domain 1 needs Domain 6 testing to validate the controls. The architectural choices in Domain 3 need Domain 6 testing to confirm they were implemented as designed. The detection capabilities in Domain 7 need Domain 6 validation to confirm they work. The secure SDLC in Domain 8 uses Domain 6 testing techniques (SAST, DAST, code review) as primary controls.
If a Domain 1 question asks about residual risk, the answer often involves Domain 6 testing as the verification mechanism. The domains are interlocked.
Core concepts at a glance
| Concept | What it is | Why it matters on the exam |
|---|---|---|
| Assessment | Evaluating overall security posture | Broader than testing; includes documentation review |
| Testing | Hands-on validation of specific controls or vulnerabilities | Active; verifies behaviour, not just design |
| Audit | Formal evaluation against a standard | Independent; produces opinions and findings |
| Vulnerability assessment | Identifies weaknesses, breadth-first | Generally automated; produces a vulnerability list |
| Penetration test | Exploits weaknesses to demonstrate impact | Generally manual; depth-first; tests defence |
| SAST | Static Application Security Testing (source code) | Finds bugs early in the SDLC; good for known patterns |
| DAST | Dynamic Application Security Testing (running app) | Finds runtime issues; closer to attacker perspective |
| IAST | Interactive Application Security Testing | Inside the running app with instrumentation |
| SCA | Software Composition Analysis | Finds vulnerable open-source dependencies |
| Red team | Simulates a determined attacker | Goal-oriented; tests detection and response |
| Purple team | Red and blue teams working together | Maximises learning; preferred by mature programs |
| SOC report | Service-organisation control attestation | SOC 1 = financial; SOC 2 = security; SOC 3 = public |
Assessment, testing, and audit: the fundamentals
The first vocabulary the exam tests is the difference between assessment, testing, and audit. They are related but distinct. Assessment is the broad evaluation of posture. Testing is the active validation of specific controls or vulnerabilities. Audit is the formal independent evaluation against a defined standard. The right tool depends on the assurance question.
Build the foundation with Security Assessment and Testing Fundamentals: How to Know If Your Controls Actually Work.
Vulnerability assessment vs penetration testing
This is the single most-tested distinction in Domain 6. Vulnerability Assessment vs Penetration Testing: Choosing the Right Tool for the Question walks through when to use each, who runs each, and what each delivers.
Quick comparison
| Property | Vulnerability Assessment | Penetration Test |
|---|---|---|
| Goal | Find weaknesses | Demonstrate exploitability and impact |
| Approach | Breadth-first | Depth-first |
| Automation | Mostly automated (Nessus, Qualys) | Mostly manual with automated assistance |
| Output | Prioritised vulnerability list | Narrative + findings + recommendations |
| Cadence | Continuous or weekly | Quarterly to annually |
| Risk | Low (read-only) | Higher (active exploitation) |
Security testing in the SDLC
Modern testing increasingly happens inside the development pipeline. Security Testing in the SDLC: Making SAST, DAST, and Code Review Part of Normal Delivery covers the techniques that catch vulnerabilities before code reaches production.
For agile and DevOps teams, the question shifts from "which test" to "how to keep up." Security Testing in Agile and DevOps: Keeping Up with Weekly Releases Without Burning Out Teams covers the cadence question and how to embed security into a fast-moving pipeline.
Red teaming and purple teaming
Red teams simulate determined adversaries; purple teams pair red and blue to maximise learning. Red Teaming and Purple Teaming: Turning Testing into a Learning Experience for Defenders covers the scope, rules of engagement, and the maturity model that decides when each makes sense.
Control testing, audits, and evidence
The audit and control-testing track is where Domain 6 most overlaps with compliance work. Internal Audits and Control Testing: Gathering Evidence That Your Security Program Works walks through the evidence-collection mindset, sampling, and the difference between testing design effectiveness and operating effectiveness.
For external attestation, Third-Party Security Assessments: Using SOC Reports, Certifications, and Questionnaires Effectively covers SOC 1 / SOC 2 / SOC 3, ISO 27001 certifications, and how to read a vendor's attestation without taking it at face value.
Logging, monitoring, and detection validation
Detection controls only work if you regularly verify they are working. Logging, Monitoring, and Control Validation: Proving Your Detection and Response Actually Work covers the validation mindset: how to test that the alert fires, the analyst sees it, and the response actually contains the threat.
Disaster recovery and business continuity testing
BCP and DR plans that are never exercised are plans that will fail when needed. Disaster Recovery and Business Continuity Testing: Proving You Can Survive a Bad Day covers the test-type ladder (read-through, walkthrough, simulation, parallel, full interruption) and which type fits which maturity level.
DR/BCP test types in increasing rigour
- Read-through (checklist): review the documented plan; lowest disruption.
- Walkthrough: structured tabletop walking through scenarios.
- Simulation: simulated event with role-play; primary systems still in production.
- Parallel test: failover environment activated alongside production.
- Full interruption test: primary systems actually taken down; highest rigour and risk.
The exam favours moving up the ladder over time as the program matures, with full interruption tests reserved for mature programs where the risk of the test itself is acceptable.
Social engineering testing
Social Engineering and Awareness Testing: Measuring the Human Side of Your Security Program covers phishing simulations, vishing, physical pretexting, and the awareness-program metrics that distinguish "click rate went down" from "people are actually safer."
Managing findings, metrics, and the testing strategy
Testing without remediation is theatre. Managing Findings and Remediation: Turning Test Results into Real Risk Reduction covers prioritisation, exception management, and the workflow that turns a vulnerability scan into closed tickets.
Security Metrics and Reporting: Turning Test Results into Decisions Executives Can Use covers the metric set that survives executive review: mean time to detect, mean time to remediate, percentage of high-severity findings closed, control-effectiveness rates.
The strategic frame is in Building a Security Testing Strategy and Annual Plan: how to coordinate the various testing activities into a coherent program rather than disconnected one-off tests.
Real-world test-manager scenarios
A security test manager is asked by leadership to "make sure our authentication system is secure." The technical instinct is to commission a penetration test. The manager instinct is to ask the underlying assurance question first. Are we trying to find unknown weaknesses (penetration test)? Verify configuration drift hasn't introduced known weaknesses (vulnerability assessment)? Test detection of credential abuse (purple team exercise)? Validate the design itself (architecture review)? Each maps to a different test type. Domain 6 questions reward this assurance-question-first thinking.
A second example: a CISO is told an internal audit has found dozens of expired access reviews. The technical instinct is to assign someone to clean them up. The strategic instinct is broader: this is a control-effectiveness signal about the access-review program itself. The right next steps are to identify why reviews are expiring (process broken? owners unclear? tool unfit?), prioritise high-risk systems first, and report the systemic finding back to the auditor with a remediation plan that addresses the root cause, not just the symptom.
Common exam traps in Domain 6
- Confusing vulnerability assessment with penetration testing. Vuln assessment is breadth-first and finds weaknesses. Pen test is depth-first and demonstrates exploitability. The exam tests the distinction directly.
- Picking SAST when the question wants runtime issues. SAST analyses source code statically. DAST analyses the running application. The right answer depends on whether the issue manifests in code or in deployment.
- Calling SOC 1 a security report. SOC 1 is for financial controls. SOC 2 is for security, availability, processing integrity, confidentiality, and privacy.
- Treating audit and assessment as synonyms. Audits are formal and independent; assessments are broader and may be self-conducted.
- Skipping plan testing. A BCP or DR plan that has never been exercised is the wrong answer to "we have continuity capability." The exam will offer "we documented the plan" as a distractor.
- Treating findings as the deliverable. The deliverable is reduced risk. Findings without remediation are scoring at the wrong goal.
- Confusing red teaming with penetration testing. Red teams test detection and response over time with goal-oriented adversary simulation. Penetration tests find vulnerabilities in scope. The two overlap but are not interchangeable.
The full Domain 6 reading order
Fundamentals
Testing in the SDLC
Red and purple teaming
Audits and third-party assessments
Detection and DR validation
Social engineering and awareness testing
Program-level: findings, metrics, strategy
- Managing Findings and Remediation
- Security Metrics and Reporting
- Building a Security Testing Strategy and Annual Plan
Exam scenario practice
Related CISSP domains
Threat on the Wire publishes a long-form pillar for every CISSP domain. The eight domains are interlocked - mastering any one of them is easier when you can see how it connects to the others. Here's how this domain relates to the other seven, with a one-line summary of the relationship and a link to the pillar.
| Pillar | How it relates to this domain |
|---|---|
| Domain 1: Security and Risk Management | Risk lifecycle from Domain 1 is validated by the testing techniques covered here. |
| Domain 2: Asset Security | Data ownership and classification get audited as part of Domain 6 control testing. |
| Domain 3: Security Architecture and Engineering | Architectural validation - design and code review - is a Domain 6 activity. |
| Domain 4: Communication and Network Security | Network testing maps to Domain 4 network security controls. |
| Domain 5: Identity and Access Management | Identity controls are a frequent Domain 6 control-testing target. |
| Domain 7: Security Operations | Domain 6 testing finds weaknesses; Domain 7 operations remediate them. |
| Domain 8: Software Development Security | Application security testing (SAST, DAST, SCA) is a Domain 6 plus Domain 8 overlap. |
For the full CISSP overview, exam structure, and 12-week study plan, see the CISSP Study Hub.
Frequently asked questions
How much of the CISSP exam covers Domain 6?
Domain 6 is weighted at 12% of the exam. Out of roughly 100-150 items, expect 12-18 from Domain 6. Many of those are scenario questions where the right answer depends on choosing the right testing technique for the assurance question.
Should we do a vulnerability assessment or a penetration test?
Both, at different cadences. Vulnerability assessments are continuous or weekly; they identify the breadth of weaknesses. Penetration tests are quarterly or annual; they validate that defences hold against an active adversary. The exam tests the case where you must pick one - in those questions, "what's the goal?" is the deciding factor: find weaknesses (vuln assessment) or demonstrate impact (pen test).
What is the difference between SOC 1, SOC 2, and SOC 3?
SOC 1 reports on internal controls relevant to financial reporting. SOC 2 reports on security, availability, processing integrity, confidentiality, and/or privacy. SOC 3 is a general-use, public-facing summary version of SOC 2. SOC 2 is what security professionals usually mean when they say "send us the SOC report"; SOC 1 is for financial auditors.
Why is purple teaming preferred to traditional red teaming?
Pure red team exercises maximise simulation realism but learning is limited to the post-test debrief. Purple team exercises pair red and blue teams in real time, so defenders see attack techniques as they happen, learn detection patterns, and tune controls during the exercise. Mature programs run pure red teams less frequently (annually) and purple teams more often (quarterly) for that reason.
When should we run a full-interruption DR test?
Only when the program is mature enough that the risk of the test itself is acceptable. Read-through, walkthrough, simulation, and parallel tests come first. Full interruption is the highest-rigour test and should be reserved for mature programs that have already validated capability via lower-risk tests. The exam tests this maturity progression.
Key takeaways
- Domain 6 is the assurance domain. Pick the testing technique that matches the assurance question, not the technique you happen to know.
- Vulnerability assessment and penetration testing are not interchangeable. Vuln assessment finds weaknesses; pen test demonstrates exploitability.
- SDLC-side testing (SAST, DAST, IAST, SCA, code review) catches vulnerabilities before production. The right tool depends on the lifecycle stage.
- Red teaming tests detection and response; purple teaming maximises learning. Both have a place in a mature program.
- SOC reports differ: SOC 1 = financial, SOC 2 = security, SOC 3 = public. Use SOC 2 for vendor-security questions.
- BCP/DR plans must be tested. The test-type ladder (read-through to full interruption) maps to program maturity.
- Findings without remediation are theatre. Metrics and remediation discipline turn testing into actual risk reduction.
If you take one thing away from Domain 6, take this: testing exists to answer specific assurance questions. Match technique to question and you will pick the right answer on exam day - and run a real program in the rest of your career.