CISSP Certified Information Systems Security Professional Exam Topics and Questions

This domain carries the heaviest weight in the exam and sets the foundation for everything that follows. You are expected to know how security aligns with business objectives, how risk decisions are made, and where the legal and ethical boundaries sit. The cost comes in breadth: governance, law, continuity, personnel, and risk management all compete for attention, and a weak area in any one of them will show.

– Ethics, governance, and policy

The ISC2 Code of Ethics is examinable in its ranked structure, not just its content. When two canons conflict, the higher one governs your choice. Organizational ethics, security governance frameworks, and the alignment of security to business strategy all appear here. You need to distinguish due care from due diligence, recognize the role of governance committees in acquisitions and divestitures, and know how frameworks like ISO, NIST, COBIT, and SABSA differ in scope and application. Security policy, standards, procedures, and guidelines form a hierarchy, and the exam expects you to apply the correct level to a given scenario. Roles and responsibilities matter: who owns a control, who implements it, and who audits it are distinct functions.

– Legal, regulatory, and compliance obligations

This group spans cybercrimes, data breaches, intellectual property, import/export controls, transborder data flow, and privacy regulations including GDPR and California's CCPA. You must recognize which legal regime applies to a scenario and what obligations follow. Licensing requirements, contractual obligations, and industry standards all intersect here. Investigation types differ by purpose and constraint: administrative, criminal, civil, regulatory, and industry-driven inquiries each impose different rules on evidence handling, disclosure, and participation. The exam tests whether you can identify the correct investigation type and the compliance requirements it triggers.

– Business continuity and personnel security

Business impact analysis, external dependencies, and continuity requirements form one cluster. You need to know what a BIA delivers, how to prioritize recovery objectives, and where dependencies introduce risk. Personnel security covers the lifecycle: candidate screening, employment agreements, onboarding, transfers, termination, and the controls applied to vendors, consultants, and contractors. Each transition point is a control opportunity and a potential failure mode. Security awareness, education, and training close this group. Methods to counter social engineering and phishing, the role of security champions, gamification, and the need for periodic content reviews all appear. Program effectiveness evaluation is the feedback loop.

– Risk management and threat modeling

Threat and vulnerability identification, risk analysis, risk assessment, and risk treatment are the core cycle. You must know the difference between risk avoidance, mitigation, transfer, and acceptance, and when each is appropriate. Control types (preventive, detective, corrective) and control assessments recur throughout the exam. Continuous monitoring, measurement, reporting, and improvement close the loop. Risk frameworks reappear here, now in the context of risk management rather than governance. Threat modeling methodologies and supply chain risk management complete the group. Supply chain risks include product tampering, counterfeits, and implants; mitigations include third-party assessment, minimum security requirements, service level agreements, and silicon root of trust. Software bill of materials is now an examinable concept.

How Security and Risk Management is tested

At sixteen percent, this domain generates roughly one in six items. Questions demand that you choose the best response when multiple answers are defensible, often by weighing business impact against technical purity. You will encounter scenarios where ethics, law, and policy intersect, and the correct answer turns on which obligation ranks highest. Risk items frequently present a threat, a set of controls, and a residual risk, then ask what to do next. The trap is choosing the most secure option rather than the most proportionate one. Business continuity items test prioritization under resource constraints: you cannot save everything, so the BIA drives the choice. Personnel security questions hinge on timing (when a control applies in the lifecycle) and scope (who is subject to it). Awareness program questions reward answers that measure effectiveness rather than activity. Candidates lose marks by selecting the answer that sounds most comprehensive rather than the one that matches the scenario's actual constraint.

Where the first domain addressed risk and governance broadly, this one narrows to the information and assets you are protecting. Asset Security covers classification, handling, ownership, lifecycle, retention, and destruction. At ten percent it is the lightest domain, but it concentrates concepts that recur in later topics: data states, data roles, and the controls that follow from classification decisions. The cost is precision. Mixing up a data controller and a data processor, or confusing data remanence with data retention, will flip your answer.

How Asset Security is tested

Ten percent weight translates to roughly fifteen items. Questions present a scenario involving data in a particular state (in use, in transit, at rest) and ask which control applies or which role is responsible. The exam expects you to match the control to the classification level and the lifecycle stage. Data roles are tested through accountability questions: who decides retention, who enforces destruction, who audits compliance. The trap is assuming the same person does all three. Asset handling items test whether you recognize that classification drives handling requirements, not the reverse. Retention and destruction questions reward answers that comply with legal or regulatory obligations over operational convenience. Data remanence items test whether you know that deletion is not destruction. Candidates lose marks by choosing controls that protect the wrong state, by assigning responsibility to the wrong role, or by selecting a technical control when the scenario calls for a procedural one. The domain is small, but every item punishes imprecision.

This domain moves from governance and data to the systems that process and protect them. Security Architecture and Engineering covers secure design principles, security models, cryptographic solutions, system vulnerabilities, and physical security. At thirteen percent it is one of the heavier domains, and the breadth is punishing: you move from threat modeling and least privilege to cryptanalytic attacks, then to site security and the information system lifecycle. The technical depth is greater here than in the previous two domains, and the cost is in the details. Knowing that defense in depth is a principle is not enough; you must recognize when a design violates it.

– Secure design principles and security models

Threat modeling, least privilege, defense in depth, secure defaults, fail securely, separation of duties, simplicity, zero trust, privacy by design, and shared responsibility are the principles. Each one shapes design decisions, and the exam tests whether you can identify which principle a scenario violates or satisfies. Security models (Biba, Bell-LaPadula, Star Model) are tested for their properties, not their history. You need to know what each model enforces and where it applies. Control selection follows from system security requirements: the requirements drive the controls, not the reverse. Security capabilities of information systems (memory protection, Trusted Platform Module, encryption/decryption) are the building blocks. Recognizing when a capability is present but misconfigured is the sharper edge of this group.

– Vulnerabilities across system architectures

Client-based, server-based, database, cryptographic, industrial control, cloud, distributed, IoT, microservices, containerization, serverless, embedded, high-performance computing, edge computing, and virtualized systems each carry distinct vulnerabilities. The exam expects you to assess and mitigate them. You are not memorizing a list; you are recognizing patterns. Containers share a kernel, so isolation is weaker than with virtual machines. Serverless architectures shift attack surface to the function runtime and its dependencies. IoT devices often lack secure update mechanisms. Edge computing moves processing closer to the data source, which moves the security boundary. The breadth is deliberate: the exam is testing whether you can transfer principles across architectures rather than recite a control checklist for one.

– Cryptographic solutions and cryptanalytic attacks

Cryptographic lifecycle, algorithm selection, symmetric and asymmetric methods, elliptic curves, quantum cryptography, and public key infrastructure all appear. You must know when to apply each method and what the lifecycle demands at each stage. Key management is where most implementations fail, and the exam knows it. Cryptanalytic attacks follow: brute force, ciphertext only, known plaintext, frequency analysis, chosen ciphertext, implementation attacks, side-channel, fault injection, timing, man-in-the-middle, pass the hash, Kerberos exploitation, and ransomware. The exam tests whether you can identify the attack type from a scenario and select the mitigation that addresses the actual vulnerability rather than a related but irrelevant one.

– Physical security and system lifecycle

Site and facility design, wiring closets, server rooms, data centers, media storage, evidence storage, restricted areas, utilities, HVAC, environmental issues, fire prevention, detection, suppression, and power redundancy form the physical security group. Each control has a purpose, and the exam tests whether you can match the control to the threat. The information system lifecycle closes the domain: stakeholder needs, requirements analysis, architectural design, development, integration, verification, validation, transition, operations, maintenance, and disposal. Each phase has security activities, and the exam expects you to know which activities belong where and what happens when one is skipped.

How Security Architecture and Engineering is tested

Thirteen percent weight produces roughly twenty items. Questions present a system architecture or design decision and ask you to identify the vulnerability, select the control, or choose the principle that applies. The trap is choosing the control that addresses a different threat. Cryptographic items test lifecycle and key management more than algorithm internals; you lose marks by selecting an algorithm that is secure in theory but misapplied in the scenario. Cryptanalytic attack questions reward answers that mitigate the specific attack described, not attacks in general. Physical security items test proportionality: the control must match the asset value and the threat likelihood. Lifecycle questions hinge on sequence: activities out of order produce vulnerabilities, and the exam expects you to spot them. Candidates lose marks by choosing technically sophisticated answers when the scenario calls for foundational controls, or by selecting a control for one architecture and applying it to another where it does not fit.

From system architecture you move to the networks that connect them. Communication and Network Security covers network design principles, secure protocols, segmentation, wireless and cellular networks, content distribution, software-defined networking, and secure communication channels. At thirteen percent it matches the previous domain in weight, and the technical detail is equally demanding. The cost is in layering: protocols stack, segments nest, and a misconfiguration at one layer propagates through the others. You must think in terms of traffic flow, control plane versus data plane, and the trust boundaries that segmentation creates or violates.

– Network architecture and protocols

The OSI and TCP/IP models provide the structure, but the exam tests application, not recitation. IPv4 and IPv6 addressing, unicast, broadcast, multicast, and anycast all appear. Secure protocols (IPSec, SSH, SSL/TLS) are tested for their properties and the threats they mitigate. Implications of multilayer protocols and converged protocols (iSCSI, VoIP, InfiniBand over Ethernet, Compute Express Link) test whether you understand how convergence changes the attack surface. Transport architecture (topology, data/control/management plane separation, cut-through versus store-and-forward) and performance metrics (bandwidth, latency, jitter, throughput, signal-to-noise ratio) form the engineering foundation. Traffic flows (north-south, east-west) matter because they define where inspection and segmentation must occur.

– Segmentation, wireless, and software-defined networks

Physical segmentation (in-band, out-of-band, air-gapped), logical segmentation (VLANs, VPNs, virtual routing and forwarding, virtual domains), and micro-segmentation (network overlays, distributed firewalls, routers, IDS/IPS, zero trust) are the layers of defense. Each type of segmentation creates a boundary, and the exam tests whether you recognize what crosses it and what control applies there. Edge networks (ingress/egress, peering), wireless (Bluetooth, Wi-Fi, Zigbee, satellite), cellular (4G, 5G), content distribution networks, software-defined networks (API, SD-WAN, network functions virtualization), and Virtual Private Cloud complete the group. SDN items test whether you understand that control plane separation introduces new risks even as it improves agility. Monitoring and management (network observability, traffic flow and shaping, capacity management, fault detection and handling) close the group.

– Securing network components and communication channels

Operation of infrastructure (redundant power, warranty, support), transmission media (physical security, signal propagation quality), network access control systems (physical and virtual), and endpoint security (host-based) form the component security group. Each component is a control point and a potential failure. Secure communication channels (voice, video, collaboration, remote access, data communications, third-party connectivity) complete the domain. The exam tests whether you can select the appropriate channel security for the data classification and the threat model. Remote access for administrative functions demands stronger controls than remote access for general users, and the exam expects you to recognize the difference.

How Communication and Network Security is tested

Thirteen percent weight yields roughly twenty items. Questions present a network design, a traffic flow, or a protocol stack and ask you to identify the vulnerability or select the control. The trap is choosing a control that works at the wrong layer. Segmentation items test whether you recognize that logical segmentation can be bypassed if the underlying physical network is not secured. Wireless and cellular questions reward answers that address the specific protocol's weakness rather than wireless security in general. Software-defined networking items test whether you understand that centralizing control creates a high-value target. Secure channel questions hinge on matching the channel security to the data classification and the threat: encrypting the channel is not enough if the endpoints are compromised. Candidates lose marks by selecting controls that address confidentiality when the scenario demands integrity, or by choosing a solution that secures one layer while leaving another exposed.

Where the previous domain secured the network, this one secures the identities that traverse it. Identity and Access Management covers physical and logical access control, authentication, authorization, credential management, federated identity, and the provisioning lifecycle. At thirteen percent it is another heavy domain, and the cost is in the details of access policy: who is authenticated, what they are authorized to do, when the authorization expires, and how the decision is enforced. The exam tests whether you can trace the path from identity to access decision and spot where it breaks.

– Access control, authentication, and identity strategy

Controlling physical and logical access to information, systems, devices, facilities, applications, and services is the foundation. The exam expects you to know which control applies to which asset type and where dual controls are required. Authentication strategy (for people, devices, and services), groups and roles, AAA (multi-factor authentication, passwordless authentication), session management, registration and proofing, federated identity management, credential management systems (password vaults), single sign-on, and just-in-time access all appear. The distinction between authentication (who you are) and authorization (what you may do) is tested repeatedly, often in scenarios where one is strong and the other is weak. Federated identity with third-party services (on-premise, cloud, hybrid) tests whether you understand where the trust boundary sits and what happens when federation is misconfigured.

– Authorization mechanisms and provisioning lifecycle

Role-based access control, rule-based access control, mandatory access control, discretionary access control, attribute-based access control, and risk-based access control are the models. Each has properties, and the exam tests whether you can match the model to the requirement. Access policy enforcement (policy decision point, policy enforcement point) tests whether you understand that the decision and the enforcement are separate functions and that compromise of either breaks the control. The provisioning lifecycle (account access review, provisioning and deprovisioning, role definition and transition, privilege escalation, service accounts management) closes the domain. Each lifecycle stage is a control opportunity. The exam tests whether you recognize when a control is missing or when a transition is not logged. Privilege escalation (use of sudo, auditing its use) and service accounts management are frequent sources of missed items, because candidates treat them as operational rather than security concerns.

How Identity and Access Management (IAM) is tested

Thirteen percent weight produces roughly twenty items. Questions present an access scenario, describe the controls in place, and ask what is missing or what fails. The trap is assuming that strong authentication compensates for weak authorization, or that a well-defined role structure compensates for poor provisioning hygiene. Federated identity items test trust boundaries: when identity is asserted by a third party, the exam expects you to know what you can verify and what you must accept. Authorization model questions reward answers that match the model to the policy requirement, not the model that sounds most sophisticated. Lifecycle items test timing and logging: the correct answer often turns on when a privilege is granted or revoked, and whether the action is auditable. Candidates lose marks by choosing technical controls when procedural ones are needed, by assuming that access reviews happen automatically, or by selecting an authorization model that cannot enforce the policy described in the scenario.

From access control you move to verification. Security Assessment and Testing covers the design and execution of assessments, control testing, process data collection, output analysis, and audits. At twelve percent it is mid-weight, but the domain is dense: every other domain's controls reappear here as the subject of testing. The cost is in knowing not just what a control does, but how to test whether it works, what evidence proves it, and what to do when it fails. You are expected to choose the right test type, interpret the results, and recommend remediation that is proportionate to the risk.

– Assessment strategy and control testing

Assessment, test, and audit strategies differ by scope: internal (within organizational control), external (outside organizational control), third-party (outside enterprise control), and by location (on-premises, cloud, hybrid). Each combination changes what you can test and how. Control testing methods include vulnerability assessment, penetration testing (red, blue, purple team exercises), log reviews, synthetic transactions, code review and testing, misuse case testing, coverage analysis, interface testing (user interface, network interface, API), breach attack simulations, and compliance checks. The exam tests whether you can select the method that matches the control type and the risk appetite. Penetration testing is not always the answer; sometimes a log review or a compliance check is more appropriate. Misuse case testing and coverage analysis appear less frequently in study materials but are tested, so candidates who skip them lose marks.

– Process data collection, output analysis, and audits

Security process data collection spans account management, management review and approval, key performance and risk indicators, backup verification data, training and awareness, and disaster recovery and business continuity. The exam expects you to know what data proves a control is operating and where gaps in the data indicate control failure. Analyzing test output and generating reports involves remediation, exception handling, and ethical disclosure. Remediation must be prioritized by risk, not by ease. Exception handling tests whether you know when an exception is justified and who approves it. Ethical disclosure tests whether you understand the obligation to report a vulnerability and the constraints on how and when. Conducting or facilitating security audits closes the domain. The exam tests whether you recognize the auditor's role, the auditee's obligations, and what constitutes audit evidence.

How Security Assessment and Testing is tested

Twelve percent weight yields roughly eighteen items. Questions present a control, describe a test, and ask whether the test is sufficient or what the results mean. The trap is assuming that any test is better than no test, or that a passing result means the control works in all scenarios. Vulnerability assessment and penetration testing items test whether you can distinguish between them: one finds weaknesses, the other exploits them, and the choice depends on what you need to prove. Log review questions reward answers that recognize what the log should contain and what its absence means. Code review and interface testing items test whether you understand that a secure implementation can still fail if the interface is misused. Output analysis questions hinge on proportionality: not every finding demands immediate remediation, and the exam expects you to prioritize by risk. Candidates lose marks by recommending remediation that exceeds the risk, by choosing a test method that cannot produce the evidence needed, or by assuming that compliance checks are sufficient when control effectiveness is the question.

Security Operations is the largest domain by sub-topic count and matches the heaviest domains in weight at thirteen percent. It covers investigations, logging and monitoring, configuration management, foundational operations concepts, resource protection, incident management, detection and prevention measures, patch and vulnerability management, change management, recovery strategies, disaster recovery processes, business continuity, physical security, and personnel safety. The breadth is deliberate: operations is where every other domain's controls are implemented, maintained, and tested under live conditions. The cost is in recognizing which operational activity applies to a scenario and what happens when process discipline breaks down.

– Investigations, logging, monitoring, and configuration management

Investigations differ by type: administrative, criminal, civil, regulatory, and industry standards. Each imposes different rules on evidence collection and handling, reporting, documentation, investigative techniques, digital forensics tools, and artifacts (data, computer, network, mobile device). The exam tests whether you know which rules apply and what happens when they are violated. Logging and monitoring activities include intrusion detection and prevention, SIEM, continuous monitoring and tuning, egress monitoring, log management, threat intelligence (threat feeds, threat hunting), and user and entity behavior analytics. The exam expects you to know what each tool detects, what it misses, and how to tune it. Configuration management (provisioning, baselining, automation) closes this group. Baseline drift is a frequent source of vulnerabilities, and the exam tests whether you recognize it and know how to prevent it.

– Foundational operations concepts and resource protection

Need-to-know, least privilege, separation of duties and responsibilities, privileged account management, job rotation, and service-level agreements are the foundational concepts. Each one shapes operational decisions, and the exam tests whether you can identify when a concept is violated. Resource protection (media management, media protection techniques, data at rest and in transit) tests whether you can match the protection to the data state and the classification. The exam expects you to know that protecting data at rest does not protect it in transit, and that both must be addressed.

– Incident management and detection measures

Incident management follows a sequence: detection, response, mitigation, reporting, recovery, remediation, and lessons learned. The exam tests whether you know what happens at each stage and what triggers the transition to the next. Detection and preventative measures include firewalls (next generation, web application, network), IDS and IPS, whitelisting and blacklisting, third-party provided security services, sandboxing, honeypots and honeynets, anti-malware, and machine learning and AI-based tools. Each measure has a purpose, and the exam tests whether you can select the one that addresses the threat in the scenario. Honeypots and sandboxing appear less frequently in study materials, so candidates who skip them lose marks.

– Patch management, change, recovery, and continuity

Patch and vulnerability management, change management processes, recovery strategies (backup storage, recovery site strategies, multiple processing sites, system resilience, high availability, quality of service, fault tolerance), disaster recovery processes (personnel, communications, assessment, restoration, training and awareness), disaster recovery plan testing (read-through, walkthrough, simulation, parallel, full interruption, communications), and business continuity planning and exercises complete the domain. Each process has steps, and the exam tests whether you know the sequence and what happens when a step is skipped. Recovery site strategies (cold versus hot, resource capacity agreements) test whether you can match the strategy to the recovery time objective. DR plan testing methods differ in cost and realism, and the exam expects you to choose the method that balances both.

– Physical security and personnel safety

Physical security (perimeter security controls, internal security controls) and personnel safety and security concerns (travel, security training and awareness including insider threat, social media impacts, two-factor authentication fatigue, emergency management, duress) close the domain. Physical security items test whether you understand that physical access often bypasses logical controls. Personnel safety items test whether you recognize threats that arise from travel, social engineering, and duress, and what controls mitigate them. Two-factor authentication fatigue is a newer concept and a frequent source of missed items.

How Security Operations is tested

Thirteen percent weight produces roughly twenty items. Questions present an operational scenario, describe what is in place, and ask what is missing or what happens next. The trap is choosing the most secure answer rather than the most operationally feasible one. Incident management items test sequence: the correct answer often depends on what stage the incident has reached. Detection and prevention items test whether you can match the tool to the threat: a firewall and an IDS both inspect traffic, but they do different things with it. Patch and vulnerability management items test prioritization: not every vulnerability demands immediate patching, and the exam expects you to weigh risk against operational impact. Recovery and DR items test whether you understand the difference between a strategy and a plan, and whether you can select the recovery method that meets the objective. Candidates lose marks by choosing answers that assume unlimited resources, by selecting a detection tool when a prevention control is needed, or by recommending a DR test method that is more disruptive than the scenario justifies.

The final domain addresses the security of software itself. Software Development Security covers the software development lifecycle, security controls in development ecosystems, software security effectiveness, acquired software, and secure coding. At ten percent it matches Asset Security as the lightest domain, but the technical detail is sharp: you must know where in the lifecycle security activities occur, what controls apply to development tools and environments, and how to assess software you did not write. The cost is in recognizing that security is not added at the end; it is integrated at every phase, and skipping it anywhere produces vulnerabilities that reach production.

– Software development lifecycle and ecosystem controls

Development methodologies (Agile, Waterfall, DevOps, DevSecOps, Scaled Agile Framework), maturity models (Capability Maturity Model, Software Assurance Maturity Model), operation and maintenance, change management, and integrated product teams form the lifecycle group. The exam expects you to know which security activities belong in each phase and what happens when they are skipped. DevSecOps items test whether you understand that security is integrated into the pipeline, not bolted on afterward. Security controls in development ecosystems include programming languages, libraries, tool sets, integrated development environments, runtime, CI/CD, software configuration management, code repositories, and application security testing (SAST, DAST, software composition analysis, IAST). Each control addresses a different risk, and the exam tests whether you can select the one that matches the threat. SAST finds vulnerabilities in source code; DAST finds them in running applications; software composition analysis finds them in dependencies. Choosing the wrong test type is a frequent source of missed marks.

– Assessing software security and secure coding

Assessing the effectiveness of software security involves auditing and logging of changes, and risk analysis and mitigation. The exam tests whether you know what evidence proves a control works and what to do when it fails. Assessing security impact of acquired software (COTS, open source, third-party, managed services, cloud services including SaaS, IaaS, PaaS) tests whether you can evaluate software you did not write and do not control. The risks differ by acquisition type, and the exam expects you to recognize them. Secure coding guidelines and standards close the domain: security weaknesses and vulnerabilities at the source-code level, security of APIs, secure coding practices, and software-defined security. The exam tests whether you can identify a coding weakness from a description and select the practice that prevents it. API security items are increasingly common, and candidates who treat APIs as afterthoughts lose marks.

How Software Development Security is tested

Ten percent weight yields roughly fifteen items. Questions present a development scenario, describe the methodology or tooling, and ask what security control is missing or what risk remains. The trap is assuming that any testing is sufficient, or that a secure design compensates for insecure implementation. Lifecycle items test whether you know which phase a security activity belongs in: threat modeling happens during design, not after deployment. Ecosystem control items test whether you can match the tool to the risk: SAST cannot find runtime vulnerabilities, and DAST cannot find them in code paths that are not exercised. Acquired software items test whether you recognize that you inherit the risk even when you do not write the code. Secure coding items test whether you can identify the weakness and the practice that prevents it, often from a brief code description rather than actual code. Candidates lose marks by choosing a control that applies to a different phase, by selecting a test type that cannot find the vulnerability described, or by assuming that third-party software is secure because it is widely used.