The current ISC2 Certified Information Systems Security Professional exam outline has applied since April 15, 2024. As of October 2026 it includes eight domains with published weightings, and ISC2 has announced an updated outline for April 2027. Candidates should verify the edition for their scheduled exam and avoid mixing weighting tables from different years.

Begin with risk ownership, not a technical solution

Security and Risk Management establishes the organizational context: governance, professional ethics, legal and contractual duties, policies, risk assessment, threat modeling, personnel controls, supplier risk, and business continuity planning. The critical distinction is between someone assessing a risk and someone authorized to accept it. A security analyst can recommend treatment; an accountable business owner accepts residual risk under the organization’s governance framework.

Practice with a scenario such as a supplier requiring emergency access to a payment system. Identify the business need, contractual obligations, assets exposed, alternatives, approval authority, and auditability before prescribing remote-access software. This prevents a plausible technical solution from hiding an unanswered governance question.

Protect assets according to their actual value and lifecycle

Asset Security covers classification, handling, retention, privacy, and secure disposal. Not every dataset needs identical controls. Customer records, test data, public marketing material, and confidential source code have different confidentiality, integrity, availability, and retention requirements. A classification scheme should lead to practical consequences, not only labels on documents.

Determine who owns the data and who administers it. The owner decides allowable use; custodians implement controls. Reassess the asset when it is copied, processed by a supplier, backed up, migrated, or no longer needed. A copy kept indefinitely can defeat an otherwise careful deletion process.

Make architecture choices explicit and testable

Security Architecture and Engineering looks at security properties of systems, trust models, cryptography, platform assurance, physical security, and vulnerabilities across different architecture styles. Rather than remembering an algorithm in isolation, ask what property is needed and how keys, authentication, authorized usage, and recovery will be managed.

A system designed for high availability still needs boundary controls. A secure component can become insecure when connected to a higher-trust service with excessive permissions. Evaluate the complete data flow and failure paths, including the ability to recover keys and maintain access-control decisions during outages.

Design networks around trust and failure boundaries

Communication and Network Security includes network design, secure protocols, communication systems, and authorized network access. A firewall is a control point, not an entire security strategy. The design should distinguish the user, device, service, and data being accessed, with appropriate segmentation and observable changes.

An encrypted remote tunnel may prevent interception but does not prove that an authenticated user should reach every internal network. Design least-privilege connectivity, monitor relevant flows, and plan how services fail if a route, DNS resolver, identity provider, or site becomes unavailable.

Govern identities from creation to removal

Identity and Access Management connects identity proofing, authentication, authorization, federation, and provisioning. Strong authentication is important, but stale privileges and poorly governed service accounts can be more damaging than weak passwords. A complete lifecycle defines how access is approved, reviewed, changed, and revoked.

Consider an employee promoted into a new function. The new role may require fresh permissions, but old elevated access should not remain merely because it was once justified. The control should support joiner, mover, and leaver processes, least privilege, exception handling, and evidence for later review.

Verify safeguards independently of design intentions

Security Assessment and Testing checks whether controls actually work. It covers testing strategies, vulnerability management, audit evidence, measurements, reporting, and the evaluation of security processes. A completed checklist is not proof that a safeguard was effective under realistic conditions.

Choose testing methods that can reveal the relevant failure mode. Automated scanning may identify exposed components, while a targeted review is better for segregation-of-duties mistakes or business-logic authorization. Record scope, findings, limits, prioritization, remediation, and verification so decision-makers can distinguish unknowns from confirmed control performance.

Run security operations as a business capability

Security Operations involves monitoring, incident response, investigations, evidence handling, physical and personnel safeguards, recovery, and operational security. It depends on the other domains: asset ownership determines priority; architecture determines what can be isolated; identity governs emergency access; logging determines what investigators can know.

During an incident, containment aims to limit harm, eradication removes the cause, and recovery restores trustworthy capability. Documenting that a server restarted is not the same as demonstrating business recovery. Exercises should test actual dependencies, recovery objectives, communications, and the ability to operate under stress.

Build software security into decisions made early

Software Development Security addresses requirements, secure design, development practices, testing, release controls, acquired software, and maintenance. An application can pass superficial tests and still expose a critical business action through faulty authorization. Teams must determine misuse cases and responsibilities before implementation.

Pipeline credentials, third-party libraries, build artifacts, and deployment approval all affect security. A software bill of materials may improve visibility but cannot replace assessment of reachable vulnerabilities or control ownership. Security continues through patching, incident handling, and retirement, not only code deployment.

Use a single case to connect all eight domains

Suppose a healthcare organization deploys a mobile appointment service. Start with its legal obligations, critical workflows, and risk tolerance. Classify appointment and identity data. Design trusted APIs and encryption. Secure network channels. Govern identities of patients, staff, and software. Test authorization and availability. Prepare response and recovery. Manage the application pipeline and third-party packages.

Now change one assumption: a supplier’s service account is compromised. Which domains become involved? Risk owners decide tolerance for interruption. Data owners define exposure. Architects identify affected trust boundaries. Network and identity teams revoke paths. Assessors confirm what could have been accessed. Operators preserve evidence and restore service. Developers correct design weaknesses. This kind of integrated explanation helps more than eight isolated definitions.

The ISC2 CISSP exam assesses broad security judgment; certification afterward is subject to ISC2’s experience and endorsement requirements. Use the outline as a map, practice multi-domain cases, keep an error log, and measure progress by how clearly you can justify decisions under changing requirements.