There are eight CISSP exam domains. They are not weighted equally, they are not equally difficult, and — this is the part most study plans get wrong — they do not each deserve the same share of your time. If you treat the CBK as a neat checklist of eight things, you'll spend months moving through the material and still feel shaky on exam day.
What actually works is knowing which domains carry more weight, which ones hide the "CISSP mindset" questions that trip up experienced engineers, and which ones you can learn cold in a week. Below is the exam outline (2024 revision, still current in 2026), what each domain actually tests, and where I'd spend disproportionate time if I were studying today.
The Eight Domains and Their Weights
| Domain | Name | Weight |
|---|---|---|
| 1 | Security and Risk Management | 16% |
| 2 | Asset Security | 10% |
| 3 | Security Architecture and Engineering | 13% |
| 4 | Communication and Network Security | 13% |
| 5 | Identity and Access Management (IAM) | 13% |
| 6 | Security Assessment and Testing | 12% |
| 7 | Security Operations | 13% |
| 8 | Software Development Security | 10% |
A few things jump out if you actually sit with the numbers. Domain 1 is almost twice the size of Domain 2 or Domain 8. Five domains are stacked so close together (12–13%) that trying to prioritize between them is a waste of planning energy. And Domain 1 is the one people talk about the least, even though it decides more of your score than any other single domain.
Domain 1: Security and Risk Management (16%)
This is the domain that trains the CISSP mindset, and it's the one most engineers underestimate. The topics look soft on paper — governance, risk management, legal and regulatory issues, the (ISC)² Code of Ethics, BCP/BIA, personnel security, security awareness, supply chain risk. Nothing here is technically hard. That's exactly the problem.
The difficulty isn't the content. It's that the exam uses this domain to test whether you think like a manager or like an engineer. Two answers can both be technically correct, and the "right" one is almost always the one that starts with governance, policy, or a decision-maker. If your instinct on a question is to pick the control that closes the vulnerability fastest, you're probably picking wrong on Domain 1.
I worked with a candidate — a network security engineer with twelve-plus years of hands-on experience — who failed his first attempt scoring high on his practice tests. His problem was almost entirely Domain 1. He kept picking the technically correct answer instead of the governance-first answer. He was right about what would actually stop the attack. The exam didn't care. The "best" answer was "consult the data owner" or "update the policy," and he kept skipping past those to the technical fix two options down.
A few things to memorize cold for this domain:
- The precise definitions of threat, vulnerability, risk, and exposure. These are tested constantly and the exam uses the formal language.
- Quantitative risk analysis: SLE = AV × EF, ALE = SLE × ARO. Know what every letter stands for and how the math works.
- The risk response options — avoid, transfer, mitigate, accept — and when each is appropriate.
- The (ISC)² Code of Ethics in order. When a question gives you an ethics scenario, the order of the canons matters.
One pattern I've noticed: people who have been doing security for a long time often skim Domain 1 because it "looks familiar." Then they get 55% of the Domain 1 questions wrong on their first practice exam and have to go back and actually study it. If you're an experienced practitioner, this is the domain most likely to embarrass you. Treat it accordingly.
Domain 2: Asset Security (10%)
Domain 2 is the opposite problem. It's low weight, it's formulaic, and if you learn the frameworks it's genuinely a source of easy points.
The topics: information classification (public, sensitive, confidential, top secret), data roles (owner, controller, processor, custodian, user), the data lifecycle, data remanence, secure destruction, encryption at rest, standards selection. None of this is conceptually hard. The exam mostly wants you to know who is responsible for what.
The single most tested idea: data owner vs. data custodian. The owner is the senior business leader accountable for the data. The custodian implements the controls on their behalf. Owners make decisions. Custodians execute them. Remember that sentence and you'll get most Domain 2 scenario questions right on reflex.
Domain 3: Security Architecture and Engineering (13%)
This is one of two domains where candidates burn the most time on things the exam doesn't test.
You need to understand cryptography — what symmetric, asymmetric, and hashing algorithms do, when to use each, and how they combine in real systems (digital envelopes, digital signatures, PKI). You do not need to be able to derive RSA by hand. Every year people spend weeks on the math of AES and then get asked a question like "which cryptographic primitive provides non-repudiation?" where the answer is just "digital signature."
The other trap is the classical security models — Bell-LaPadula, Biba, Clark-Wilson, Brewer-Nash. Memorizing rules without understanding the philosophy behind them doesn't work. Bell-LaPadula is about confidentiality: no read up, no write down. Biba inverts it for integrity: no read down, no write up. Clark-Wilson is integrity through well-formed transactions and separation of duties. Brewer-Nash (the Chinese Wall) is about conflicts of interest. If you know what each model is protecting against, you don't need to memorize the rules — you can derive them.
Also in this domain: secure design principles (defense in depth, least privilege, fail-safe defaults, separation of duties), TCB and reference monitor concepts, architectural vulnerabilities across cloud/IoT/ICS, and physical security. Physical security is one of those things that looks trivial until you get a question about fire suppression class and realize you haven't thought about Class C vs. Class K since you started studying.
Domain 4: Communication and Network Security (13%)
The most classically "technical" domain. If you have a networking background, this is where you'll feel at home — and it's also where the exam will quietly punish you for coasting.
Knowing the OSI layers in order is the baseline. The exam asks which layer specific attacks operate at, and which layer specific controls live at. ARP poisoning is layer 2. IP spoofing is layer 3. TCP session hijacking is layer 4. WAFs operate at layer 7. Traditional stateful firewalls live at layers 3–4. If these don't come to you instantly, you'll lose questions here.
Beyond that: secure protocols (TLS, SSH, IPsec, Kerberos, RADIUS vs. TACACS+), wireless security (WPA2 vs. WPA3, 802.1X), network segmentation, zero trust, VPN and SD-WAN fundamentals. RADIUS vs. TACACS+ comes up more than you'd expect — know that RADIUS combines authentication and authorization and only encrypts passwords, while TACACS+ separates them and encrypts the whole payload.
If you don't have a networking background, this is your largest investment domain. Work through each OSI layer methodically, attacks and controls at each, until you can rattle them off without pausing. It sounds tedious. It is. It's also the difference between passing and failing this section.
Domain 5: Identity and Access Management (13%)
CISSP IAM questions are sneaky. The concepts look simple — you've probably configured access controls on a hundred systems — and that familiarity is the trap. The exam doesn't test whether you can set up RBAC in Active Directory. It tests whether you can read a four-sentence scenario and instantly tell which model the architects chose, why they chose it, and what they got wrong. Domain 5 is also where almost every other domain leans for context — software security, network security, and operations all assume you understand IAM — so time spent here pays back across the whole test.
Identification, authentication, authorization, accountability
Start with the distinction experienced engineers throw away points on. Identification is the claim ("I'm Alice"). Authentication is the proof (password, token, fingerprint). Authorization is the decision (Alice can read this, not edit it). Accountability is the fourth piece: the ability to trace an action back to an authenticated identity — logging, audit trails, non-repudiation. Shared accounts kill accountability on contact, which is why they're never the right answer for a production scenario.
Under exam pressure, with a scenario about a user who "logged in successfully but couldn't reach the executive SharePoint," candidates conflate authentication and authorization and pick a control that solves the wrong problem. If the user is already logged in, you're in authorization territory. An MFA-related answer is wrong there even though MFA is "more secure."
Authentication factors
Something you know, something you have, something you are, somewhere you are, something you do. Multi-factor means combining factors from different categories. A password plus a security question is still single-factor, because both are "something you know." This gets tested in slightly disguised forms — candidates see "a PIN and a passphrase" and convince themselves that's MFA. It isn't. If you see two knowledge factors and an answer choice says "this is true MFA," it's a trap.
A few authentication patterns are worth recognizing beyond the factors themselves. Single sign-on reduces password fatigue but concentrates blast radius — when the IdP goes down, everything goes down with it. Passwordless authentication (FIDO2/WebAuthn is the standard to know by name) replaces shared secrets with device-bound cryptographic keys. Risk-based authentication triggers a step-up challenge when signals look off; continuous authentication quietly re-evaluates trust in the background.
Access control models — the part you cannot fake
This is the most heavily tested topic in Domain 5. Memorizing definitions works less well than memorizing the signal in a question that points to each model.
Discretionary Access Control (DAC) is "the owner decides." Classic Unix file permissions — you created the file, you decide who reads it. Flexible, but nearly impossible to govern at scale because owners hand out access inconsistently and there's no central policy to fall back on.
Mandatory Access Control (MAC) is "central policy decides, based on labels." Subjects have clearances, objects have classifications, and users can't override it. Think military, think classified government data. Bell-LaPadula and Biba from Domain 3 are the formal MAC models. If clearances and classifications appear in the scenario, the answer is MAC.
Role-Based Access Control (RBAC) is "permissions follow the role, not the person." New hire in Accounting gets the Accountant role and inherits the permission set; promote them and you swap the role. This is what most enterprises actually run on. Watch for "role explosion" as a distractor — so many overlapping roles that the model collapses under its own weight.
Attribute-Based Access Control (ABAC) is "evaluate attributes at request time" — user, resource, action, environment. "A hospital wants access to patient records to depend on whether the user is a physician, whether they're currently on shift, and whether the patient is assigned to them" is ABAC. It's the most expressive model and the right answer for modern cloud and zero-trust scenarios, but also the hardest to design and audit.
| Signal in the question | Model |
|---|---|
| Object owner decides who gets access | DAC |
| Clearances, classifications, labels, "no read up" | MAC |
| Permissions assigned to a job function, inherited by people | RBAC |
| Decisions evaluated at request time using user/resource/environment attributes | ABAC |
One pattern I've noticed: candidates who consistently miss model-identification questions are picking the model they'd architect if they were building the system, not the one the scenario actually describes. The exam isn't asking what you'd choose. It's asking what's there.
Federation
SAML is XML-based and used heavily for enterprise SSO — the user authenticates at their Identity Provider, which sends a signed assertion to the Service Provider. SAML is for authentication. OAuth 2.0 is for authorization — it hands out access tokens that let one service act on a user's behalf against another service's API, and plain OAuth doesn't give you a verified identity. OpenID Connect (OIDC) is the identity layer built on top of OAuth 2.0 that does. You don't need to memorize the flows. You do need to catch the trap: OAuth presented as an authentication solution. If a scenario calls for verifying user identity across systems and the OAuth answer doesn't mention OIDC, that answer is incomplete.
The identity lifecycle, PAM, and where audits go bad
Provisioning, maintenance, periodic review, deprovisioning. None of it is conceptually hard; the exam tests whether you know which stage fails in practice. The answer is almost always deprovisioning. Orphaned accounts — credentials still active after someone leaves or changes teams — are one of the most common audit findings in real environments, and SOX, PCI DSS, and HIPAA all care about them. If a scenario describes a former employee whose account was still active months after departure, the failure is deprovisioning and the corrective control is automated deprovisioning tied to HR systems plus periodic access reviews.
Privileged Access Management (PAM) is the umbrella for the controls you wrap around admin and service accounts: just-in-time elevation, session recording, credential vaulting, automated rotation. When a question asks for the right control on a high-privilege account, PAM-flavored answers usually win.
Two more failure patterns the exam likes: privilege creep (users accumulating permissions across role changes without ever losing the old ones — a least-privilege violation, and the control is access reviews) and MFA fatigue or push bombing (mitigated by number-matching MFA and rate-limited push prompts).
If one of these areas is already second nature — say you've worked enterprise IAM and RBAC is reflex — don't re-read it. The leverage is in the models you don't use day to day: MAC and the formal models for most engineering-background candidates, the federation standards for most governance-background ones.
Domain 6: Security Assessment and Testing (12%)
Less about tools, more about process. The exam wants to know that you understand assessment types, who runs them, what they produce, and who the audience is.
The most-tested distinction: vulnerability assessment vs. penetration testing. Vulnerability assessment finds weaknesses. Penetration testing actively exploits them to prove impact. Related to this are the testing approaches — black-box (no knowledge), gray-box (partial knowledge), white-box (full knowledge). Know which approach matches which scenario.
Audit reports get tested too. SOC 1 is about controls over financial reporting. SOC 2 is about controls at a service organization (security, availability, confidentiality, processing integrity, privacy). Type I is a point-in-time report. Type II covers a period (usually 6–12 months) and actually tests whether the controls operated effectively. If a question asks which report a prospective customer would want to evaluate a SaaS vendor's security, it's SOC 2 Type II.
Process details matter here. Log reviews, synthetic transactions, code reviews, and misuse case testing all have different purposes. You don't need to be an expert in any of them. You need to know what each is for.
Domain 7: Security Operations (13%)
The largest operational domain and the one where sequence matters more than anywhere else on the exam.
Learn the incident response lifecycle in order: preparation, detection and analysis, containment, eradication, recovery, lessons learned. The exam gives you scenarios and asks what the next step is. If containment has happened but eradication hasn't, you're not recovering yet. If you haven't done lessons learned, the incident isn't closed. These questions are almost free points if you know the sequence.
BCP and DRP sequences matter the same way. Know the order: project initiation, scope, BIA, identify preventive controls, develop recovery strategies, develop the plan, test/train/maintain. And know the recovery site options in order of cost and recovery time: hot, warm, cold, mobile, cloud.
Evidence handling is where a lot of Domain 7 questions live. Chain of custody is the phrase to burn into your head. If a question asks what to do first when you discover evidence, the answer is almost always "document and preserve" — not "analyze," not "notify," not "contain." Everything else comes after you've preserved the evidence and established custody.
Domain 8: Software Development Security (10%)
This is the domain non-developers most often underinvest in, and it's the one where that underinvestment shows up on the score report.
You don't need to write code. You do need to understand what SQL injection, XSS (stored, reflected, and DOM-based), CSRF, and insecure deserialization actually are, how they work, and how they're prevented. Input validation and output encoding come up repeatedly. So does parameterized queries as the answer to SQL injection — if you see it as an option, it's almost certainly right.
Also in scope: SDLC models (waterfall, agile, DevOps, DevSecOps), application security testing approaches (SAST looks at source, DAST tests the running app, IAST combines both), third-party and open-source risk, database security fundamentals, and the shift-left principle. When in doubt on a Domain 8 question, favor answers that build security in during design and development rather than bolting it on at test or production.
A pattern I've seen: candidates with non-development backgrounds treat Domain 8 as "only 10% of the exam" and skim it. Then they get 6 out of 10 Domain 8 questions wrong, which is more than enough to tank an otherwise solid score. Give it at least two weeks. OWASP Top 10 at the conceptual level is non-negotiable.
Why the Domains Blur Into Each Other
Real exam questions rarely sit neatly inside one domain. A scenario about an incident response situation (Domain 7) will include logging and monitoring considerations (Domain 6), governance and notification requirements (Domain 1), and access review questions (Domain 5). A cloud architecture scenario touches Domain 3, Domain 4, and Domain 8 at minimum.
This is why "think like a manager" holds up as a heuristic when two answers both look correct. Managers don't evaluate technical questions in isolation — they evaluate them against risk, policy, regulatory obligations, and business impact. The broader, more governance-aware answer wins more often than the narrower technical one. It's also why Domain 1, despite being the most boring-looking domain on paper, carries the most weight. It's the lens through which the exam expects you to read everything else.
Where to Actually Spend Your Time
If you only have limited time and you want a defensible priority order, this is roughly how I'd rank the domains for most candidates:
- Domain 1 — highest weight, most commonly underestimated, trains the exam mindset
- Domain 3 — technically dense, and the biggest gap for non-architects
- Domain 4 — large investment if you don't have a networking background, moderate if you do
- Domain 5 — access control models are tested constantly
- Domain 7 — process and sequence knowledge
- Domain 8 — bigger than its 10% weight suggests if you're not a developer
- Domain 6 — process-oriented, mostly manageable
- Domain 2 — formulaic, learnable in a week
Your order will look different based on your background. A senior network engineer might drop Domain 4 way down and move Domain 1 and Domain 8 way up. A compliance-heavy candidate might invert that. The list above is the default I'd give to someone with no obvious strengths or weaknesses yet.
That last part is the real question. Most people are wrong about where they're weak. They feel shaky on a domain that's actually solid for them and they feel confident on one where they're about to get hammered. The fastest way to fix that is a diagnostic — something that gives you a per-domain accuracy score and tells you, with data, where to start. LearnZapp has a free CISSP diagnostic that covers all eight domains in about 30 minutes, no signup, and gives you a per-domain breakdown plus a study plan targeted at your actual gaps rather than your imagined ones.