Overview
Security Assessment and Testing covers how an organization verifies that its controls are designed and operating as intended. Its five sub-objectives are designing and validating assessment, test and audit strategies (internal, external, third-party, across on-premise, cloud and hybrid locations); conducting control testing such as vulnerability assessments, penetration tests, log reviews, synthetic transactions, code review, misuse case testing, coverage analysis, interface testing, breach attack simulations and compliance checks; collecting security process data such as KPIs and KRIs; analyzing output and reporting with remediation, exception handling and ethical disclosure; and conducting or facilitating audits.
Candidates must pick the test that answers the question being asked, understand who should perform it and how independent they must be, and know what happens to findings afterwards. This domain measures the governance of Domain 1, the access controls of Domain 5 and the operations of Domain 7.
How it's tested
Questions present an assurance need and ask which assessment, which assessor, which data or which report fits it. Many include a sequencing twist, such as what must happen before a penetration test or after findings are reported. The deciding clue is usually the audience (management, customers, regulators) and whether the goal is design adequacy or operating effectiveness over time.
-
Choose the test
A goal such as finding known flaws, proving exploitability or checking availability from a user's perspective points to a scan, penetration test or synthetic transaction.
-
Choose the report or assessor
A customer, regulator or board needs assurance, and you pick an internal, external or third-party assessment, or the right SOC report type.
-
Handle the findings
Results are in, and you decide on remediation priority, exception handling or ethical disclosure of a vendor vulnerability.
A SaaS customer asks for evidence that the provider's security controls operated effectively throughout the past year. Options include a SOC 1 report, a SOC 2 Type I, a SOC 2 Type II and the provider's internal audit summary. SOC 2 covers security trust services criteria, and Type II tests operating effectiveness over a period. SOC 2 Type I is the strongest distractor, but it only assesses design at a point in time.
Sub-objectives 5
Official sub-objectives from the ISC2 outline, in outline order.
6.1 Design and validate assessment, test, and audit strategiesInternal, external and third-party assessments across on-premise, cloud and hybrid locations.
- What it means
- An assessment strategy defines what will be tested, how often, by whom and against which criteria, aligned with risk and compliance obligations. The outline distinguishes internal, external and third-party assessments and the location of what is assessed: on-premise, cloud or hybrid.
- What to understand
- Internal assessments are cheaper and frequent but less independent; external audits by an organization's own auditors or regulators and third-party assessments by independent firms add credibility. Cloud assessments are constrained by the provider's terms, so customers often rely on the provider's attestations and their own configuration testing.
- How it shows up
- A board wants independent assurance before a major acquisition, and the BEST choice is a third-party assessment rather than an internal review.
- Common confusion
- Assuming you can penetration-test a cloud provider's infrastructure freely; testing must follow the provider's published policy and the shared responsibility model.
6.2 Conduct security controls testingVulnerability assessment, penetration testing, log reviews, synthetic transactions, code review, misuse cases, coverage, interface testing, BAS and compliance checks.
- What it means
- This covers vulnerability assessments; penetration testing including red, blue and purple team exercises; log reviews; synthetic transactions and benchmarks; code review and testing; misuse case testing; coverage analysis; interface testing of user, network and API interfaces; breach attack simulations; and compliance checks.
- What to understand
- A vulnerability assessment identifies and ranks weaknesses without exploiting them; a penetration test exploits them to prove impact and requires written authorization and rules of engagement. Synthetic transactions run scripted activity to monitor availability and performance, while real user monitoring observes actual users. Purple teaming combines red attack and blue defense to improve detection collaboratively.
- How it shows up
- A team needs to know whether a vulnerability is actually exploitable in its environment, which points to a penetration test, not another scan.
- Common confusion
- Treating a vulnerability scan as a penetration test, or starting a penetration test without signed authorization from senior management.
6.3 Collect security process data (e.g., technical, and administrative)Account management, management review, KPIs and KRIs, backup verification, training and DR/BC data.
- What it means
- Process data shows whether security processes work over time. The outline lists account management data, management review and approval, key performance and risk indicators, backup verification data, training and awareness metrics, and disaster recovery and business continuity data.
- What to understand
- A key performance indicator (KPI) measures how well a process is performing, such as patching within SLA; a key risk indicator (KRI) signals rising risk exposure, such as the count of unpatched critical systems. Backups are only evidence of recoverability when restores are tested and verified.
- How it shows up
- Management wants an early warning that risk is increasing before an incident occurs, which calls for KRIs.
- Common confusion
- Treating successful backup job logs as proof of recoverability without restore testing.
6.4 Analyze test output and generate reportRemediation, exception handling and ethical disclosure.
- What it means
- Test results must be analyzed for root cause, prioritized by risk and reported to the right audience. The outline names remediation, exception handling when a finding cannot be fixed, and ethical disclosure when a test uncovers a vulnerability in someone else's product.
- What to understand
- Executives need risk-based summaries; technical teams need detailed findings and fixes. An exception is a documented, time-bound risk acceptance by the appropriate owner, often with compensating controls. Ethical disclosure means notifying the vendor privately and allowing reasonable time to fix before any public release.
- How it shows up
- A legacy system cannot be patched for a critical finding, and the BEST response is a formal exception approved by the owner with compensating controls and a review date.
- Common confusion
- Publishing a discovered vendor vulnerability immediately, or quietly ignoring an unfixable finding instead of documenting an exception.
6.5 Conduct or facilitate security auditsInternal, external and third-party audits across locations.
- What it means
- Audits independently evaluate controls against criteria such as policy, regulation or standards. Security professionals may conduct internal audits or facilitate external and third-party audits by providing evidence, access and context.
- What to understand
- Auditors need independence from the area audited. Service organization control reports under SSAE 18 come in SOC 1 (financial reporting controls), SOC 2 (trust services criteria including security, restricted distribution) and SOC 3 (general-use summary); Type I covers design at a point in time and Type II covers operating effectiveness over a period.
- How it shows up
- A company must assess a cloud provider that will not allow on-site audits, and the answer is to review its SOC 2 Type II report and bridge letters.
- Common confusion
- Asking for a SOC 1 to assess security controls; SOC 1 addresses controls relevant to financial reporting.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Vulnerability assessment vs. penetration test
A vulnerability assessment finds and prioritizes weaknesses without exploiting them; a penetration test exploits them to demonstrate real impact.
- Remember
- Penetration tests require written authorization and agreed rules of engagement from management before starting.
- Tested as
- Test selection and sequencing questions.
- Trap
- Beginning a penetration test on verbal approval from IT.
-
Knowledge levels of testing
Black box testers start with no knowledge, white box with full knowledge, gray box with partial knowledge.
- Remember
- Black box best simulates an external attacker; white box finds more issues in less time.
- Tested as
- Scope and approach questions.
- Trap
- Assuming black box is always more thorough.
-
Red, blue and purple teams
Red teams emulate attackers, blue teams defend and detect, and purple teams combine both to improve detection and response jointly.
- Remember
- Purple teaming is about feedback loops, not a third adversary.
- Tested as
- Exercise type identification.
- Trap
- Thinking purple teams are independent auditors.
-
Synthetic transactions vs. real user monitoring
Synthetic transactions are scripted actions run on a schedule to test functionality and availability; real user monitoring passively observes actual users.
- Remember
- Synthetic monitoring detects outages even when no users are active.
- Tested as
- Availability testing questions.
- Trap
- Choosing real user monitoring for proactive testing at night.
-
Misuse case testing
Testing scenarios written from an attacker's point of view to see how a system handles abuse.
- Remember
- It complements use cases by testing what should not be possible.
- Tested as
- Application testing questions.
- Trap
- Confusing it with negative input testing alone.
-
Coverage analysis
Measuring how much of the code or functionality the tests actually exercised, such as statement, branch or condition coverage.
- Remember
- High coverage shows tests ran through code, not that the code is secure.
- Tested as
- Test completeness questions.
- Trap
- Equating 100% coverage with no vulnerabilities.
-
Breach attack simulation
Automated tools that continuously run known attack techniques against production controls to check detection and prevention.
- Remember
- It provides frequent, repeatable validation that complements periodic penetration tests.
- Tested as
- Continuous control validation questions.
- Trap
- Treating it as a replacement for human-led testing.
-
KPI vs. KRI
KPIs measure how well processes perform against targets; KRIs signal changing risk exposure.
- Remember
- KRIs are leading indicators used for early warning.
- Tested as
- Metric selection questions.
- Trap
- Using a KPI when the scenario asks for early warning of risk.
-
SOC 1, SOC 2, SOC 3
SOC 1 covers controls relevant to financial reporting; SOC 2 covers trust services criteria (security, availability, processing integrity, confidentiality, privacy) with restricted distribution; SOC 3 is a public summary.
- Remember
- For a vendor's security controls, request a SOC 2.
- Tested as
- Third-party assurance questions.
- Trap
- Requesting a SOC 1 to assess security.
-
Type I vs. Type II
Type I reports on control design at a point in time; Type II tests operating effectiveness over a period, commonly six to twelve months.
- Remember
- Type II gives stronger assurance.
- Tested as
- Assurance strength questions.
- Trap
- Accepting a Type I when evidence of operation over time is required.
-
Exception handling
A documented, approved and time-limited acceptance of a finding that cannot be remediated now.
- Remember
- The owner approves it, compensating controls are applied and a review date is set.
- Tested as
- Remediation and reporting questions.
- Trap
- Leaving findings open indefinitely without documentation.
-
Ethical disclosure
Responsibly reporting a discovered vulnerability to the affected vendor before any public release, allowing time for a fix.
- Remember
- Coordinated disclosure balances user protection with vendor remediation time.
- Tested as
- Findings in third-party products.
- Trap
- Posting details publicly to force a fix.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Vulnerability assessment vs. penetration test vs. breach attack simulation
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Vulnerability assessment | Identify and prioritize known weaknesses | No exploitation; broad and frequent | Calling a scan report a penetration test |
| Penetration test | Exploit weaknesses to show real impact | Human-led, scoped, authorized in writing | Starting without rules of engagement |
| Breach attack simulation | Automated emulation of known attack techniques | Continuous validation of detection and prevention | Assuming it finds novel attack paths like a skilled tester |
SOC 1 vs. SOC 2 vs. SOC 3
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| SOC 1 | Controls relevant to user entities' financial reporting | Used by financial auditors | Using it to assess security controls |
| SOC 2 | Trust services criteria including security | Detailed report with restricted distribution | Expecting it to be publicly posted |
| SOC 3 | General-use summary of SOC 2 scope | Public, but without detailed test results | Relying on it for detailed control assurance |
KPI vs. KRI
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| KPI | Measures process performance against a target | Looks at how well work is done, such as percentage of patches within SLA | Using it as an early warning of risk |
| KRI | Measures changes in risk exposure | Leading indicator tied to risk appetite thresholds | Confusing it with a performance target |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Test now, authorize later
- What candidates pick
- Launching a penetration test after the IT manager verbally agrees.
- Why it looks right
- It is fast and the intent is protective.
- Why it's wrong
- Without written authorization from senior management and defined scope, testing may be illegal and can disrupt production.
Clue to watch for The question asks what must happen FIRST before testing.
-
Scan equals pen test
- What candidates pick
- Running another vulnerability scan to determine real impact.
- Why it looks right
- Scans are cheaper and already scheduled.
- Why it's wrong
- Scans identify potential weaknesses; only exploitation demonstrates impact in context.
Clue to watch for The requirement is to prove exploitability or business impact.
-
Wrong SOC report
- What candidates pick
- SOC 1 Type II to evaluate a cloud provider's security.
- Why it looks right
- Type II is the stronger report type.
- Why it's wrong
- SOC 1 covers financial reporting controls; security needs SOC 2.
Clue to watch for The concern is security, availability or confidentiality of a service provider.
-
Point-in-time assurance
- What candidates pick
- SOC 2 Type I as evidence controls worked all year.
- Why it looks right
- It is a SOC 2 report covering security.
- Why it's wrong
- Type I assesses design at one date; operating effectiveness over a period requires Type II.
Clue to watch for Words such as throughout, over the period or consistently.
-
Coverage equals security
- What candidates pick
- Accepting 100% code coverage as proof the application is secure.
- Why it looks right
- Complete coverage sounds complete.
- Why it's wrong
- Coverage shows code paths executed, not that tests checked for abuse or that results were correct.
Clue to watch for A metric about test execution is offered as evidence of security.
-
Publish to force a fix
- What candidates pick
- Disclosing a vendor vulnerability publicly as soon as it is found.
- Why it looks right
- Public pressure seems to protect users.
- Why it's wrong
- Ethical disclosure notifies the vendor privately first and allows reasonable time to remediate.
Clue to watch for The vulnerability is in a third party's product.
Answer framework
Use these steps when a Domain 6 question asks which assessment to run, who should run it or what to do with results.
- Clarify the assurance question: are we checking control design, operating effectiveness over time, exploitability, availability or compliance with a specific standard?
- Choose the assessor by audience and required independence: internal for frequent checks, external or third-party for boards, customers and regulators.
- Secure written authorization, scope and rules of engagement before any intrusive testing, especially penetration tests and simulations against production.
- Select the test or data that answers the question, such as a penetration test, synthetic transactions, KRIs, or a SOC 2 Type II report.
- Report by audience, prioritize remediation by risk, document approved exceptions with compensating controls, and disclose third-party flaws ethically.
Practice question
Want more like this? The CISSP practice test has questions for every domain.
Checklist
0 of 12
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Begin with the purpose of testing: assurance for a decision maker. Then study control testing types (6.2) as a comparison table that shows goal, method, who performs it and prerequisites, because the exam distinguishes tests by goal more than technique. Next cover process data and metrics (6.3), followed by reporting and audit topics (6.4 and 6.5), including SOC report types.
High-priority concepts are scans versus penetration tests, authorization before testing, KPIs versus KRIs, SOC report types and exception handling. Commonly underestimated areas are the less familiar testing methods in the outline, such as synthetic transactions, misuse case testing, coverage analysis, interface testing and breach attack simulations, and ethical disclosure.
After this domain, connect it back to Domain 1 by asking which governance decision each test supports, and forward to Domain 7, where DR plan testing and incident lessons learned produce the data you analyze here. Mixed practice sets that combine Domains 6 and 8 also help, because code review, SAST and DAST questions appear in both.
FAQ
Is Domain 6 technical or managerial?
Both. You need to know what each test does technically, but most questions ask which test, which assessor or which report suits a business need. Thinking like an audit manager helps.
What must happen before a penetration test?
Written authorization from appropriate senior management, an agreed scope and rules of engagement, including timing, methods allowed, data handling and emergency contacts. Testing without it can be illegal and disruptive.
What is the difference between SOC 2 Type I and Type II?
Type I reports on whether controls are suitably designed at a specific date. Type II tests whether they operated effectively over a period, typically six to twelve months, and gives stronger assurance.
What are synthetic transactions used for?
They run scripted actions against a system on a schedule to verify functionality, availability and performance, so problems are detected even when no real users are active.
How do KPIs and KRIs differ?
KPIs measure how well a process performs against its target. KRIs signal changes in risk exposure and are used as leading indicators against risk appetite thresholds.
How does Domain 6 relate to Domain 8?
Domain 6 covers code review, testing and coverage as assessment techniques; Domain 8 places them in the software development lifecycle through SAST, DAST, IAST and software composition analysis.
How long should I study Domain 6?
Our editorial planning estimate is 25 to 35 hours within a 250-hour plan. Most of that time goes to distinguishing similar test and report types.
Other Cybersecurity certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- CompTIA Cybersecurity Analyst+ Study guide
- Microsoft Security Operations Analyst Associate Study guide
- Certified Ethical Hacker Study guide
- Penetration Tester Study guide
- Systems Security Certified Practitioner Study guide
- Certified in Risk and Information Systems Control Study guide
- CompTIA PenTest+ Study guide
- CompTIA SecurityX (CASP+) Study guide
- Azure Security Engineer Associate Study guide
- CISM (Certified Information Security Manager) Study guide
- CompTIA Security+ Study guide
- Certified Information Systems Auditor Study guide
- Certified Cloud Security Professional Study guide
Test your Domain 6 knowledge
You have covered assessment strategy, control testing types, security metrics, reporting and audits. Test whether you can choose the right assessment and report for each scenario.