The CISSP domains create a mental model: not just reacting to issues, but understanding what category of security problem you are looking at. The domain structure shifts the question from "what is wrong here?" to "which area of security does this belong to?" That is what turns scattered learning into a study system.
Read each domain description as a framing question, not a textbook summary. Each domain exists because it answers a different set of questions a security professional must be able to answer. Understanding why a domain exists is more useful than memorising what it contains.
CISSP Domain Weightage
The exam draws questions from all 8 domains, but not equally. Domain 1 alone accounts for 16% of questions. Knowing this does not mean you neglect lower-weight domains — every domain is tested — but it does inform where to invest deeper effort when time is limited.
| Domain | Name | Weight | Bar |
|---|---|---|---|
| D1 | Security and Risk Management | 16% | |
| D2 | Asset Security | 10% | |
| D3 | Security Architecture and Engineering | 13% | |
| D4 | Communication and Network Security | 13% | |
| D5 | Identity and Access Management | 13% | |
| D6 | Security Assessment and Testing | 12% | |
| D7 | Security Operations | 13% | |
| D8 | Software Development Security | 10% |
Source: ISC2 CISSP Exam Outline
Domain 1 — Security and Risk Management
This domain is about responsibility, governance, and how risk is defined and managed. It sets the context for every other domain — without understanding risk, none of the controls in the other seven domains have a coherent purpose.
What it helps you ask
- Do we have security policies, and who approves them?
- Are we aligned with a governance model?
- What is the threat landscape and how do we measure risk?
- Do we assess inherent versus residual risk?
- How do we balance security goals with business priorities?
Key topics
- Qualitative and quantitative risk analysis (ALE, SLE, ARO)
- Risk treatment: avoid, mitigate, transfer, accept
- Security roles and responsibilities (RACI, ownership)
- Ethics and professional conduct
- Compliance and legal frameworks (GDPR, HIPAA, SOX)
Domain 2 — Asset Security
Before you can protect anything, you need to know what exists and how it should be handled. Domain 2 is the inventory and classification layer — it answers the question of what the organisation owns and how sensitive each asset is.
What it helps you ask
- What assets do we have, and who owns them?
- How is data classified and labelled?
- Where is it stored and how long must it be retained?
- What disposal procedures apply when assets reach end of life?
Key topics
- Data lifecycle management
- Privacy versus confidentiality
- Data ownership roles: owner, custodian, steward, user
- Asset handling procedures
- Regulatory requirements for PII and sensitive data
Domain 3 — Security Architecture and Engineering
This domain is about building security in by design rather than adding it later through patchwork. It covers the principles, models, and mechanisms that make systems trustworthy before they are ever deployed.
What it helps you ask
- Do we use design principles like least privilege and defence in depth?
- Are we using strong, appropriate cryptography?
- How is trust established between components?
- What vulnerabilities exist in the system design itself?
Key topics
- Security models: Bell-LaPadula, Biba, Clark-Wilson, Brewer-Nash
- Cryptography, hashing, digital signatures, and key management
- PKI and certificate infrastructure
- Cloud shared responsibility model
- Hardware, firmware, and OS vulnerabilities
- Physical security controls and fire suppression
Domain 4 — Communication and Network Security
This domain focuses on how systems communicate and how that communication is protected, segmented, and monitored. Many candidates find this the most technically dense domain — the breadth of protocols and topologies is wide.
What it helps you ask
- Do internal services use encryption in transit?
- Are development, test, and production environments segmented?
- Is remote access appropriately controlled?
- Are we monitoring for anomalous network behaviour?
Key topics
- OSI and TCP/IP models
- Secure protocols: TLS, SSH, IPsec, HTTPS
- Insecure protocols and their secure replacements
- Firewalls, IDS/IPS, proxy and gateway architectures
- VPN, VLAN, and network segmentation
- Wireless security: WPA3, 802.1X
Domain 5 — Identity and Access Management
This is the control layer around who gets access, how that access is verified, and how it is removed. IAM questions on the exam often test the distinction between identification, authentication, authorisation, and accountability — the IAAA sequence.
What it helps you ask
- Who has access to what, and on what basis?
- Are permissions role-based or manually assigned?
- How are accounts provisioned and deprovisioned?
- How do we handle federated identities across systems?
Key topics
- Identification, Authentication, Authorisation, Accountability (IAAA)
- Authentication factors: something you know, have, are, do, where
- Access control models: RBAC, ABAC, MAC, DAC
- Identity lifecycle management
- SSO, federated identity, SAML, OAuth, OpenID Connect
- Zero Trust architecture
Domain 6 — Security Assessment and Testing
This domain is about proving whether controls work rather than assuming they do. It covers the full range of testing methodologies — from vulnerability scans to penetration tests to formal audits — and the process of using evidence to drive continuous improvement.
What it helps you ask
- How do we know our controls are actually working?
- When was the last vulnerability scan or penetration test?
- Are audit findings tracked to closure?
- Do we have a continuous monitoring programme?
Key topics
- Vulnerability scanning and penetration testing (black, white, grey box)
- Static and dynamic code analysis (SAST, DAST)
- Security audits and assessments
- Test coverage metrics and code coverage
- SOC reports and third-party assurance
Domain 7 — Security Operations
This is the heartbeat of operational security: monitoring, detection, response, and continuity. Domain 7 is often where lifecycle questions appear — the incident response sequence, the forensic evidence handling order, and the BCP/DRP testing hierarchy all live here.
What it helps you ask
- Are logs being collected and reviewed?
- Who is watching for suspicious activity in real time?
- What is the sequence when an incident occurs?
- Do we have a tested disaster recovery plan?
Key topics
- Incident response lifecycle: Detect, Respond, Mitigate, Report, Remediate, Restore, Lessons Learned
- SIEM, IDS/IPS, UEBA
- Digital forensics and order of volatility
- BCP and DRP — distinction and testing methods (tabletop, simulation, parallel, full interruption)
- Change management and patch management
- Physical security operations
Domain 8 — Software Development Security
This domain focuses on securing what gets built — from requirements through deployment and maintenance. It is not just a developer domain. Security professionals need to understand the SDLC because software is where a large proportion of vulnerabilities are introduced.
What it helps you ask
- Are secrets hardcoded into code or configuration?
- Is there security review at key SDLC gates?
- Are security requirements defined before development starts?
- Are there automated security checks in the CI/CD pipeline?
Key topics
- Secure SDLC phases and security integration points
- Threat modeling (STRIDE, PASTA, DREAD)
- Static and dynamic analysis (SAST, DAST, IAST)
- OWASP Top 10
- DevSecOps and security automation
- Software supply chain security
The domains do not operate independently. An incident in Domain 7 traces back to a control failure that could sit in Domain 1 (governance), Domain 3 (architecture), Domain 5 (IAM), or Domain 6 (assessment). The exam tests this connected thinking — your ability to identify where in the system the root cause actually lies.
Article 3 covers the preparation journey in full — the resources, the sequencing, and the mindset shifts that separate candidates who pass from those who almost do.
