CISSP Domain 6: Security Assessment, Testing, and Audits

Introduction

CISSP security assessment and testing turns control objectives into evidence that management can use. This lesson covers all of Domain 6, Security Assessment and Testing (12% of the exam, ISC2 exam outline effective 15 April 2024): design and validate assessment, test, and audit strategies (6.1); conduct security control testing (6.2); collect security process data (6.3); analyze test output and generate reports (6.4); and conduct or facilitate security audits (6.5).

Controls that are never tested are assumptions. Assessment and testing turn assumptions into evidence, tell management whether risk is within appetite, and feed the improvement cycle. After this lesson you can decide which kind of test fits a goal, who should perform it, how to run it safely, and how to report results so that the business acts on them.

Learning objectives

After this lesson you can:

1. Design an assessment, test, and audit strategy using internal, external, and third-party options.
2. Compare vulnerability assessments, penetration tests, red team exercises, and breach and attack simulation.
3. Select appropriate test techniques: log reviews, synthetic transactions, code review and testing, misuse case testing, coverage analysis, interface testing, and compliance checks.
4. Collect and interpret security process data: KPIs, KRIs, account management data, backup verification, training and awareness metrics, and DR/BC results.
5. Analyze findings, prioritize remediation, handle exceptions, and write reports for technical and executive audiences.
6. Explain the audit process and the differences among SOC 1, SOC 2, SOC 3, ISO/IEC 27001 certification, and internal, external, and third-party audits.

1. Designing and validating assessment, test, and audit strategies

1.1 Assessment, test, and audit: three different things

These activities overlap. Assessments can combine examination, interviews, and testing; tests can exercise technical or procedural controls; audits evaluate evidence against defined criteria and require appropriate independence. NIST SP 800-53A provides tailored control assessment procedures.

1.2 Who performs it

These labels are not mutually exclusive: an external firm can perform an independent third-party assessment, or a customer-directed supplier review. Choose independence according to the audience. Management wants quick feedback (internal), the board wants assurance (external or internal audit reporting to the audit committee), and regulators or customers want attestation (third party).

1.3 Building the strategy

A good strategy ties testing to risk and business needs:

1. Define objectives: compliance, risk reduction, release readiness, incident learning.
2. Scope assets and systems: crown jewels, internet-facing systems, new releases, critical third parties.
3. Set frequency: continuously (monitoring), per change (pipeline tests), periodically (annual penetration test, quarterly scans).
4. Select methods and roles: automated scanning plus manual expert testing.
5. Define rules of engagement (RoE): authorized targets, time windows, forbidden actions (denial of service, social engineering of executives), data handling, emergency contacts, and a stop condition.
6. Obtain written authorization. Testing without valid authorization may violate computer-misuse laws, contracts, or provider terms. Confirm authority over each target and applicable rules, including cloud-provider testing conditions.
7. Define reporting, remediation tracking, and retest criteria.

Validate the strategy itself: does it cover the control objectives, are results used, is coverage meeting the risk assessment, and are tests keeping pace with changes in the environment?

1.4 Testing in the lifecycle

Security tests belong in every phase: design (threat modeling, architecture review), development (static analysis, code review), integration (dynamic testing, fuzzing), release (penetration test), operations (vulnerability scanning, monitoring), and retirement (media sanitization checks). Finding a flaw during design is far cheaper than finding it in production.

2. Conducting security control testing

2.1 Vulnerability assessment

A vulnerability assessment identifies weaknesses with automated scanners, then ranks them. Key distinctions:

• Authenticated (credentialed) scans log in and see patch levels and configuration, producing fewer false positives and deeper results. Unauthenticated scans see what an outsider sees.
• Network scans, host-based scans, web application scans, database scans, and container/image scans have different tools.
• Passive (traffic observation) vs active (probing) scanning: active scanning can disrupt fragile systems and needs scheduling.
• False positives (reported but not real) and false negatives (real but missed) must both be managed. Validate high-severity findings before escalating.
• Scoring: CVSS rates severity, not a complete organizational risk score. EPSS estimates the probability of observed exploitation in the next 30 days; CISA KEV records known exploitation. Combine these distinct signals with asset criticality, exposure, and compensating controls. A low EPSS value does not cancel confirmed exploitation or an applicable remediation deadline.

2.2 Penetration testing

A penetration test actively exploits weaknesses to show real impact. Knowledge levels:

Tester knowledge and defender awareness are separate dimensions. Limited-knowledge testing may be called blind; a double-blind exercise also restricts notice to defenders, apart from a small authorized coordination team. Terminology varies across methodologies: state exactly what testers know and who is informed in the rules of engagement.

Typical activities: planning, discovery, controlled attack or exploitation, and reporting with cleanup. NIST SP 800-115 groups penetration testing into planning, discovery, attack, and reporting; other methodologies divide them differently. Persistence demonstrations require explicit authorization and are not mandatory in every test. Testers follow methodologies such as NIST SP 800-115, the OWASP Web Security Testing Guide, PTES, and OSSTMM.

Key safety points: never go beyond scope; handle sensitive data minimally; stop and notify if a critical production risk appears; remove tools and test accounts afterwards.

2.3 Red team, blue team, purple team, and BAS

• Red team: an adversary simulation with a goal (steal a given dataset) across technology, people, and physical access; tests the whole defense including detection.
• Blue team: defenders, who detect and respond.
• Purple team: collaborative exercise in which red and blue share techniques and tune detections in real time.
• Breach and attack simulation (BAS): automated tools that replay configured attacker techniques within an authorized scope (often mapped to MITRE ATT&CK) to verify whether controls detect or block them. Validate safety settings and potential production impact; automation does not guarantee safe execution.
• Bug bounty: external researchers are rewarded for reported vulnerabilities under published rules.

2.4 Log reviews and monitoring checks

Log reviews verify that events are generated, collected, protected, and examined. Test that critical systems send logs, that time is synchronized, that collected records have access separation and tamper protection against administrators of the monitored systems, and that alerts reach people who act on them. Automated correlation (SIEM) supports this, but reviewers still sample for gaps.

2.5 Synthetic transactions and real user monitoring

• Synthetic transactions (synthetic monitoring): scripted transactions run against the system to confirm availability and correct behavior, for example logging in and completing a checkout every five minutes from multiple regions.
• Real user monitoring (RUM): passively measures actual user experience.

Synthetic tests are proactive (they detect problems before users complain) and repeatable; RUM shows real conditions.

2.6 Code review and testing

Mutation-based fuzzing changes existing seed inputs; generation-based fuzzing constructs inputs from a model or grammar. Mutation can be blind or structure-aware; it is not necessarily “smart.”

Combine these techniques with secure software development practices rather than treating any scanner as proof that an application is secure.

2.7 Misuse case testing, test coverage, and interface testing

• Misuse (abuse) case testing: starts from how an attacker would use a feature and writes tests for it, the negative counterpart of use cases.
• Test coverage analysis: measures how much of the code, requirements, or attack surface tests exercise, as a percentage (statement, branch, or requirements coverage). High coverage does not prove quality, and low coverage highlights untested portions that need risk-based review.
• Interface testing: tests APIs, user interfaces, and system-to-system connections, including boundary values and error handling.
• Compliance checks: automated configuration baselines (such as CIS benchmarks via SCAP tools) that compare systems with required settings.

2.8 Testing specific control areas

2.9 Worked example: choosing a test

Scenario. Lumen Health is launching a patient web portal in six weeks. The board asks whether an attacker could reach patient data. The development team already runs SAST on every commit. The security manager has a budget for one external activity and wants evidence that is credible to regulators.

Reasoning.

1. SAST covers source code but not the deployed configuration, the cloud environment, or business logic flaws in the running portal.
2. A vulnerability scan identifies known weaknesses but does not prove exploitation or chain issues.
3. The board's question ("could an attacker reach patient data?") is answered best by a penetration test, performed by an independent third party for credibility, against the production-like environment before launch.
4. Rules of engagement: authorized targets (portal, APIs, supporting cloud tenant), a gray-box approach with test patient accounts to maximize coverage in limited time, no denial of service, data exposure handled according to policy.
5. Findings feed a retest before go-live.

Solution. A gray-box penetration test by an independent firm, preceded by an authenticated vulnerability scan to clear known issues so the testers' time focuses on logic and chaining.

Why not the alternatives? A red team exercise tests detection and response across people and physical access and is more than needed for a pre-launch question. A BAS tool validates detections, not application logic. More SAST adds little because the question concerns the deployed system.

3. Collecting security process data

Security process data shows whether the management system is operating. Collect it from tools and records, not memory.

3.1 What to collect (6.3)

3.2 KPIs and KRIs

• A key performance indicator (KPI) measures how well a process performs (percent of systems patched within SLA).
• A key risk indicator (KRI) signals rising risk before an incident (number of internet-facing systems with critical vulnerabilities older than 30 days).
• Good metrics are specific, measurable, tied to objectives, automatically collected where possible, and understood by their audience. Beware vanity metrics such as the number of blocked connections, which tell little about risk.

3.3 Data quality and handling

Test data and logs may contain sensitive information; protect and retain them as evidence. Ensure completeness (all scope covered), accuracy (calibrated tools), timeliness, and chain of custody when data may support disciplinary or legal action. Continuous monitoring (NIST SP 800-137) adds ongoing visibility at risk-based frequencies; periodic assessments and independent audits still serve distinct purposes. Account-management evidence should test the joiner, mover, and leaver lifecycle, including issued sessions and tokens.

4. Analyzing test output and generating reports

4.1 From raw findings to decisions

1. Normalize and validate: remove duplicates and false positives, confirm critical findings.
2. Contextualize: consider asset value, exposure, exploitability, existing controls, and regulatory impact.
3. Prioritize: use risk (likelihood and impact), not severity score alone. A medium-severity flaw on an internet-facing payment system may outrank a critical one on an isolated lab server.
4. Assign owners and deadlines: unowned findings never get fixed.
5. Decide treatment: remediate, mitigate with compensating controls, transfer, or accept.
6. Track to closure and retest.

4.2 Exceptions and risk acceptance

When a finding cannot be fixed on time (legacy system, vendor delay), record a formal exception: justification, compensating controls, an accountable risk owner with authority (business or executive, not the security tester), expiry date, and review. Exceptions without an expiry become permanent hidden risk.

4.3 Writing the report

A good report states scope, method, limitations, findings ranked by risk, evidence, recommendations, and responsible parties. Reports are sensitive, so classify and restrict distribution.

4.4 Ethical and legal reporting

Report findings honestly even when unwelcome; do not hide or soften material issues. When illegal activity is discovered (for example child exploitation material during testing), follow legal obligations and organizational procedures. Disclose vulnerabilities in third-party products using responsible (coordinated) disclosure.

4.5 Worked example: prioritizing a scan result

Scenario. A quarterly scan returns 1,200 findings. Among them: (a) a critical remote code execution flaw (CVSS 9.8) on an internal print server with no inbound access from the internet and no sensitive data; (b) a high-severity (CVSS 7.5) flaw on the internet-facing customer authentication gateway, listed as actively exploited in the CISA catalog; (c) a medium finding on 300 laptops (outdated browser plug-in); (d) a low-severity information disclosure banner on 40 servers.

Reasoning.

1. (b) combines exposure, a business-critical asset, and active exploitation: top priority despite a lower CVSS score.
2. (a) is critical technically. Lack of direct internet exposure reduces one attack path but does not prove isolation; check internal reachability, privileged service accounts, and lateral movement before deciding urgency.
3. (c) is widespread, so it goes through automated patching in normal cycles; endpoints are common entry points, so it is not ignored.
4. (d) is batch-fixed during hardening.

Solution order: b, then a, then c, then d. The report to management states the top five risks, owners, and dates, with the rest tracked in the ticketing system.

Why not sort by CVSS alone? A severity score is not a complete risk assessment. Sorting only by the supplied scores would put a server without direct internet exposure ahead of an actively exploited authentication gateway. Reassess if internal compromise or privileged dependencies change the facts.

5. Conducting and facilitating security audits

5.1 Audit types

5.2 The audit process

1. Scope and objectives are agreed, with audit criteria (standard, law, or policy).
2. Planning: risk-based audit plan, schedule, auditors' independence and competence verified.
3. Fieldwork: interviews, document review, observation, sampling, technical testing, evidence collection.
4. Evidence evaluation: evidence must be relevant, reliable, and sufficient.
5. Findings and reporting: draft findings are discussed with management for factual accuracy, then a report states conclusions and recommendations.
6. Follow-up: management responses, corrective action plans, and verification.

Auditor independence and objectivity are fundamental: auditors must not audit their own work, and conflicts of interest must be disclosed. The audit charter and agreement must provide sufficient authorized access to people, records, and systems within scope, subject to lawful handling and agreed safeguards. Auditors should report to a level that can act on findings, such as the audit committee.

5.3 Attestation reports: SOC and ISO

For vendor due diligence, a SOC 2 Type 2 report from an independent CPA firm is usually stronger evidence than a self-assessment questionnaire or a Type 1 report. Always check the scope (which services and locations are covered), the period, and the exceptions noted. Review complementary user entity controls (CUECs), which are controls the customer must run for the provider's controls to be effective.

5.4 Facilitating audits

Security professionals support audits by preparing evidence in advance, assigning a single coordinator, answering truthfully, and not altering records. They track audit findings to remediation and use the results to improve controls. Common frameworks and criteria include ISO/IEC 27001 and 27002, NIST Cybersecurity Framework and SP 800-53, PCI DSS, HIPAA, and COBIT.

5.5 Worked example: choosing assurance for a cloud provider

Scenario. Quillon Finance wants to store customer financial data with a new SaaS analytics vendor. The vendor offers a self-completed security questionnaire, a SOC 2 Type 1 report from last year, and a SOC 2 Type 2 report covering the last nine months with two noted exceptions in access reviews.

Reasoning.

1. The questionnaire is self-attestation with no independent verification.
2. Type 1 only shows that controls were suitably designed at one date.
3. Type 2 tests operation over a period, performed by an independent auditor. It is the best evidence.
4. Exceptions are not disqualifying, but access review failures matter for financial data. Ask for the management response and remediation evidence, and verify that the complementary user entity controls are implemented at Quillon.

Solution. Rely on the Type 2 report, review scope and exceptions, request remediation evidence, include audit rights and breach notification in the contract, and schedule periodic reassessment.

6. Mini case study

Scenario. Vantor Logistics completed its first annual penetration test. The report found 3 critical, 12 high, and 40 medium issues. Management asks: "Are we secure now?" Six months later, an external attacker accesses the customer database through a flaw rated medium in the test, in a legacy web service that was marked "exception, accepted by IT manager" with no expiry date. Meanwhile the quarterly phishing simulation shows a 4% click rate, and the last backup restoration test was 2 years ago. The audit committee requests a review of the testing program.

Task. Identify the weaknesses in the program and recommend improvements.

Commented solution.

1. Point-in-time view: one annual test is a snapshot. Add continuous vulnerability management, tests per release, and BAS or purple team exercises to validate detection.
2. Risk prioritization: the medium finding was on an internet-facing system holding customer data. Prioritize by context, not label alone.
3. Exception governance: the exception was accepted by an IT manager without authority for business risk and had no expiry or compensating controls. Require the business risk owner, an expiry date, compensating controls, and periodic review.
4. Backup verification: restoration has not been tested for two years. Set risk-based restore-test frequencies, including after significant changes, and compare measured recovery time and recoverable data age with RTO and RPO. Quarterly tests can be a local policy choice, not a universal requirement.
5. Metrics: a 4% click rate alone is not enough; track report rate, repeat clickers, and time to report, plus KRIs such as overdue critical vulnerabilities.
6. Reporting: give executives a risk-based summary and track remediation to closure with retests.

The report cannot establish that the organization is secure in every circumstance. It provides bounded evidence of risk; follow-up testing must check remediation and changing conditions. Use protected operational logs and monitoring to retain the evidence needed between assessments.

7. Common pitfalls and exam tips

• Exam tip: the first action before any penetration test is written authorization and defined scope (rules of engagement).
• Pitfall: mistaking a vulnerability scan for a penetration test. Scans identify; penetration tests exploit.
• Exam tip: credentialed scans give more accurate results and fewer false positives than uncredentialed ones.
• Exam tip: SAST analyzes code without executing it; DAST tests a running application; IAST uses instrumentation; SCA examines third-party components.
• Pitfall: prioritizing only by CVSS. Add exposure, asset value, exploitability, and compensating controls.
• Exam tip: SOC 2 Type 2 shows operating effectiveness over a period; Type 1 shows design at a point in time; SOC 3 is public.
• Exam tip: auditors must be independent; the best vendor assurance comes from an independent audit, not self-assessment.
• Exam tip: reports must be tailored: executives need risk and decisions, technical teams need detail.
• Pitfall: accepting risk without an authorized owner or expiry date.
• Exam tip: when a test might disrupt production, coordinate timing, set a stop condition, and keep emergency contacts ready.

Key terms

• Rules of engagement (RoE): the written boundaries and procedures for a test.
• Vulnerability assessment / penetration test: identify weaknesses / exploit them to show impact.
• Black, gray, white box: zero, partial, full tester knowledge.
• Red, blue, purple team: attackers, defenders, collaborative exercise.
• BAS: breach and attack simulation.
• SAST / DAST / IAST / SCA: static, dynamic, interactive testing, and component analysis.
• Fuzzing: testing with malformed or random inputs.
• Synthetic transaction: scripted transaction used to monitor service health.
• KPI / KRI: performance and risk indicators.
• SOC 1/2/3, Type 1/2: service organization attestation reports and their depth.
• CUEC: complementary user entity control.

Summary checklist

• I can distinguish assessments, tests, and audits and choose internal, external, or third-party performers.
• I can describe rules of engagement and the penetration test phases and knowledge levels.
• I can compare vulnerability scans, penetration tests, red teams, purple teams, and BAS.
• I can choose between SAST, DAST, IAST, SCA, fuzzing, and code review.
• I can define KPIs and KRIs and name the data that proves the program works.
• I can prioritize findings by risk and manage exceptions properly.
• I can tailor a report to executives, technical teams, and auditors.
• I can compare SOC 1, SOC 2, SOC 3, Type 1 and Type 2, and ISO/IEC 27001 certification.

Official sources

• ISC2 CISSP exam outline: https://www.isc2.org/certifications/cissp/cissp-certification-exam-outline (opens in a new tab)
• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment: https://csrc.nist.gov/pubs/sp/800/115/final (opens in a new tab)
• NIST SP 800-137, Information Security Continuous Monitoring: https://csrc.nist.gov/pubs/sp/800/137/final (opens in a new tab)
• OWASP Web Security Testing Guide: https://owasp.org/www-project-web-security-testing-guide/ (opens in a new tab)
• AICPA SOC suite of services: https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services (opens in a new tab)
• AICPA SOC 3 general-use reports: https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-3 (opens in a new tab)
• NIST SP 800-53A Rev. 5, control assessments: https://csrc.nist.gov/pubs/sp/800/53/a/r5/final (opens in a new tab)
• OWASP static analysis limitations: https://owasp.org/www-community/controls/Static_Code_Analysis (opens in a new tab)
• CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (opens in a new tab)
• FIRST, CVSS and EPSS: https://www.first.org/cvss/ (opens in a new tab) and https://www.first.org/epss/ (opens in a new tab)