CISSP 2024 Outline Final Review

ISC2's current CISSP Exam Outline is the version effective April 15, 2024. The exam remains broad by design: technical controls matter, but so do governance, ownership, legal duties, architecture, operations, software, and the people authorized to make each decision.

This page assumes the eight domain guides are already familiar. Use it to test whether the decision order is still fast enough for a scenario where several answers are technically reasonable.

1. How to use this final review

Treat each section as a recall test.

For a scenario, ask:

• What decision is actually being made? Governance, risk, architecture, access, testing, operations, or software?
• Who owns that decision? Business owner, data owner, system owner, custodian, management, legal, privacy, security, developer, auditor, incident commander, or another role?
• What must happen first? Establish authority, requirements, classification, scope, evidence, or business impact before implementation.
• What evidence would change the answer? A contract, risk assessment, asset classification, test result, log, recovery requirement, control objective, or approved change.
• Does the answer fit the lifecycle stage? Design, acquisition, implementation, operation, assessment, response, recovery, retirement.
• Is the proposed action proportionate? Choose the control or response that addresses the requirement without creating unnecessary harm or authority problems.

When two answers both sound secure, prefer the one that solves the stated problem at the correct level and in the correct sequence.

2. Current exam snapshot

ISC2 currently identifies the April 15, 2024 outline as the active CISSP blueprint.

The exam is experiential. Memorizing definitions helps, but many questions require you to connect a control to ownership, risk, legal obligations, architecture, or the correct stage of a process.

3. Use the CISSP decision lens

A useful cross-domain sequence is:

1. Establish authority and objective.
2. Identify the asset, process, people, and business requirement.
3. Determine legal, contractual, policy, privacy, and risk constraints.
4. Choose the control or action that satisfies the requirement.
5. Implement through an approved process.
6. Verify effectiveness with appropriate evidence.
7. Monitor, improve, and retire when the requirement changes.

This order explains why a technically strong answer can still be wrong.

"First" questions

Look for prerequisites.

Examples:

• Classify the information before choosing handling rules.
• Establish scope and authorization before penetration testing.
• Identify business impact before choosing recovery targets.
• Prove identity before relying on authentication.
• Define security requirements before selecting a product.
• Preserve life and safety before protecting equipment.

"Best" and "most appropriate" questions

Match the answer to the stated objective and authority.

A more expensive, more technical, or more restrictive control is not automatically better.

Risk ownership

Security professionals can identify, assess, communicate, and recommend treatment. The person authorized to accept business risk is the appropriate risk owner, not whichever technical person found the issue.

Compliance

Compliance creates requirements and evidence obligations. It does not automatically prove the organization is secure or that a control is effective against every relevant threat.

4. The eight-domain map

A scenario can cross several domains. Classification may drive IAM requirements. Architecture affects operations. Assessment findings feed governance and risk. Software supply-chain decisions affect asset security, architecture, and vendor risk.

5. Domain 1: Security and Risk Management

Ethics and authority

Professional ethics sets boundaries on what you should do even when technology allows more.

When a scenario involves investigation, monitoring, personnel, or sensitive data, first ask whether the organization has authority, legitimate purpose, and defined scope.

Governance vs management

Governance sets direction, accountability, objectives, and oversight. Management executes within that direction.

Do not let a technical team silently become the owner of a business decision because it understands the technology.

Due care vs due diligence

• Due care: take reasonable protective action.
• Due diligence: investigate, verify, monitor, and maintain that protection over time.

Installing a control can demonstrate care. Reviewing whether it remains effective is diligence.

Policy hierarchy

Keep the role of each document clear:

Risk

Risk combines uncertainty with possible harm to objectives.

Useful quantitative relationships:

Single Loss Expectancy (SLE) = Asset Value x Exposure Factor
Annualized Loss Expectancy (ALE) = SLE x Annualized Rate of Occurrence

Use the numbers when the question provides meaningful estimates. Do not invent precision where only qualitative ranking is supported.

Common treatment choices:

• Avoid
• Mitigate
• Transfer/share
• Accept

Transfer can move financial consequences or responsibilities. It does not erase the organization's accountability for every obligation.

Business continuity

A Business Impact Analysis (BIA) identifies critical processes, impacts, dependencies, and recovery needs.

Keep common recovery concepts separate:

• Maximum Tolerable Downtime (MTD): longest disruption the business can tolerate before unacceptable harm.
• Recovery Time Objective (RTO): target time to restore a service or process.
• Recovery Point Objective (RPO): target maximum data loss measured in time.
• Mean Time to Repair (MTTR): average repair/restoration duration for a component or service context.
• Mean Time Between Failures (MTBF): reliability measure between failures.

The technology recovery plan should support the business requirement, not define it backward.

Supply chain and awareness

Contracts, minimum requirements, assessment rights, monitoring, Software Bill of Materials (SBOM) information, provenance, supplier lifecycle, and exit planning all help manage supplier risk.

Training completion measures participation. Measure whether behavior and outcomes improved.

6. Domain 2: Asset Security

Classification starts with value and impact

Identify the information or asset, then determine who owns the business decision and what harm could occur if confidentiality, integrity, availability, privacy, authenticity, or another property is lost.

Classification should drive handling requirements.

Owner and custodian are different roles

The owner is accountable for business classification and protection requirements.

A custodian implements or operates controls on the owner's behalf.

Do not let operational possession become business ownership.

Data roles depend on context

Privacy and data-protection frameworks may distinguish roles such as controller, processor, subject, owner, custodian, and user. Read the scenario's legal and organizational context before assigning responsibility.

Lifecycle

Think through:

collect → use → store → share/transfer → retain → archive → destroy

At each stage, ask:

• Is the data still needed?
• Where is it located?
• Who can access it?
• What protection applies in use, transit, and at rest?
• How long must it be retained?
• What happens when support ends?
• How is destruction verified?

Retention is not backup

Retention answers how long information must or may be kept.

Backup answers how data can be restored after loss or corruption.

A backup copy can create an additional retention and discovery obligation.

Remanence and sanitization

Deleting a file is not the same as removing recoverable data.

At the appropriate assurance level:

• Clear: logical techniques that protect against simple recovery.
• Purge: stronger methods intended to resist more advanced recovery.
• Destroy: physically render the media unusable when required.

Choose the method from classification, media type, reuse plan, legal requirements, and risk.

7. Domain 3: Security Architecture and Engineering

Start with requirements

Architecture should answer a requirement and threat model. Product selection comes later.

Useful principles include:

• Least privilege
• Segregation of duties
• Defense in depth
• Secure defaults
• Fail securely
• Keep it simple and small
• Zero trust / explicit verification
• Privacy by design
• Shared responsibility

Security models

Do not choose a model from one memorized phrase without checking what property the scenario is trying to preserve.

Cryptography

Choose the cryptographic mechanism from the security objective.

• Encryption: confidentiality
• Hashing: integrity comparison/fingerprint, not confidentiality
• Digital signature: integrity, origin authentication, and nonrepudiation support when the surrounding trust model is sound
• Message Authentication Code (MAC): integrity/authenticity with a shared secret
• Key exchange/agreement: establish shared keying material
• Public Key Infrastructure (PKI): bind identities or attributes to public keys through certificates and trust relationships

Key management often matters more than the algorithm name: generation, distribution, storage, rotation, revocation, recovery, destruction, and cryptographic agility all matter.

Architecture and shared responsibility

Cloud, industrial systems, containers, serverless, Internet of Things, virtualized systems, and AI platforms shift responsibilities. Provider-managed does not mean customer-complete.

Identify who secures each layer and interface.

Facilities and safety

Physical security uses layers: site selection, perimeter, building, restricted areas, server rooms, media, power, fire, heating/ventilation/air conditioning, and emergency response.

For safety conflicts, people come before equipment.

System lifecycle

Security requirements should remain traceable through design, implementation, verification, validation, operation, change, and retirement.

• Verification: did we build according to specification?
• Validation: did we build the right thing for the intended need?

8. Domain 4: Communication and Network Security

Locate the control in the communication path

Use models such as OSI and TCP/IP to reason about where a control operates, but do not treat the model as the goal.

Ask:

• What endpoints communicate?
• What trust boundary is crossed?
• What must be protected: confidentiality, integrity, availability, identity, segmentation, or monitoring?
• Does the control protect the endpoint, channel, network path, or application?

Secure protocols answer different needs

Examples:

• TLS: protects application sessions and related transport communication.
• IPsec: protects IP communications at the network layer.
• SSH: secure remote administration and tunneling use cases.
• VPN: creates a protected communication path, but does not prove the endpoint is trustworthy.

Avoid the shortcut that "encrypted" means "secure enough." Authentication, endpoint security, authorization, key management, and availability can still fail.

Segmentation

Physical segmentation, VLANs, virtual routing, firewalls, microsegmentation, and zero-trust policy can reduce exposure and movement.

A VLAN separates broadcast domains. It is not, by itself, a complete security policy.

Network direction and visibility

Know the difference between:

• North-south: traffic entering/leaving a protected environment.
• East-west: traffic between internal workloads or segments.

Modern environments need visibility and controls in both directions.

Network design

Consider:

• Redundancy without shared failure points
• Routing and switching resilience
• Capacity and Quality of Service (QoS)
• Wireless and radio risks
• Remote access
• Third-party connections
• Software-Defined Networking (SDN), Software-Defined Wide Area Networking (SD-WAN), and cloud networking
• Network Access Control (NAC)
• Monitoring, baselines, flow data, and fault management

A redundant component that shares power, path, provider, or control plane with its partner may not remove the actual failure mode.

9. Domain 5: Identity and Access Management

Keep the identity sequence intact

A useful sequence is:

identify/proof → authenticate → authorize → account/monitor → review → change/remove

Authentication proves a credential or factor. It does not establish what the user is allowed to do.

Authentication factors

Common factors include:

• Something you know
• Something you have
• Something you are

Two passwords are not multifactor authentication because they use the same factor type.

Phishing resistance, replay resistance, recovery strength, and enrollment proofing matter in addition to factor count.

Federation, SSO, and delegated authorization

Federation reduces the need for separate credentials. It does not transfer all accountability to the identity provider.

Authorization models

• Discretionary Access Control (DAC): owner-controlled permissions.
• Mandatory Access Control (MAC): centrally enforced labels/classifications.
• Role-Based Access Control (RBAC): permissions assigned through organizational roles.
• Rule-based: access based on system-enforced rules.
• Attribute-Based Access Control (ABAC): decisions use attributes of subjects, objects, action, and environment.

Read the policy requirement before choosing a model.

Lifecycle and privileged access

Provisioning is not finished when access is granted.

Handle:

• Joiner/mover/leaver changes
• Access reviews and certification
• Just-in-time access
• Privileged Access Management (PAM)
• Break-glass/emergency access
• Service/workload identities
• Secrets and credential rotation
• Immediate deprovisioning when required

A periodic review does not replace timely removal after termination or role change.

10. Domain 6: Security Assessment and Testing

Define the question before choosing the test

Different activities produce different evidence.

Authorization, scope, rules of engagement, safety, and independence matter.

Evidence quality

Match evidence to the decision.

A screenshot can show one state at one time. A reproducible test, log trail, configuration review, independent sample, or repeated measure may provide stronger evidence depending on the claim.

Metrics

• KPI: performance toward an objective.
• KRI: indicator of changing risk exposure.
• Control metric: evidence about control operation/effectiveness.

Completion counts alone are often activity metrics, not outcome metrics.

Application testing

Keep common techniques separate:

• SAST: analyze code/build artifacts without running the application.
• DAST: test a running application from the outside.
• IAST: instrumented analysis while the application runs.
• SCA: identify third-party/open-source components and known dependency issues.

No single tool proves the application is secure.

Findings and remediation

A finding is not finished because a ticket changed to "closed."

Verify:

• Root cause/action
• Compensating controls where needed
• Retest or evidence of correction
• Exception/risk acceptance by the correct authority
• Expiration/review date for exceptions
• Trend and recurrence

11. Domain 7: Security Operations

Investigation comes with authority and evidence duties

Before collecting evidence:

• Know the purpose and legal/organizational authority.
• Preserve chain of custody where required.
• Minimize unnecessary changes to evidence.
• Follow order of volatility when appropriate.
• Document who collected what, when, where, and how.

Do not power off a system reflexively if volatile evidence matters and safety does not require it.

Logging, monitoring, and SIEM

A Security Information and Event Management (SIEM) platform centralizes and correlates event information. It does not detect every attack by itself.

Good monitoring requires:

• Useful log sources
• Time synchronization
• Retention
• Baselines
• Detection logic
• Tuning
• Escalation
• Response process
• Measurement of detection quality

Incident response

A useful high-level flow is:

prepare → detect/analyze → contain → eradicate → recover → learn/improve

The exact framework wording can vary. Use the scenario's stated process when provided.

Containment may protect the business while evidence collection continues. Eradication removes the cause. Recovery restores trusted operation. Lessons learned should feed improvements.

Configuration, change, patch, and vulnerability management

Keep the purposes separate:

• Configuration management: maintain known/approved system state.
• Change management: control proposed changes and risk.
• Patch management: evaluate, test, deploy, and verify updates.
• Vulnerability management: identify, prioritize, remediate/mitigate, verify, and monitor weaknesses.

Numeric severity is one input. Exploitability, exposure, asset value, compensating controls, business criticality, and active exploitation also matter.

Recovery and continuity

Recovery test methods generally increase in disruption from document review/checklist and tabletop activities toward simulation, parallel processing, and full interruption. Choose the least disruptive method that provides the evidence required for the current test objective.

Safety

Personnel safety outranks protection of equipment or information when they directly conflict.

12. Domain 8: Software Development Security

Put security into the lifecycle

Security requirements, architecture, threat modeling, coding standards, testing, release controls, monitoring, change, and retirement should be part of the Software Development Life Cycle (SDLC).

Waiting for a final penetration test is too late to discover every design problem economically.

Development methods change cadence, not the requirement for security

Waterfall, Agile, DevOps, DevSecOps, and other approaches organize work differently. Security still needs:

• Requirements
• Threat modeling
• Secure design
• Code/repository protections
• Testing
• Change control
• Deployment controls
• Monitoring
• Incident response
• Retirement

DevSecOps is a way of integrating security into delivery workflows. It is not a single product.

Protect the development ecosystem

Important assets include:

• Source code
• Repositories
• Build systems
• CI/CD pipelines
• Dependencies
• Package registries
• Secrets
• Signing keys
• Infrastructure definitions
• Test data
• Artifacts
• Development and test environments

Compromise of the pipeline can bypass secure source code.

Testing techniques

Use SAST, DAST, IAST, SCA, code review, penetration testing, fuzzing, and other methods for the questions they are designed to answer.

Earlier feedback is usually cheaper to act on, but later testing still provides evidence that cannot be obtained before runtime.

Software supply chain

Useful concepts include:

• Supplier assessment
• Dependency governance
• SBOM
• Vulnerability Exploitability eXchange (VEX)
• Artifact signing/provenance
• Reproducible/verifiable builds
• Repository and pipeline access
• Update/patch trust
• Contractual obligations
• Ongoing monitoring

An SBOM shows what components are declared/present. It does not prove those components are safe or correctly configured.

Secure coding and APIs

Keep fundamentals fresh:

• Validate input and enforce expected meaning.
• Use parameterized interfaces to reduce injection risk.
• Enforce authorization for each object/action.
• Protect secrets and cryptographic material.
• Fail safely and avoid sensitive error leakage.
• Manage memory/concurrency risks where relevant.
• Log useful events without exposing secrets.
• Use secure defaults.

For APIs, authenticate the caller, authorize the requested action, validate requests/responses, control abuse, maintain inventory, and protect documentation/secrets.

AI-assisted development

Treat AI-generated code as untrusted until reviewed and tested.

Protect prompts, training/retrieval data, models, dependencies, generated artifacts, and the permissions given to AI coding agents. Avoid placing sensitive source, credentials, private keys, customer data, or proprietary material into an unapproved AI service.

13. Cross-domain decision traps

These mistakes recur because the answer sounds secure but skips the actual decision.

• Implementing before requirements: choose the product only after the objective, scope, and constraints are known.
• Letting security accept business risk: communicate and recommend; the authorized owner accepts residual risk.
• Treating compliance as assurance: compliance may be necessary, but effectiveness still needs evidence.
• Confusing owner and custodian: operational responsibility does not automatically include business authority.
• Choosing authentication before identity proofing: a strong credential bound to the wrong person is still a failure.
• Confusing authentication and authorization: proving identity does not grant every permission.
• Calling OAuth authentication: OAuth is delegated authorization; OIDC adds an authentication layer.
• Treating encryption as complete protection: key management, authorization, endpoints, integrity, availability, and operations still matter.
• Treating a VLAN or VPN as complete security: segmentation and protected transport are pieces of a control architecture.
• Testing without authorization: technical capability does not create permission.
• Closing findings without verification: remediation needs evidence.
• Confusing configuration and change management: one controls approved state; the other controls proposed transitions.
• Treating backup completion as recovery proof: restoration/testing provides stronger recovery evidence.
• Choosing technology recovery before business impact: RTO/RPO should support business requirements.
• Protecting evidence or equipment before people: safety comes first.
• Treating DevSecOps as a tool: it is an integrated way of working.
• Trusting AI output because it is confident: verify evidence, authority, scope, and result.

14. Final readiness checklist

You are ready for another full CISSP practice session when you can work through these without relying on recognition alone:

• [ ] Ethics, governance, management, ownership, and risk-acceptance authority
• [ ] Due care vs due diligence
• [ ] Policy, standard, procedure, guideline, and baseline
• [ ] BIA, MTD, RTO, RPO, SLE, ARO, ALE
• [ ] Risk treatment and residual-risk ownership
• [ ] Supplier risk, contracts, monitoring, and exit planning
• [ ] Classification, owner vs custodian, data roles, handling, retention, remanence, destruction
• [ ] Data protection in use, in transit, and at rest
• [ ] Secure design principles and security-model purposes
• [ ] Bell-LaPadula, Biba, Clark-Wilson, and Brewer-Nash distinctions
• [ ] Cryptography by objective plus the key-management lifecycle
• [ ] PKI, certificates, signatures, hashing, encryption, and MAC distinctions
• [ ] Shared responsibility across cloud, virtualized, industrial, and AI systems
• [ ] Verification vs validation
• [ ] Segmentation, secure channels, remote access, network direction, and third-party connectivity
• [ ] Redundancy vs shared failure points
• [ ] Identity proofing, authentication, authorization, accounting, and lifecycle
• [ ] SSO, SAML, OIDC, OAuth, DAC, MAC, RBAC, rule-based, and ABAC
• [ ] PAM, service identities, JIT access, access review, and timely deprovisioning
• [ ] Vulnerability assessment vs penetration test vs audit vs red team
• [ ] Independence, scope, rules of engagement, evidence quality, metrics, remediation, and retest
• [ ] SAST, DAST, IAST, and SCA
• [ ] Investigation authority, order of volatility, chain of custody, and documentation
• [ ] Logging, SIEM, threat intelligence, hunting, and detection tuning
• [ ] Incident response order and purpose of containment, eradication, recovery, and lessons learned
• [ ] Configuration, change, patch, and vulnerability-management distinctions
• [ ] Business continuity vs disaster recovery and recovery testing
• [ ] Personnel safety priority
• [ ] Secure SDLC, DevSecOps, repository/pipeline security, and software supply chain
• [ ] SBOM, VEX, provenance, secure coding, and API security
• [ ] AI governance, architecture, assessment, operations, and development risks across domains
• [ ] The correct owner, prerequisite, and evidence for a BEST/FIRST/MOST scenario

If several boxes are slow, use the matching CISSP Quick Review or domain guide to repair the distinction, then take a fresh CISSP practice test.

15. Official references

• ISC2 CISSP Certification Exam Outline
• ISC2 CISSP Exam Refresh FAQ
• ISC2 Code of Ethics
• ISC2 CISSP certification overview