Assessment, testing and audit strategies

Security controls are promises. A firewall rule promises that only certain traffic gets through, an access review promises that leavers lose their accounts, a backup schedule promises that data can be restored. Security assessment and testing is the discipline that checks whether those promises are kept. It turns assumptions into evidence, and evidence into decisions that managers, auditors, regulators and customers can rely on. An organization that never tests its controls does not know its risk; it only knows its intentions.

Domain 6 of the CISSP, Security Assessment and Testing, carries about 12 % of the exam weight under the outline ISC2 has used since 15 April 2024 (checked October 2026; ISC2 had announced no replacement, but outlines are reviewed through a job task analysis roughly every three years, so confirm before you book). It has five sub-domains: 6.1, design and validate assessment, test and audit strategies; 6.2, conduct security control testing; 6.3, collect security process data; 6.4, analyse test output and generate reports; and 6.5, conduct or facilitate security audits. This course is independent study material. It is not produced, endorsed or reviewed by ISC2, and none of its questions are taken from any real exam. Every scenario is original and written to train the judgement the exam rewards.

The domain is managerial at heart. The exam rarely asks you to run a tool; it asks you to choose the right kind of assessment for a goal, to scope and authorize it properly, to judge whether evidence is sufficient, and to report results in a way that leads to action. Throughout this course, technical detail is there to support those decisions. Penetration testing in particular is described at the level of methodology, authorization and reporting, never as attack instructions.

Assessment, testing and audit: three related ideas

The three words are often used loosely, but the distinctions matter on the exam and in practice. A test is a specific procedure that checks whether a control behaves as intended: a vulnerability scan, a restore of a backup, an attempt to log in with a disabled account. An assessment is a broader evaluation that combines tests, interviews and document review to form a judgement about a set of controls or a system, often against a risk-based question such as whether the controls are adequate for the data being processed. An audit is a formal, independent examination of whether an organization complies with a defined set of criteria, such as a standard, a contract, a regulation or its own policy, performed by someone who is independent of the activity being audited and resulting in a formal opinion or report.

A useful rule of thumb is that tests produce data, assessments produce judgements about risk, and audits produce opinions about conformance. A penetration test that finds an exploitable weakness is a test. A risk assessment that combines that finding with asset value and threat information is an assessment. A SOC 2 examination that concludes whether controls met the Trust Services Criteria over a period is an audit-type engagement. All three appear in Domain 6, and the exam often asks you to pick the one that fits a stated objective.

Internal, external and third-party assessments

Assessments are also classified by who performs them and for whom. The CISSP outline uses three categories: internal, external and third-party. Each has a different balance of knowledge, independence and cost.

An internal assessment is performed by the organization's own staff, such as the security team, internal audit or a control owner testing their own processes. Internal staff know the environment, are available continuously and cost less per hour, so internal testing is ideal for frequent, routine checks such as monthly vulnerability scans or quarterly access reviews. The weakness is independence. People rarely find serious flaws in systems they designed, and internal results carry less weight with outsiders. Internal audit departments gain some independence by reporting to the board's audit committee rather than to the managers whose areas they audit.

An external assessment is performed by a party outside the organization that the organization itself hires, such as a consulting firm engaged to run a penetration test or a gap assessment against ISO/IEC 27001. External assessors bring fresh eyes, specialist skills and greater independence, and their reports are more persuasive to boards. They are more expensive, need time to learn the environment, and must be managed carefully: they need authorization, scope, access and supervision.

A third-party assessment is performed by an outside party on behalf of, or to satisfy, someone other than the organization being assessed. Examples include a customer's auditor examining a cloud provider, a payment card Qualified Security Assessor issuing a Report on Compliance for a card brand, a regulator's examination, or a certification body auditing for ISO/IEC 27001 certification. The term is also used for assessing your own suppliers: when your organization evaluates a vendor's controls, you are performing a third-party (or vendor) risk assessment. Some textbooks reverse the labels, so read each question carefully and decide who performs the work and who relies on the result.

Strategy before tools

Sub-domain 6.1 asks you to design and validate strategies, not merely to run tests. A testing strategy answers a set of questions before any scanner is launched. What are we trying to learn, and who needs to know? Which assets and controls matter most, given the organization's risks? Which requirements apply, from laws, contracts and standards? How often must each control be tested, and how independent must the tester be? What will we do with the results, and who owns remediation? A strategy that cannot answer the last question produces reports that nobody reads.

Good strategies are risk-based. They test the most important controls on the most valuable assets most often and most rigorously, and accept lighter testing elsewhere. They also combine methods, because each method sees something the others miss. Automated scanning gives breadth and frequency; manual testing gives depth and creativity; reviews of configuration and documentation find design weaknesses that tests may never exercise; interviews reveal whether people actually follow the procedures on paper; and observation shows what really happens at a help desk or a loading dock.

Testing frequency should match how quickly the risk changes. External attack surfaces change daily as cloud resources are created and destroyed, so many organizations scan them continuously. Internal networks may be scanned weekly or monthly. Penetration tests of major applications are commonly annual and after significant change, which is also what standards such as PCI DSS require. Disaster recovery plans are exercised at least annually, and access reviews are commonly quarterly for privileged accounts and semi-annually or annually for others. Continuous control monitoring, where tools check control status automatically every day, is increasingly expected for cloud environments and is central to the United States' FedRAMP 20x approach discussed in lesson 9.

Validating the strategy

Validation means confirming that the strategy itself is sound: that it covers the right scope, uses methods capable of detecting the problems that matter, and produces results that are accurate and actionable. A strategy can be validated by mapping planned tests to the organization's risk register and control framework to find gaps, by comparing coverage against an asset inventory, by reviewing past incidents to ask whether the tests would have caught them, and by having an independent party review the plan. A common validation finding is that testing covers only the systems on the official inventory, while the shadow IT and forgotten cloud accounts that attackers actually use go untested.

Another validation question is whether the tests are sensitive enough. A scan that runs without credentials sees only what is exposed on the network, and may miss most missing patches on the host. A phishing simulation that uses an obviously fake email measures nothing useful. A backup test that restores one file says little about whether a whole system can be rebuilt within the recovery time objective. Each test needs to be capable of failing; a test that always passes is not evidence of anything.

# How many of the risk register's top risks have at least one planned test?
risks = {
    'R1 ransomware on file servers': ['backup restore test', 'EDR detection test'],
    'R2 stolen admin credentials': ['privileged access review'],
    'R3 exposed cloud storage': [],
    'R4 payment page tampering': ['quarterly ASV scan', 'annual penetration test'],
    'R5 insider data theft': [],
    'R6 supplier compromise': ['vendor SOC 2 review'],
}
covered = [r for r, tests in risks.items() if tests]
gaps = [r for r, tests in risks.items() if not tests]
print(f'Coverage: {len(covered)}/{len(risks)} top risks have a planned test ({len(covered)/len(risks):.0%})')
for g in gaps:
    print('GAP:', g)

Coverage: 4/6 top risks have a planned test (67%)
GAP: R3 exposed cloud storage
GAP: R5 insider data theft

The output shows two of six top risks with no planned test at all. Exposed cloud storage would call for continuous configuration scanning of cloud accounts, and insider data theft might call for testing data loss prevention rules and reviewing access to sensitive repositories. Mapping tests to risks in this way is a simple but powerful validation technique, and it gives management a clear coverage figure.

Independence, objectivity and conflicts of interest

Independence is the quality that makes assessment results trustworthy. An assessor is independent when they have no responsibility for designing, operating or managing the thing they assess, and no personal or financial interest in the outcome. Audit standards treat independence as a requirement, not a preference. A firm that implemented a company's security program should not then issue the opinion on it, and an internal auditor who used to run the IT department should not audit it for a cooling-off period. Objectivity is the related state of mind: assessing evidence fairly without bias toward a desired answer.

In practice, organizations use a three lines model to separate roles. Operational management, the first line, owns and operates controls and performs self-assessment. Risk and compliance functions, the second line, set policy, monitor and challenge. Internal audit, the third line, provides independent assurance to the board. External auditors and regulators sit outside these lines. When a question asks who should perform a test for maximum objectivity, the answer usually moves outward along this chain.

Lesson 2 turns to the practical work of designing an individual assessment: scoping it, agreeing rules of engagement and obtaining written authorization, which is both a legal necessity and a safety control.