CISSP study guide

Domain 1: Security and Risk Management

Security and Risk Management establishes the decision system for the other seven domains. Begin with professional ethics, governance, laws and regulations, policy hierarchy, business continuity, personnel security, threat modeling, supply-chain risk, security awareness, and formal risk management. The core skill is translating security concerns into accountable business decisions.

Risk is not a vulnerability count. A vulnerability matters because it intersects with an asset, threat, likelihood, impact, existing controls, and business context. Qualitative and quantitative methods can support prioritization, but the output should help an accountable owner choose treatment: avoid, mitigate, transfer, or accept. Security teams should document assumptions and residual risk rather than pretending every uncertainty can be reduced to one precise number.

Governance distinguishes direction from execution. Policies communicate management intent. Standards define mandatory requirements. Procedures describe repeatable steps. Guidelines recommend practices. Security architecture, engineering, operations, and assurance should trace back to these decisions so teams can explain why a control exists and who can authorize exceptions.

Business continuity begins with critical functions and dependencies, not with backup products. Business impact analysis helps identify disruption tolerance, recovery priorities, and dependencies. Risk management also extends to suppliers because outsourced services can create concentration risk, data exposure, contractual obligations, and operational dependencies that remain the customer's responsibility to govern.

Domain 3: Security Architecture and Engineering

Architecture turns security principles into system structure. Defense in depth, least privilege, zero trust, secure defaults, fail-safe behavior, separation of duties, isolation, and privacy by design are design principles rather than individual products. The exam may present several technologies; choose the architecture that reduces trust and failure concentration at the right boundary.

Security models such as Bell-LaPadula and Biba illustrate confidentiality and integrity goals. Modern systems also require understanding trusted computing concepts, cryptography, physical security, cloud architecture, virtualization, containers, serverless platforms, IoT, industrial systems, distributed systems, and high-availability design.

Cryptography protects data only when algorithms, modes, implementations, key generation, storage, rotation, access, revocation, and recovery are handled correctly. Hashing supports integrity use cases; digital signatures support integrity, origin authentication, and non-repudiation properties when keys and validation are trustworthy. Symmetric and asymmetric cryptography solve different performance and key-distribution problems.

Resilience requires tracing shared dependencies. Two systems are not truly redundant if both depend on one identity provider, network path, power source, DNS service, or administrative plane. Threat modeling and architecture review should reveal these hidden couplings before failure or attack does.

Domain 5: Identity and Access Management (IAM)

IAM connects identity proofing, authentication, authorization, federation, lifecycle management, privileged access, access review, and accountability. Authentication proves an identity; authorization decides what the identity can do. Federation allows one trust domain to rely on another identity provider, but the relying service still needs correct authorization.

Least privilege limits permissions to business need. Separation of duties prevents one identity from controlling an entire sensitive process. Role-based controls simplify permissions around job functions, while attribute-based policies can incorporate identity, resource, action, device, and environmental context.

Identity lifecycle failures often create more durable risk than a single bad login. Joiner, mover, and leaver processes should provision approved access, adjust permissions when roles change, review entitlements, and remove stale access quickly. Service accounts and machine identities deserve the same lifecycle discipline as people.

Privileged access requires stronger protection because compromise can bypass many downstream controls. Dedicated administrative accounts, phishing-resistant MFA, just-in-time elevation, approval, session logging, vaulting, rotation, and break-glass processes are examples of controls that can reduce standing privilege and improve accountability.

Domain 7: Security Operations

Security Operations converts policy and architecture into daily control execution. Topics include investigations, incident response, logging, monitoring, vulnerability management, patching, configuration, change management, recovery, disaster recovery, physical security, personnel safety, and resource protection.

Incident response should preserve sequence and evidence. Preparation establishes tooling, roles, communications, and procedures. Detection and analysis determine what happened. Containment limits attacker capability. Eradication removes cause and persistence. Recovery restores trusted service. Lessons learned should improve controls rather than simply close the ticket.

Forensics requires chain of custody, integrity, repeatability, authorization, and awareness of legal or regulatory constraints. Investigators should distinguish observed facts from hypotheses and document who collected, handled, analyzed, and transferred evidence.

Change and configuration management reduce accidental risk. Secure baselines, version control, approvals, testing, rollback, monitoring, and exception handling improve reliability and forensic clarity. Emergency changes may use accelerated procedures, but urgency should not eliminate accountability.

Cycle through domains, then integrate them with mixed scenarios.

Weeks 1–2: governance, risk, and assets

Review Domain 1 and Domain 2 together. Build a small risk register, classify a fictional data set, define ownership and handling rules, and map a continuity scenario from business impact through recovery priorities.

Weeks 3–4: architecture, networks, and IAM

Draw a secure service architecture with trust boundaries, identity flow, administrative access, network segmentation, encryption, resilience dependencies, and cloud responsibilities. Explain why each control sits at that layer.

Weeks 5–6: assessment and operations

Create a control-assurance plan: what would you test, how would you measure effectiveness, and which evidence would prove the control works? Then write an incident timeline from detection through recovery and lessons learned.

Week 7: software security

Threat-model a small application. Identify source, dependency, CI/CD, secrets, deployment, authorization, logging, and update risks. Choose at least three different testing methods and state what each one can and cannot prove.

Week 8: mixed practice

Take scenario questions across all eight domains. For every miss, classify the error as knowledge, scope, ownership, sequencing, or control-objective confusion. Review the reasoning pattern rather than rereading the entire domain.