Security & Risk Management

This domain exists to protect five properties of information and systems: confidentiality, integrity, and availability (the CIA triad) plus authenticity and nonrepudiation. Each is a property to preserve, not a product to buy, so a control earns its place only by strengthening one or more of them for a defined asset. FIPS 199 rates confidentiality, integrity, and availability independently as LOW/MODERATE/HIGH and takes the highest as the system's overall impact (the high-water-mark rule), and that categorization is what later drives both the strength of the control baseline and recovery priority in a Business Impact Analysis. When a stem asks for the FIRST step to protect an asset, the manager-altitude answer is to determine the asset's value and dominant pillar before choosing any technology: name the threatened pillar, then reach for the control whose primary effect is that property.

Governance, threat modeling, business continuity, and compliance are not parallel topics: they are all the risk process seen from different angles. Risk is the likelihood that a threat exploits a vulnerability multiplied by the resulting impact, and after analysis (quantitative ALE = SLE × ARO, or qualitative likelihood-impact bands) every risk gets exactly one response: avoid, transfer, mitigate, or accept. Threat modeling is that same risk assessment moved early, onto a design diagram before code exists; a Business Impact Analysis is risk assessment focused on availability, producing the recovery-time requirements (MTD, RTO, RPO) the rest of continuity must satisfy. A safeguard is justified only when its cost is below the reduction in Annualized Loss Expectancy it produces, so 'most secure' is never automatically 'correct': cost-justified-against-the-risk is.

One rule unifies governance, personnel security, risk, and supply chain: you can hand down the responsibility to perform work, but never the accountability for the outcome. The board and senior management are ultimately accountable for the security program; a data owner stays accountable for classification even when an IT custodian implements the controls; residual risk that remains after a chosen response must be formally accepted by senior management, not by the analyst or IT operations. The same rule survives outsourcing: you can transfer the work and operational responsibility to a third party, but the accountability for the inherited risk remains yours, which is exactly why supply-chain risk is managed through contracts and oversight rather than trust. Most CISSP 'who is responsible/accountable' stems resolve to naming the right role in this chain.

A mature program is not ad hoc: it picks a control framework by the obligation it must meet (PCI DSS for cardholder data, NIST RMF/SP 800-53 for a U.S. federal ATO, ISO/IEC 27001 for a certifiable ISMS, COBIT for end-to-end IT governance), and it expresses management intent through a derivation chain: policy states what and why, standards and baselines turn that into specific mandatory requirements, and procedures give the exact steps, with discretionary guidelines advising alongside. NIST CSF 2.0 ties this together as a voluntary, outcome-based way to communicate and organize risk rather than a control catalog. Beneath all of it sits the ISC2 Code of Professional Ethics, binding as a condition of certification: its four Canons apply in priority order, so protecting society (Canon 1) outranks loyalty to an employer (Canon 3), and no company policy can authorize an act that breaches a Canon.

Most real losses arrive through one of three vectors this domain covers, and routing a scenario to the correct subtopic is half the exam skill. Trusting a person means personnel security: designate the position's risk, screen to it, sign access agreements, then grant least privilege, and on exit, disable access promptly (before notice for a for-cause termination). Surviving a disruption means business continuity: run the BIA first to set recovery requirements before debating hot sites or backup tooling. Trusting a supplier means supply-chain risk: you inherit your suppliers' risk the moment you deploy what you bought, so perimeter defenses cannot see it, you reduce it at acquisition (vendor assessment, contractual minimum requirements, SBOMs, hardware roots of trust) and through continuous monitoring. The recurring trap is altitude confusion: a contractor's individual access is personnel security, but whether the supplier organization is trustworthy is supply-chain risk.