A test gathers raw evidence. An assessment interprets many tests into posture and recommendations. An audit is independent verification against a standard or criterion. Vulnerability assessment lists possible weaknesses. A penetration test proves one path is exploitable. SOC 1 is about financial reporting controls. SOC 2 uses the Trust Services Criteria (security plus optional availability, processing integrity, confidentiality, privacy). SOC 3 is the general-use summary. Type I = design as of a date. Type II = operating effectiveness over a period. Domain 6’s official weight is 12% — that is the only exam percentage this page uses.
A scan is a list. A pen test is a story from one day. An audit is an independent opinion. Type II is the period. If I cannot show the control operated, I have not finished Domain 6 work.
1. Why a green scan is not assurance
Interview, 35 minutes in. “Enterprise customer will not sign until you prove access control and change management worked for the last financial year. What do you send FIRST?” The engineer brain attaches last Friday’s scan and a clean pen-test slide. The CISSP brain asks: who is independent, what criterion, and over what window?
ISC2 Domain 6 — Security Assessment and Testing — is 12% of the official April 2024 exam outline. The five objectives are the spine of this page: design the strategy (6.1), conduct control testing (6.2), collect process data (6.3), analyze output and report (6.4), conduct or facilitate audits (6.5). The outline is not asking you to love Nessus. It is asking whether you can produce assurance.
Three reasons this domain fails strong operators:
- Tool output is not an opinion. A scanner lists possible CVEs. It does not say the control is effective, and it does not carry independence.
- Point-in-time is not a period. Pen tests, Type I reports, and one-day tabletop exercises answer “as of.” Type II, sampled tickets, and continuous log review answer “throughout.”
- Coverage hides in the scope sentence. “All green” on the web tier is not a finding if the API and the identity plane were never in the rules of engagement.
Assurance — justified confidence that a control is designed, implemented, and operating. Not a synonym for “we ran a tool.”
Independence — how much the reviewer is under the auditee’s control. Official 6.1 / 6.5: internal (within organization control), external (outside organization control), third-party (outside of enterprise control).
Design effectiveness — the control, as specified, could meet the criterion. Type I lives here.
Operating effectiveness — the control ran as designed across the period, with sampled evidence. Type II lives here.
Rules of engagement (RoE) — written scope, timing, forbidden actions, and emergency stop, agreed before any exploit attempt.
Coverage analysis — how much of the in-scope system the tests actually touched (objective 6.2). Green on an untested tier is a coverage miss, not a clean bill.
2. Mental model · test, assess, audit
Hold three parts. Interviews fail when people treat “audit,” “assessment,” and “pen test” as three names for one scan, or treat a SOC logo as a certificate.
Part 1 · three words that are not synonyms
A test is data gathering. Did the patch close the port? Did the synthetic checkout finish in two seconds? NIST SP 800-53A’s methods are examine (artifacts), interview (people), and test (exercise the control). CISSP Domain 6 uses “test” the same way: raw evidence.
An assessment is expert interpretation of many tests. Vulnerability assessment, risk assessment, and a control-effectiveness review all sit here. The assessor can be internal. The output is posture plus recommendations, not a formal attestation.
An audit uses the same techniques but adds independence and a stated criterion (ISO 27001, a policy, AICPA Trust Services Criteria, a regulation). If the stem says “objective verification against a standard by reviewers with no stake,” the word is audit.
Test
Gather. Scan, exploit, examine a ticket, replay a backup, run a synthetic user. Output: data.
Assessment
Interpret. Combine tests, score coverage, recommend treatment. Output: report the business can act on.
Audit
Attest. Independent party vs a criterion. Output: opinion others will rely on.
Pen test (special test)
Prove impact. Goal-driven exploit under RoE. One path, one window — not a year of operating effectiveness.
Part 2 · independence is a ladder, not a vibe
Objectives 6.1 and 6.5 use the same three labels, plus location (on-premises, cloud, hybrid). The location clause exists because a cloud control you cannot see still has to be tested — often via the provider’s SOC plus your complementary user-entity controls.
Read left → right. Official outline words are on the cards. A SOC 2 you commissioned is typically external. A regulator-directed exam is third-party. Your own IA shop is internal.
Part 3 · design vs operating effectiveness
This is the Type I / Type II hinge and the whole point of “control effectiveness.” A beautifully written access-review procedure that nobody ran in Q3 is designed and dead. A sloppy procedure that operators followed every month, with tickets and screenshots, is operating — and an auditor will still write an exception if the design cannot meet the criterion.
NIST SP 800-53A assesses whether the control is implemented as specified and whether it is effective. AICPA Type II adds the period and the sample. CISSP stems that say “throughout the year” or “operated effectively” are hunting Type II / operating effectiveness, not a Friday scan.
Test gathers. Assessment interprets. Audit attests. Independence is who controls the reviewer. Type I is the photograph. Type II is the movie.
3. Decision flow · which proof do they need?
Draw this before you book a tester or attach a PDF. First name the question the stakeholder is actually asking. Then pick the method. Then pick the independence level. Last, pick the time window.
Read top → bottom. Diamond = decision. Green border = the artifact that usually closes an enterprise RFP. ISO 27001 certification is a different criterion — still an audit, not a SOC type.
“We are SOC 2 compliant.” SOC is an attestation report from a licensed CPA firm under AICPA standards, not a certificate you hang. A Type I dated last week does not prove last year’s operations. A SOC 3 on the website has no test detail a customer’s auditor can reuse.
4. How to choose VA, pen test, and SOC
Use the tables, then the official 6.2 menu. Vulnerability assessment and penetration testing are siblings, not rivals. Red / blue / purple are how you staff the exploit side. Black / white / grey box is well-known CBK for tester knowledge — NIST SP 800-115 talks the same idea as overt/covert and insider/outsider.
| If the ticket looks like… | Pick | Do not send |
|---|---|---|
| Enumerate known weaknesses across a large estate, fast, on a schedule. | Vulnerability assessment (credentialed where you can). Breadth. Expect false positives. | A three-day pen test billed as “full coverage.” |
| Prove a real attacker could chain to impact. Board wants a story, not a CVE dump. | Penetration test under signed RoE. Depth. Red team if stealth + objectives; purple if you want detections tuned live. | An unauthenticated scan renamed “red team.” |
| Zero prior knowledge, public app, mimic the internet. | Black-box pen test (well-known CBK). Official 6.2 still wants RoE first. | White-box “because coverage is better” when the stem asked for an outsider. |
| Partial knowledge — a standard user account, or a phished insider. | Grey-box. Highest exam frequency after black/white. | Calling it black-box because the tester is a vendor. |
| Full diagrams, source, creds. Maximize coverage before go-live. | White-box (crystal/clear). Pair with coverage analysis. | Skipping coverage just because you had source. |
| Customer / user-auditor needs security, availability, or privacy controls over a year. | SOC 2 Type II (Trust Services Criteria). Security is the required category. | SOC 1 (wrong subject). SOC 3 (no tests). Type I (no period). |
| Payroll / payments processor; question is ICFR for the user entity’s financials. | SOC 1 (AT-C 320 / SSAE 18 family). Type II if they need the year. | SOC 2 because “security sounds closer.” |
| Report | Subject | Audience | Type I vs Type II |
|---|---|---|---|
| SOC 1 | Controls relevant to user entities’ internal control over financial reporting. | User-entity management and their financial auditors. Restricted use. | I = design as of a date. II = design + operating effectiveness over a period. |
| SOC 2 | Trust Services Criteria: security (required), availability, processing integrity, confidentiality, privacy. | Informed users under NDA (customers, their auditors). Restricted use. | Same Type split. Type II includes tests of controls and results. |
| SOC 3 | Same TSC as SOC 2. | General use — the public seal / website version. | Opinion without the detailed tests. Cannot replace Type II evidence. |
Official 6.2 control-testing menu
Memorize the list as a toolkit, not a dump. Each row answers a different question.
Log reviews
Did the control fire in production? Need time sync (NTP), integrity, and correlation — collection alone is not a review.
Synthetic transactions / benchmarks
Scripted real-user journeys (checkout, login, quote) that prove availability and function before customers call.
Code review and testing
SAST reads source at rest. DAST probes the running app. Manual review catches business logic. Well-known CBK trio.
Misuse-case testing
Flip the use case: “attacker brute-forces login,” not “user logs in.” Abuse paths, not happy paths.
Interface testing
Outline names UI, network interface, and API. The untested microservice in Q1 of the quiz lives here.
Breach attack simulations + compliance checks
BAS / purple-style control validation vs a mapped threat. Compliance checks ask “does the artifact match the standard,” not “can I pop a shell.”
Red attacks under RoE. Blue detects and responds. Purple is not a third army — it is red and blue working the same scenario so findings become detections the same week. A fully autonomous “AI pentest” with no human review is not purple, and it is not an audit. The official outline’s Domain 6 AI note is red-teaming of models (evasion, extraction, logic flaws) plus AI-assisted vuln management — still under human accountability.
5. Runbook · Side A scope, B test, C report
This is not a vendor console path. It is the Domain 6 operating path you walk when a new system, a new SaaS, or a new model must be assured. Each side cites one primary source.
Side A · design the strategy (due diligence on scope)
Primary source: ISC2 outline 6.1 and NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (planning before discovery).
-
Name the asset, the criterion, and the audience
What must be true, for whom, against which standard? A bank RFP, an ISO surveillance audit, and an internal purple exercise are three different strategies. If nobody will name the criterion, stop — you are about to run a tool for sport.
-
Pick independence and location
Internal for frequent health. External (licensed CPA / certified body) when outsiders will rely. Third-party when the enterprise does not control the reviewer. On-prem, cloud, and hybrid each need a line in scope — including complementary user-entity controls on a SaaS SOC.
-
Write RoE and coverage before anyone scans
In-scope systems, out-of-scope (OT, prod payments, executive laptops), time window, data handling, emergency stop. Then state how you will measure coverage so an untested API tier cannot hide behind “all green.”
-
Map each control to a 6.2 method
VA for breadth. Pen test / BAS for impact. Logs and synthetics for operation. Code and interface tests for the build. Compliance checks for the criterion. One method is almost never the whole strategy.
Side B · conduct the tests
Primary source: NIST SP 800-53A Rev. 5 — examine, interview, test — and outline 6.2 / 6.3.
-
Examine artifacts
Policies, configs, access-review tickets, change records, backup-restore proofs, training completion, DR test minutes. Outline 6.3 names the process-data set: account management, management review and approval, KPIs/KRIs, backup verification, training and awareness, DR/BC.
-
Interview the people who operate the control
Owners, custodians, on-call. If the procedure says monthly access review and the owner says “we click through the tool,” that interview is a finding — do not wait for the sample to fail.
-
Test the control and the abuse path
Credentialed VA, then scoped exploit only inside RoE. Misuse cases and interface tests on the API the scanner never reached. For an LLM or scoring model, add robustness tests (evasion, extraction, prompt injection) — that is the official Domain 6 AI addition, not a blog fashion.
-
Keep a chain you can show
Who authorized the test, what was in scope, what was touched, what was found, what was immediately contained. Ethical disclosure (6.4) starts here: no dump of a live exploit to a public channel.
Side C · analyze, report, remediate
Primary source: ISC2 outline 6.4 (remediation, exception handling, ethical disclosure) and the AICPA SOC report structure for anything outsiders will rely on.
-
Separate possible from proven
VA findings stay “possible” until validated. Pen-test impact stays “this path, this day.” Do not let a 300-row critical list become the board slide.
-
Write exceptions the owner can sign
Risk, affected criterion, compensating control, expiry. An unsigned “we will watch it” is ignore — not an exception. Domain 1 residual-risk rules still apply.
-
Hand the right artifact to the audience
Internal assessment to the CISO. SOC 2 Type II (NDA) to the enterprise customer. SOC 3 to the website. Pen-test report to the people who can patch — not to a marketing PDF.
-
Disclose ethically
Vendor and in-house findings go through the agreed channel and timeline. Outline 6.4 lists ethical disclosure next to remediation on purpose: speed without dumping, and no silent shelf.
criterion = TSC Security (CC6 access) + change management window = 2025-04-01 .. 2026-03-31 independence = external CPA (SOC 2 Type II) methods = examine tickets + interview owner + test sample sample = 25 access reviews, 25 changes, 12 privileged joins coverage = web + API + IdP (no unscanned tier) exceptions = 1 late access review in Aug — remediated 2025-09-04 not_this_report = last week's Nessus, 3-day pen test
Scope, criterion, and audience are written. RoE and coverage exist before exploit. Each in-scope control has an examine / interview / test trail. Possible vs proven is labeled. Exceptions have owners and dates. The artifact matches the question (Type II for a year, pen test for a path, VA for a list).
6. Runtime path after the report
The report is Authorize-adjacent, not the end. Outline 6.3 is the continuous feed: account reviews, management approval, KPIs and KRIs, backup verification, awareness metrics, DR/BC evidence. A Type II next year is only possible if that feed stays on.
Read left → right. A new microservice, a model in production, or a failed sample sends you back to Side A. Acceptance of an exception expires when the facts change.
KPI vs KRI is well-known CBK sitting on official 6.3 (“key performance and risk indicators”). A KPI looks backward — percent patched, mean time to remediate, training completion. A KRI looks forward — exploitable vulns on crown-jewel assets, access reviews past due, unreviewed high-severity alerts. If the stem wants an early-warning metric, it is a KRI.
800-115’s technical-testing spine is Planning → Discovery → Attack → Reporting. Well-known CBK splits Discovery into recon + scanning/enumeration and Attack into exploitation + post-exploitation. Examiners test order. Do not start exploiting in Planning, and do not skip Reporting.
7. Traps + proof checklist
| Stem pattern | What ISC2 is testing | Engineer trap | Manager move |
|---|---|---|---|
| Independent reviewers vs a standard | Audit, not assessment (6.5). | Call every review an audit. | Independence + criterion = audit. |
| “Prove it worked all year” | Operating effectiveness / Type II. | Attach last week’s pen test or Type I. | Period-of-time sample. SOC 2 Type II for TSC. |
| 300 highs, 6 exploitable | VA vs pen test (6.2). | “The scanner is broken.” | Expected: list vs proven path. |
| All-green scan, live exploit in another tier | Coverage analysis (6.2). | Buy a new scanner. | Expand scope; add interface / pen test. |
| No creds, no diagrams, public app | Black-box (CBK knowledge level). | White-box “for quality.” | Match tester knowledge to the threat. |
| Checkout must stay < 2 seconds overnight | Synthetic transactions (6.2). | SAST or an account review. | Script the user journey; alert on fail. |
| Two vendors, both “SOC 2 compliant” | Type I vs Type II + exceptions. | Newest date wins; any exception loses. | Type II over a period beats a clean Type I. A remediated exception can be a healthy control. |
| Payroll processor, financial auditor asking | SOC 1 vs SOC 2 subject matter. | Send SOC 2 because it says Security. | ICFR → SOC 1. TSC / security → SOC 2. |
| Autonomous AI pentest, no human | Accountability + 6.4 disclosure. | “The model is the assessor.” | AI is a force multiplier. Humans own RoE, severity, and the opinion. |
- I can define test, assessment, and audit in one sentence each.
- I can rank internal / external / third-party with the official parentheticals.
- I can say why a pen test does not satisfy a Type II request.
- I can map SOC 1 / 2 / 3 and Type I / II without mixing subject and window.
- I can name three 6.2 methods besides “scan and pentest.”
- I can point to one KPI and one KRI on a system I have touched.
- I did not invent a subtopic exam percentage. Domain 6’s official weight is 12%.
Weak: “Domain 6 is vuln scans and pen tests, plus SOC 2.” Strong: “I start from the question. A test gathers, an assessment interprets, an audit attests. VA lists possibles; a pen test proves a path under RoE. If a customer needs operating effectiveness over a year I do not send Friday’s scan — I send a SOC 2 Type II (or the sampled evidence that will feed one). Coverage and independence are first-class. AI can accelerate testing; it does not sign the opinion.”
Knowledge check
Six judgment items. Map each one to a FIRST/BEST stem, not a definition. Check answers, then reset and retry the misses.
Sources
- ISC2 — CISSP Certification Exam Outline (effective 15 April 2024). Domain 6 weight 12%. Objectives 6.1–6.5 are the spine of this lesson. No other exam percentages are claimed.
- NIST — SP 800-115, Technical Guide to Information Security Testing and Assessment (planning, discovery, attack, reporting; rules of engagement).
- NIST — SP 800-53A Rev. 5, Assessing Security and Privacy Controls (examine, interview, test; control effectiveness).
- NIST — SP 800-92, Guide to Computer Security Log Management (review, integrity, time synchronization).
- AICPA & CIMA — SOC suite of services; SOC 2; SOC 3 general-use report; 2017 Trust Services Criteria (revised points of focus 2022).
- Well-known CBK (not an ISC2 percentage claim): black / white / grey box tester knowledge; SAST vs DAST vs manual review; KPI (lagging) vs KRI (leading); pentest mnemonic recon → scan → exploit → post-exploit → report as a split of SP 800-115 Discovery + Attack.
Related: CISSP overview (all 8 domains) · Domain 5: IAM · Domain 7: Security Operations · Domain 6 assessment · 8-week roadmap