CISSP Domain 6: Security Assessment and Testing — Assess, Test, Prove

CISSP Domain 6, Security Assessment and Testing, is 12% of the exam and the discipline that turns security claims into evidence. Its job is assurance: proving to stakeholders that controls are defined, tested, and actually operating, not just documented. You will design assessment, test, and audit strategies; run vulnerability assessments and penetration tests; collect security process data; analyze output into reports; and conduct or facilitate audits. In real jobs this is the language auditors, GRC teams, and red teams share. Knowing why a SOC 2 Type II report beats a one-day pen test, when a scan is enough, and how log and code reviews feed metrics is what separates someone who runs tools from someone who can defend a control posture to a board or a client.

Domain 6 at a glance

Flip each card for the one-line essence of each area before you dive in.

Assessment strategy & control testing

Think of a security assessment strategy like a school's annual exam timetable. You decide upfront which subjects get tested, when, by whom, and how marks get reported. CISSP Domain 6 asks you to design that timetable for your security controls, not improvise it.

Start by mapping every control to a business risk, then decide what evidence proves it works. A good test strategy defines scope, frequency, tools, owners, and a reporting path to management. High-risk controls get tested often, low-risk ones less. You blend automated scans with manual reviews so nothing slips through.

Security control testing is the hands-on part. It includes vulnerability scanning, penetration testing, configuration and code review, log reviews, synthetic transactions, misuse-case testing, and interface testing. Each method answers a different question: a scan finds known weaknesses, a pen test proves real exploitability.

Now the exam-favourite distinction. A test gathers raw technical data (did the patch close the hole?). An assessment is a broader, expert evaluation of overall posture that interprets many tests and produces a report with recommendations. An audit uses the same techniques but is performed by independent auditors to formally verify compliance against a standard or policy.

Test coverage analysis measures how much of your system the tests actually exercised. Black-box, white-box, and grey-box approaches give different coverage. Coverage gaps mean untested code paths or controls hide unknown risk.

Vuln assessment vs pen testing

Think of a vulnerability assessment as a home inspector walking through your house listing every weak lock and rusty window. A penetration test is a hired burglar who actually picks one lock to prove a thief could walk in. Both matter, but they answer different questions for CISSP Domain 6.

A vulnerability assessment is broad and shallow. It scans hosts, compares configs against benchmarks, and produces a long, prioritized list of possible weaknesses. It finds many issues fast but never proves they are reachable or exploitable, so it carries false positives. A penetration test is narrow and deep. The tester actively exploits a chosen flaw to demonstrate genuine business impact, validating exploitability that a scan only guessed at.

Knowledge level defines the test box. Black box means zero prior knowledge, mimicking an external attacker. White box (also called crystal/clear box) gives full access to source, architecture, and credentials, maximizing coverage. Grey box sits between, often a low-privilege user account, simulating a malicious insider or a phished employee.

The standard pentest follows five phases: reconnaissance (passive and active footprinting), scanning/enumeration (ports, services, versions), exploitation (gaining the foothold), post-exploitation (privilege escalation, lateral movement, persistence, proving impact), and reporting with prioritized, evidence-backed remediation. Always agree scope and rules of engagement first.

Finally, know the teams. Red attacks, blue defends and detects, and purple is not a separate team but red and blue collaborating live so attacker findings immediately tune defensive detections.

Audits & SOC reports

Think of an audit like a restaurant health inspection. Sometimes the head chef checks the kitchen himself, sometimes a hired consultant checks it, and sometimes a government inspector you cannot influence walks in. Same kitchen, very different credibility. CISSP Domain 6 frames audits exactly this way by independence.

An internal audit uses your own staff. It is cheap and frequent, but carries the least external trust because the auditors report up your own chain. An external audit is run by a firm you hire, like an accounting firm doing your SOC examination. A third-party audit is commissioned by an outside party, such as a regulator or a big client, so you cannot steer the outcome. As independence rises, so does the assurance the report gives.

For service providers, the AICPA SOC reports dominate. A SOC 1 covers controls over financial reporting (think payroll or payment processors). A SOC 2 covers the five Trust Services Criteria: security, availability, processing integrity, confidentiality, privacy. A SOC 3 is a trimmed, marketing-friendly SOC 2 you post publicly with no sensitive test detail.

Within SOC 1 and SOC 2, watch the Type. A Type I attests design of controls at a single point in time. A Type II tests operating effectiveness across a period, usually 6 to 12 months, demanding far more evidence and sampling.

What do auditors actually want? Evidence, gathered via three NIST SP 800-53A methods: examine (policies, configs, logs), interview (staff), and test (run the control). They sample tickets, access reviews, change records, and screenshots with timestamps.

Logs, code review & metrics

Think of a CCTV control room: cameras record everything, but value comes only when a guard correlates feeds, spots the same intruder across three doors, and acts. Logs, code review, and metrics are that control room for your security program.

Log review and SIEM correlation sit at the centre. Individual logs are noise; a SIEM ingests firewall, OS, application, and authentication logs, normalizes them, and applies event correlation rules to surface real attacks. A single failed login means nothing; 200 failures then one success, from a new country, is credential stuffing. The exam stresses that logs must be tamper-protected, time-synchronized via NTP, and reviewed regularly, not just collected.

Code review and testing validate software controls. Learn the three modes precisely. Static testing (SAST) reads source code without executing it, catching flaws like SQL injection early. Dynamic testing (DAST) runs the app and probes it from outside, like an attacker, finding runtime issues. Manual code review by peers catches business-logic flaws tools miss. Fuzzing feeds malformed input to crash hidden bugs.

Synthetic transactions are scripted bots that mimic real users, checking a balance or completing a checkout, to verify availability, functionality, and response time before customers complain. Misuse-case testing flips a use case: instead of "user logs in," you test "attacker brute-forces login," validating that abuse paths are blocked. Account-management reviews audit provisioning, deprovisioning, and entitlement creep, ensuring leavers lose access and no orphaned accounts linger.

KPIs and KRIs turn all this into management language. KPIs are backward-looking ("percentage of systems patched," "mean time to patch"). KRIs are forward-looking exposure signals ("number of exploitable vulnerabilities on critical assets," "accounts past 90-day review").

Domain 6 in the AI era (2026)

Domain 6 is about security assessment and testing — and in 2025/2026 that discipline has split into two clear AI lanes: using AI to test classic systems, and testing the AI systems themselves.

AI as the tester (offensive + defensive). Penetration testing and fuzzing are being supercharged. Tools like PentestGPT, XBOW, Pentera and NodeZero chain reconnaissance, vulnerability scanning and exploitation through LLM reasoning; PentestGPT reported an 86.5% success rate (90/104) on the XBOW validation benchmark. AI-guided fuzzing (Google's OSS-Fuzz with LLM seed generation and Fuzz Introspector) mutates inputs using semantic understanding of the target, surfacing bug classes that pure coverage metrics miss. A 2025 SANS survey found 67% of red-team operators now use at least one AI-assisted tool, up from 18% in 2023.

AI as the target — AI red-teaming. A brand-new test discipline has formed around LLM apps. The OWASP Top 10 for LLM Applications (2025) ranks Prompt Injection as LLM01 — because models read instructions and data on the same channel, attacker text can hijack behaviour. Jailbreaks (bypassing safety guardrails) and Sensitive Information Disclosure (data leakage) round out the high-priority risks. The OWASP Gen AI Red Teaming Guide (Jan 2025) and NIST AI 100-2 e2025 (Mar 2025, adversarial-ML taxonomy) plus NIST AI 600-1 now make red-teaming an expected control. Open frameworks like NVIDIA Garak and Microsoft PyRIT automate these probes at scale.