CISSP Domain 1 Revision: Security and Risk Management

Domain 1 carries the heaviest weighting on the CISSP exam, and for good reason. Everything else you study sits on top of it. Get the governance, risk, legal and ethical foundations wrong here and the later domains start to feel like technical detail floating without a frame. This is the domain where ISC2 wants to know whether you think like a security leader rather than a technician who happens to hold a clipboard.

What follows is a revision pass through the eleven objectives, written to be read rather than memorised in isolation. Treat it as a companion to your primary study material, not a replacement for it.

Professional ethics: the exam's favourite trap

ISC2's Code of Professional Ethics sits in a strict order of preamble and canons:

Protect society, the common good, necessary public trust and confidence, and the infrastructure.
Act honourably, honestly, justly, responsibly, and legally.
Provide diligent and competent service to principals.
Advance and protect the profession.

The order matters more than most candidates expect. When a scenario question presents a conflict between, say, loyalty to an employer and the wider public interest, canon one wins. Candidates who answer from instinct rather than the hierarchy tend to pick the answer that protects the company or the client first, which is precisely the trap being set.

Organisational codes of ethics sit underneath this. They cannot contradict the ISC2 code, but they can be more specific: acceptable use policies, conflict of interest declarations, whistleblowing procedures. Know the distinction between the two layers, because exam writers like to test whether you understand which one takes precedence.

The pillars: CIA and beyond

Confidentiality, integrity and availability remain the backbone, but the current exam outline adds authenticity and non-repudiation explicitly, so don't treat these as an afterthought.

Confidentiality: preventing unauthorised disclosure. Encryption, access control, classification.
Integrity: preventing unauthorised or accidental modification. Hashing, digital signatures, change control.
Availability: ensuring authorised access when needed. Redundancy, fault tolerance, disaster recovery.
Authenticity: assurance that data, transactions or communications are genuine. This underpins digital signatures and PKI.
Non-repudiation: the inability of a party to deny having performed an action. Digital signatures again, but also audit logging and timestamping.

A common exam pattern presents a scenario and asks which pillar was violated. Read carefully. A system going offline during a DDoS attack is an availability failure. An employee altering financial records without authorisation is an integrity failure. Someone denying they sent a fraudulent wire transfer instruction, when logs prove otherwise, is a non-repudiation issue rather than a confidentiality one. The distinctions are the whole point of the question.

Security governance: aligning security with the business

This objective tests whether you understand security as a function of the business rather than a function that sits beside it. Security strategy should trace back to business strategy, goals and mission. If your organisation's mission is rapid product delivery, a governance model built entirely around risk aversion will create friction that eventually gets security cut out of decisions altogether.

Organisational processes worth knowing:

Mergers, acquisitions and divestitures: due diligence during acquisition should include a security assessment of the target company's infrastructure, culture and existing incidents. Divestiture carries its own risk: data segregation, access revocation, and ensuring departing business units don't retain access to systems they no longer need.
Governance committees: steering committees, risk committees, and boards where security reports upward. Know that governance is about oversight and accountability, not day-to-day operational control.

On roles and responsibilities, the exam expects you to distinguish between the board (accountable), senior management (responsible for setting policy and resourcing), data owners (classification and access decisions), data custodians (day-to-day handling), and users (compliance with policy).

Security control frameworks come up often enough to be worth memorising by purpose rather than name alone:

ISO 27001/27002: information security management system (ISMS), the international standard.
NIST CSF / SP 800-53: US federal risk management, control catalogue.
COBIT: IT governance, aligning IT with business objectives.
SABSA: business-driven security architecture, risk-focused.
PCI DSS: payment card data protection, industry mandated.
FedRAMP: cloud service authorisation for US federal agencies.

Finally, due care and due diligence. Due diligence is the research: understanding the risk before acting. Due care is the action: implementing reasonable protections based on that understanding. A useful shorthand is that diligence is the investigation, care is the follow-through. Failing either exposes an organisation to negligence claims.

Legal, regulatory and compliance: a genuinely global remit

This objective has grown considerably as CISSP has become a more international qualification, and it now expects familiarity well beyond US law.

Cybercrime and data breach law varies by jurisdiction, but the exam tends to test general categories rather than statute numbers: computer fraud, unauthorised access, and the distinction between civil and criminal liability for breaches.

Intellectual property comes in four flavours worth keeping straight:

Copyright: protects expression, not ideas. Automatic on creation.
Patent: protects inventions. Requires registration, time limited, strongest protection but hardest to obtain.
Trademark: protects brand identifiers, logos, names.
Trade secret: protects confidential business information indefinitely, provided reasonable measures are taken to keep it secret.

Import and export controls matter more than candidates often expect, particularly around cryptographic technology. Products with strong encryption can be subject to export licensing requirements, and the exam may test your awareness that moving certain security tools across borders isn't always a simple technical exercise.

Transborder data flow is closely related. Once data crosses a border, it can become subject to a second country's laws, sometimes in direct conflict with the first. This is the practical reason multinational organisations spend so much on data residency and localisation strategies.

Privacy law is worth knowing at the level of purpose rather than clause number:

GDPR (EU): consent, right to erasure, data protection by design, extraterritorial reach for any organisation processing EU residents' data.
CCPA (California): consumer right to know what data is collected and to opt out of its sale.
PIPL (China): strict rules on cross-border transfer of personal data, similar in spirit to GDPR but with distinct enforcement.
POPIA (South Africa): consent and accountability principles broadly aligned with GDPR.

You don't need statute-level detail. You need to recognise the pattern each represents and reason from principle when a scenario question drops you into an unfamiliar regulation.

Investigation types

Four categories, and the exam likes to test the standard of proof and purpose behind each:

Administrative: internal, often HR-driven, lowest standard of proof, aimed at policy violations.
Criminal: prosecuted by the state, "beyond reasonable doubt", can result in imprisonment.
Civil: between parties, "preponderance of the evidence", results in damages rather than imprisonment.
Regulatory: conducted by a regulator against a standard such as HIPAA or PCI DSS, can carry criminal or civil elements depending on the finding.

If a scenario mentions law enforcement involvement, chain of custody, and possible imprisonment, you're in criminal territory. If it's a dispute over damages between two companies, that's civil.

Policy, standards, procedures and guidelines

Know the hierarchy and the binding strength of each:

Policy: high level, mandatory, sets intent.
Standard: mandatory, specific, defines how policy is implemented (a required configuration baseline, for example).
Procedure: mandatory, step by step instructions.
Guideline: discretionary, recommended best practice.

A frequent exam wrinkle: a "baseline" is sometimes tested as a distinct category, sitting close to a standard but referring specifically to a minimum acceptable level of security for a system type.

Business continuity: the BIA is the anchor

Business continuity planning starts with the business impact analysis, and nearly every exam question on this objective traces back to it in some way. The BIA identifies critical business functions, the impact of their disruption over time, and produces the metrics that everything downstream depends on:

RTO (Recovery Time Objective): how long a function can be down before unacceptable damage occurs.
RPO (Recovery Point Objective): how much data loss, measured in time, is tolerable.
MTD (Maximum Tolerable Downtime): the outer limit before the organisation suffers irrecoverable harm.

External dependencies are an increasingly tested subtopic. A BIA that only considers internal systems misses the point when a critical supplier, cloud provider, or utility outage can halt operations just as effectively as an internal server failure. Mapping and testing third-party dependency resilience is now treated as core BC practice rather than an afterthought.

Personnel security: the human lifecycle

This objective runs the full employment lifecycle:

Candidate screening and hiring: background checks, reference verification, proportionate to the sensitivity of the role.
Employment agreements: NDAs, acceptable use agreements, and policy acknowledgement as a condition of employment.
Onboarding, transfers, terminations: access provisioning on hire, re-provisioning on transfer (a frequently overlooked source of privilege creep), and immediate deprovisioning on termination.
Third parties: vendors, consultants and contractors need contractual security requirements, not just internal policy assumptions. A contractor's laptop is still a risk to your network even though your HR department has no relationship with the person using it.

Termination procedures come up often because they intersect with several other domains: access revocation timing, exit interviews, and the handling of an involuntary termination where the individual may pose a heightened insider threat risk.

Risk management: the engine room of the domain

This is arguably the densest objective in Domain 1, so it rewards a structured mental model.

Threat and vulnerability identification comes first: a threat is a potential cause of harm, a vulnerability is a weakness that could be exploited. Risk exists at the intersection of the two, combined with impact.

Risk analysis and assessment splits into qualitative (subjective ratings, fast, good for prioritisation) and quantitative (numerical, uses formulas like Single Loss Expectancy × Annualised Rate of Occurrence = Annualised Loss Expectancy). Know the SLE/ARO/ALE calculation cold. It appears reliably.

Risk response options are usually tested as a set of four:

Avoid: eliminate the activity causing the risk.
Mitigate: reduce likelihood or impact through controls.
Transfer: shift the risk, commonly through cybersecurity insurance.
Accept: acknowledge the risk and proceed, usually when cost of treatment exceeds potential loss.

Control types get tested by function: preventive (stops an incident before it happens), detective (identifies one in progress or after the fact), corrective (restores normal operation), deterrent, and compensating. A scenario describing a CCTV camera is detective. A firewall rule blocking traffic is preventive. Restoring from backup after ransomware is corrective.

Control assessments verify that controls are operating as designed, distinct from an audit, which verifies compliance against a standard. Continuous monitoring feeds this process in near real time rather than relying solely on periodic point-in-time reviews.

Reporting distinguishes internal reporting (to management, for decision making) from external reporting (to regulators, customers, or the public, often legally mandated within specific timeframes after a breach).

Continuous improvement and risk maturity modelling ask whether an organisation is getting better at managing risk over time, often benchmarked against models like CMMI adapted for risk practice.

Risk frameworks overlap with the governance frameworks above, but here they're applied specifically to risk process: ISO 31000 for general risk management principles, NIST RMF (SP 800-37) for the federal risk management lifecycle, and COBIT and SABSA reappearing with a risk lens rather than a pure governance one.

Threat modelling

STRIDE remains the most commonly referenced methodology on the exam: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Also worth knowing by name: PASTA (Process for Attack Simulation and Threat Analysis), which takes a more risk centric, business aligned approach, and attack trees, which model the paths an attacker could take to achieve an objective.

The exam tends to test whether you understand threat modelling as something done early, ideally at design stage, rather than bolted on after a system is built.

Supply chain risk management

SCRM has become one of the more heavily emphasised additions to recent exam versions, reflecting genuine industry concern about compromised hardware and software reaching organisations through their vendors.

Risks include product tampering during manufacture or shipping, counterfeit components, and hidden implants in hardware or firmware. The mitigations worth knowing by name reflect how technical this area has become:

Third-party assessment and monitoring: ongoing vendor security reviews, not a one-off checkbox at contract signing.
Minimum security requirements and service level requirements: contractually binding baselines suppliers must meet.
Silicon root of trust: a hardware-based anchor for a chain of trust, verifying firmware integrity from first boot.
Physically unclonable function (PUF): a hardware security mechanism that exploits natural manufacturing variation to create a unique, unclonable identifier for a device.
Software bill of materials (SBOM): an inventory of every component and dependency inside a piece of software, increasingly mandated for critical infrastructure and government procurement, and central to responding quickly when a vulnerability like Log4Shell surfaces in a dependency you didn't know you had.

Security awareness, education and training

The final objective distinguishes three related but distinct concepts: awareness (building general recognition of risk, aimed at everyone), training (building specific skills, often role based), and education (building deeper understanding, typically for security professionals themselves).

Methods worth knowing include simulated phishing campaigns, social engineering exercises, security champions programmes embedded within business units, and gamification to sustain engagement over time. Periodic content review matters because static annual training loses relevance quickly against emerging technology and threat trends, cryptocurrency scams, AI-enabled social engineering, and blockchain-related fraud among them.

Programme effectiveness evaluation closes the loop. Metrics might include phishing simulation click rates over time, incident reporting rates, or knowledge assessment scores. The exam wants you to understand that a training programme without a measurement mechanism is difficult to justify to a board asking for return on investment.

Where AI now sits in Domain 1

ISC2 hasn't given AI its own domain. Instead it has threaded AI-specific tasks through all eight, and Domain 1 is where the governance side of that thread lives. Risk leaders are now expected to fold machine learning models and large language models into existing risk frameworks rather than treating them as a separate category of technology sitting outside normal governance. That means setting governance for AI ethics, watching for algorithmic bias, and checking that automated decisions still align with legal, regulatory and privacy obligations, the same obligations covered earlier in this domain's legal and compliance objective.

The supply chain angle matters just as much here. Organisations increasingly buy AI capability rather than build it, which means the SCRM concepts covered earlier extend naturally to AI vendors: how transparent is a provider about where its training data came from, and how resilient is a provider-managed model against the kind of manipulation or drift that could undermine decisions built on top of it without anyone noticing straight away. Treat this as an extension of existing supply chain risk thinking rather than a new discipline to learn from scratch.

Final thought for revision

Domain 1 rewards structural thinking over rote memorisation. The exam rarely asks you to recite a definition in isolation. It presents a scenario and expects you to reason from the underlying principle: which pillar was affected, which control type applies, which risk response is proportionate, which investigation standard governs the outcome. Build your revision around those decision points rather than flashcards of terms, and the rest of the domain tends to fall into place.