CISSP Exam Domains

How the outline and weights work

ISC2's CISSP exam outline is the authoritative map of what the examination can test. Its current version became effective April 15, 2024. The domains group related professional responsibilities, from governance and risk through engineering, assessment, operations, and secure software development. The outline includes task statements under each domain; those tasks, rather than a prep provider's shortened topic list, define the study scope.

The listed weight is the share of scored exam content assigned to a domain. It is useful for deciding how much review attention a subject deserves, but it is not a promise that a fixed number of questions will appear. The English CISSP uses computerized adaptive testing and may present 100 to 150 items. A candidate cannot calculate a domain's exact item count from the percentage or infer the exam result from a short practice set.

1. Security and Risk Management: 16%

This domain is the broadest and carries the largest weight. It includes security governance and principles, organizational roles, policy, professional ethics, legal and regulatory responsibilities, risk management, business continuity, personnel security, and awareness. The recurring question is how security supports the organization's purpose while managing exposure within the authority and appetite it has set.

Know the difference between a threat, vulnerability, likelihood, impact, and risk. A vulnerability is a weakness; a threat source may exploit it; risk expresses the possibility and consequence in context. A control can reduce likelihood, impact, or both. Risk acceptance belongs to an accountable owner, not automatically to the security analyst who identifies the issue. The security role is to assess, communicate, and recommend treatment through governance.

Governance scenarios also test sequence. If a business unit introduces an unapproved system, first understand the data, purpose, and applicable requirements. Then use the organization's risk and procurement processes to decide whether to approve, mitigate, transfer, or reject the risk. Jumping straight to a technical setting before learning the business context often misses the governance task.

2. Asset Security: 10%

Asset Security concerns information and asset handling through their life cycle. Learn how ownership, classification, labeling, retention, storage, transfer, and disposal work together. Classification communicates sensitivity and handling needs; ownership identifies the business authority responsible for decisions. A custodian may operate safeguards but does not automatically become the information owner.

Data can be exposed at rest, in transit, or in use. The appropriate safeguards depend on the information and its use: encryption, access control, approved transfer, retention limits, backups, or verified destruction may be relevant. Retention is not simply “keep everything.” Legal holds, business requirements, privacy rules, and records schedules can constrain deletion or require it after the authorized period.

A useful scenario distinction is to separate a technical storage location from the classification decision. If a team copies sensitive records into a new service, moving the files does not change their classification or the handling requirements. The owner and security process should determine whether the destination, access, encryption, retention, and disposal controls remain appropriate.

3. Security Architecture and Engineering: 13%

This domain asks how systems are designed and engineered to meet security requirements. Relevant concepts include security models, trust boundaries, secure design principles, system components, cryptographic applications, resilience, and the protection of environments such as cloud, virtualized, and embedded systems. Learn the purpose of a control and the architectural layer at which it operates.

Cryptography questions usually test which security property is needed. Encryption protects confidentiality; a message authentication code or digital signature can support integrity and authenticity; a digital signature also provides evidence of origin under the relevant key and trust model. Hashing creates a fixed-length digest but does not encrypt the original data. Do not select a cryptographic mechanism merely because it sounds strongest; match it to the stated goal.

A secure design constrains trust and limits the consequences of failure. Defense in depth uses complementary controls; least privilege limits what a component or user can do; fail-safe defaults deny access unless it is authorized. The best design is not always the one with the most controls. It must meet security objectives without violating availability, safety, or operational requirements.

4. Communication and Network Security: 13%

Study network architecture, secure communication, protocols, devices, remote access, segmentation, and common network threats. Trace where a connection begins, which boundaries it crosses, and which party controls the relevant device or service. Understand the function of routing, switching, firewalls, proxies, VPNs, and monitoring systems well enough to distinguish their jobs.

Segmentation reduces unnecessary paths and can contain a compromise, but a network zone does not grant trustworthy identity by itself. Encryption protects data in transit but does not repair a compromised endpoint or grant the right user access. A firewall rule can restrict traffic without proving that the allowed application is safe. Scenarios often reward combining controls while identifying the primary objective.

For a remote-access question, clarify the user, device, destination, and data sensitivity. Authentication establishes the user or device claim; authorization limits permitted actions; encrypted transport protects the connection; endpoint controls and monitoring address other risks. A single VPN connection does not replace identity governance or application-level access decisions.

5. Identity and Access Management: 13%

IAM covers identity proofing and lifecycle, authentication, authorization, access control models, federation, and accountability. Identification names a subject; authentication tests a claim about that identity; authorization determines what the subject may do. Accounting or logging records activity. Keeping these functions separate helps you choose the control a scenario actually needs.

Learn how role-based access control assigns permissions through roles and how attribute-based policies can evaluate properties of a subject, resource, action, or environment. Least privilege grants only necessary rights. Separation of duties reduces the chance that one person can complete an incompatible process alone. Periodic access review checks whether previously granted rights remain appropriate.

Identity is not a one-time onboarding task. Provisioning should follow authorization; a change in role should prompt a review and adjustment; termination should revoke access promptly and recover assigned assets. Shared accounts weaken attribution. Strong authentication helps verify a subject but does not justify broad permissions. Pair identity controls with authorization and monitoring.

6. Security Assessment and Testing: 12%

This domain covers audit and assessment, security testing, vulnerability management, control validation, metrics, and reporting. Match the method to the objective. A vulnerability scan compares observed systems with known weaknesses. A penetration test attempts controlled exploitation within an agreed scope. An audit evaluates evidence against defined criteria. These methods answer different questions and are not interchangeable.

Assessment quality depends on scope, authorization, evidence, and independence. A test that excludes a critical environment cannot support a conclusion about that environment. A finding needs enough context to establish impact and a responsible owner for remediation or risk acceptance. Metrics should help a decision maker understand exposure or control performance; a large dashboard is not useful merely because it contains many numbers.

For audit evidence, consider relevance, reliability, sufficiency, and source. A system-generated access log may be more reliable than an unauthenticated verbal summary, but the log's configuration, completeness, and time synchronization still matter. Conclusions should be supported by evidence that actually tests the control objective.

7. Security Operations: 13%

Security Operations includes incident handling, logging, monitoring, investigations, operational change, recovery, and physical security. An incident process defines preparation, detection, analysis, containment, eradication, recovery, and lessons learned. The sequence is contextual: contain urgent harm, preserve evidence, and coordinate through the assigned incident authority.

Know the difference between backup, disaster recovery, and business continuity. A backup is a copy used to restore data; disaster recovery restores technology services; business continuity sustains important business functions during disruption. Recovery time and recovery point objectives describe different tolerances: one concerns downtime and the other acceptable data loss. A plan is not reliable until it is exercised and updated.

Change management and configuration management preserve accountability and reduce avoidable outages. Emergency changes still need an authorized process and later review. Logging supports detection and investigation, but logs should be protected, retained appropriately, and reviewed. When evidence may be needed, preserve originals and document handling rather than improvising collection.

8. Software Development Security: 10%

Software Development Security follows a system from requirements through design, development, testing, release, and maintenance. Security belongs in requirements and architecture, not only in a final test. Threat modeling helps identify assets, entry points, trust boundaries, and plausible misuse before implementation. Secure coding practices and code review can prevent common classes of defects.

Different tests discover different problems. Static analysis examines code without executing it; dynamic testing observes an executing system; dependency analysis identifies risk in third-party components; penetration testing probes a deployed environment within authorization. A passed test does not prove that software is secure in every configuration or threat context.

Change and release controls preserve integrity: protect source repositories, separate duties where needed, review code, test changes, approve releases, and maintain rollback options. Security exceptions should have an owner and a reason. After release, monitor vulnerabilities and maintain components through a controlled patch process.

How domain concepts combine in a scenario

A company learns that a contractor's account exported a sensitive dataset from a cloud-hosted application. The question asks for the best immediate response. IAM helps determine whether the identity and privileges should be contained. Security Operations supplies the incident process and evidence preservation. Asset Security identifies the data's classification and handling rules. Risk Management establishes decision authority and potential reporting duties.

Do not answer as though only one domain exists. First identify what the question asks: immediate containment, investigation, long-term control improvement, or notification. Then apply the relevant policy and role authority. If the account is actively misused, scoped containment and evidence preservation may be appropriate while the organization determines what was accessed. Broadly shutting down the service may be disproportionate; deleting the logs would undermine the investigation.

Original worked question: match control to objective

A finance application already requires multifactor authentication. A review finds that every analyst can approve and release their own payment batches, even when they do not manage the vendor. Which control change most directly addresses the identified risk?

1. A. Require a longer password for all analysts.
2. B. Separate payment preparation from approval or release and assign the roles to different authorized people.
3. C. Encrypt the payment database at rest.
4. D. Add more network monitoring alerts for the finance subnet.

Answer: B. The scenario identifies an incompatible access arrangement: one person can prepare and approve the same transaction. Separation of duties and role-based authorization directly address that risk. Multifactor authentication proves more reliably which person is acting, but it does not prevent that authenticated person from holding excessive permissions. Encryption protects stored data, and network alerts may support detection, but neither prevents the conflict of authority.

Read task verbs as clues to the expected judgment

The outline's task statements describe work a security professional should be able to perform. When a statement asks you to establish, implement, or manage something, ask what authority, sequence, and evidence that work requires. When it asks you to assess or verify, look for a method that produces evidence against a defined objective. When it asks you to recommend or support, identify the decision owner and the information that owner needs.

Task verbs do not create a mechanical answer key. A real scenario can include several valid activities, but the question usually narrows the choice with a role, priority, or timing cue. For example, an analyst can identify a risk and recommend treatment, while an accountable business owner accepts residual risk. A tester can report a weakness, while the system owner approves a remediation window. Reading the task in terms of responsibility helps you choose the action appropriate to the role.

Use each detailed task as a learning objective: explain the concept, identify who is responsible, recognize evidence of success, and name one limitation. This gives your revision enough depth to transfer to a new scenario instead of repeating a glossary definition.

How to study the domains without memorizing a list

Read the official outline task by task. For each task, write a one-sentence statement of the decision or responsibility it describes, then add one control and one limitation. For instance: IAM limits access through authorization; authentication alone does not determine what an authenticated person can do. The limitation often becomes the clue that helps distinguish neighboring concepts.

After learning a concept, retrieve it without notes and use it in a new situation. Mix scenarios from different domains so you practice recognizing the issue rather than receiving a topic label. Review errors by asking whether the miss came from missing knowledge, overlooking a constraint, or selecting a valid action at the wrong stage. A fixed question count per domain is not useful because the CAT exam's item total varies.

The percentage weights can guide your calendar: schedule slightly more review for Security and Risk Management and maintain consistent practice in the other domains. Do not ignore a 10% area or spend all your time on the largest one. The passing standard applies to the exam as a whole, and a weak area can still affect the overall result.