CISSP Domain 6 Revision: Security Assessment and Testing

Domain 6 is the smallest domain by exam weighting, which tempts some candidates into under-preparing for it. That's a mistake. The concepts here are precise, the terminology is frequently paired in ways designed to confuse, and the domain connects directly into governance reporting from Domain 1, so a shaky grasp here tends to show up as lost marks elsewhere too.

Designing and validating assessment, test and audit strategies

Before any testing happens, an organisation needs to decide who is doing it and from where. This objective is really about scope and independence.

Internal assessments are conducted by staff within the organisation, useful for frequent, low-friction checks but carrying an inherent independence limitation, since the people testing the environment may have a stake in its results looking favourable.

External assessments are conducted by parties outside the organisation but still, in some framings, working close to or on behalf of it, offering more independence than a purely internal review.

Third-party assessments go further, conducted by an entity entirely outside the enterprise's control, often required contractually or by regulation, and carrying the strongest claim to independence of the three.

Location matters as its own dimension, since testing on-premises, in the cloud, or across a hybrid environment each carries different constraints. Cloud testing, in particular, usually requires prior authorisation from the cloud provider before certain types of testing, penetration testing especially, can legally be carried out.

Conducting security control testing

This objective lists the actual techniques, and the exam likes to test which technique fits which purpose rather than asking for definitions alone.

Vulnerability assessment identifies known weaknesses, typically through automated scanning against a database of known vulnerabilities, without attempting to exploit them.

Penetration testing goes further, actively attempting to exploit identified weaknesses to demonstrate real-world impact. The red, blue and purple team structure is worth knowing precisely: red team attacks, blue team defends, and purple team is the collaborative arrangement where both sides work together, sharing findings in real time to improve detection and response rather than treating the exercise purely as a pass or fail test.

Log reviews examine existing system and application logs for evidence of anomalous activity, an inexpensive technique compared with active testing, but entirely dependent on logging having been configured properly in the first place.

Synthetic transactions and benchmarks simulate real user activity against a system to measure performance and detect issues before genuine users encounter them, useful for both security monitoring and general system health.

Code review and testing examines source code directly, either manually or through automated tooling, to catch vulnerabilities before software reaches production, connecting directly to the application security testing covered later in Domain 8.

Misuse case testing deliberately tests how a system responds to intentional misuse rather than normal expected use, the security equivalent of asking what happens when someone tries to break the rules rather than follow them.

Coverage analysis measures how much of a system, or how much of its code, has actually been exercised by testing, since a test suite that never reaches certain code paths provides false confidence about the security of those unexercised paths.

Interface testing covers user interfaces, network interfaces and APIs specifically, recognising that each interface type represents a distinct attack surface with its own testing considerations, an API accepting malformed input behaves very differently from a web form doing the same.

Breach and attack simulation automates the continuous testing of security controls against known attack techniques, offering more frequent validation than a periodic penetration test can realistically provide.

Compliance checks verify a system or process against a specific regulatory or contractual standard, distinct from vulnerability testing in that the benchmark is a defined requirement rather than a general security posture.

Collecting security process data

This objective is about gathering the evidence that assessment and reporting depend on, and it spans both technical and administrative sources.

Account management data shows whether access reviews and provisioning processes from Domain 5 are actually being followed in practice, rather than existing only on paper. Management review and approval records demonstrate governance oversight is genuinely happening rather than being assumed. Key performance and risk indicators translate raw security activity into metrics a board can actually interpret. Backup verification data confirms that backups aren't just being taken but are actually restorable, which is a distinction organisations discover the hard way more often than the exam's phrasing might suggest. Training and awareness data measures whether the programme from Domain 1 is producing a measurable change in behaviour. Disaster recovery and business continuity data confirms plans have been tested rather than simply written and filed away.

The theme across all of these categories is the same: security process data exists to prove that controls are operating as intended, not simply that they were designed correctly at some point in the past.

Analysing test output and generating reports

Collecting data is only useful if it leads somewhere, and this objective covers what happens next.

Remediation addresses identified weaknesses directly, and the exam expects an understanding that remediation needs prioritisation, since not every finding can or should be fixed with equal urgency.

Exception handling covers situations where a finding can't be remediated immediately, or perhaps ever, due to business constraint, and the process needs a formal, documented acceptance of that residual risk rather than an informal decision to simply ignore it, echoing the risk acceptance option from Domain 1.

Ethical disclosure governs how vulnerabilities are communicated, particularly when a third party or external researcher discovers them. Coordinated, responsible disclosure gives an affected organisation reasonable time to remediate before details become public, balancing the researcher's right to credit and transparency against the practical risk of publishing an exploitable flaw before a fix exists.

Conducting or facilitating security audits

The final objective in the domain mirrors the internal, external and third-party structure from the opening objective, but applied specifically to formal audit activity rather than general testing.

An internal audit, conducted by an organisation's own audit function, tests compliance against internal policy and, increasingly, external regulatory requirements, but its independence is naturally more limited than an audit conducted by an outside party. An external audit brings a greater degree of independence and is often required for specific certifications or regulatory attestations. A third-party audit, again the most independent of the three, is frequently mandated by contract, a customer requiring evidence of a vendor's security posture before entrusting them with data, for instance.

Location, on-premises, cloud, or hybrid, shapes audit scope and methodology here just as it does for testing generally, and cloud audits in particular often rely on the provider's own third-party attestations, SOC 2 reports being the most commonly referenced example, rather than direct access to the provider's own infrastructure.

Where AI now sits in Domain 6

Testing has had to grow a new branch to cover AI models specifically. Red teaming an AI system means probing for evasion, tricking a model into misclassifying something it should catch, and extraction, attempting to reconstruct a model's training data or internal logic from its outputs. Neither of these fits neatly into the vulnerability assessment or penetration testing categories as originally conceived, since the target isn't a piece of software with a conventional bug but a model whose failure mode is a flaw in its own reasoning rather than its code.

AI cuts the other way in this domain too, automating parts of the vulnerability management lifecycle by prioritising remediation against live threat intelligence rather than a static severity score. The effect is to push security assessment toward something closer to continuous testing than the periodic point-in-time exercise the domain has traditionally assumed, a shift worth bearing in mind given how much of Domain 6 is built around scheduled testing and audit cycles.

Final thought for revision

Domain 6's small size on the exam blueprint doesn't mean its questions are easy. The domain rewards candidates who can distinguish closely related concepts under pressure: vulnerability assessment against penetration testing, internal against external against third-party, remediation against exception handling. Spend revision time specifically on these pairings, since a scenario question here is far more likely to test the boundary between two similar terms than to ask for a definition of either one alone.