Security and Risk Management

1.1 The CIA triad, authenticity and nonrepudiation

The CIA triad is the foundational mental model of information security. Confidentiality ensures information is disclosed only to authorized parties with a need to know: a customer-data leak violates confidentiality. Integrity ensures information stays complete and accurate, free from unauthorized modification: if an attacker alters an amount in a banking database, integrity is affected, even though the data remains readable by all. Availability ensures information is accessible when and where it is needed: ransomware that encrypts files attacks availability.

ISC2 expanded this model to five pillars by adding authenticity and nonrepudiation. Authenticity ensures information is genuine: it comes from a trusted, verifiable source, and its originator had the authority to act (whaling attacks specifically exploit a lack of authenticity). Nonrepudiation prevents an actor from later denying an action they performed: a digital signature on a medical order or a trading contract guarantees the originator cannot say "it wasn't me."

Classic trap: confidentiality concerns disclosure (who can read), integrity concerns modification (who can write). A single incident may touch several attributes, but the exam expects you to identify the primary attribute at stake.

1.2 The IAAAA lifecycle and its distinction from AAA

Every access to a resource follows a logical sequence summarized by the acronym IAAAA: Identification, Authentication, Authorization, Accountability, Auditing. Identification is the claim of an identity: the user states "I am alice" (a username, a card identifier). Authentication proves that claim: alice provides a password, a token, or a biometric. Until authentication succeeds, no identity is validated.

Authorization then determines what the authenticated identity is allowed to do: which objects it can read, write, or execute, following the principle of least privilege. Accountability ties each action to the responsible identity: it is the ability to attribute an action to an individual, an essential condition for nonrepudiation. Auditing reviews logs after the fact to verify, detect anomalies, and provide evidence.

The access-control AAA model (triple-A) groups Authentication, Authorization, and Accounting (often equated with accountability). IAAAA is thus a more complete view that explicitly adds Identification upstream and Auditing downstream. Exam trap: do not confuse Identification (claiming who you are) with Authentication (proving it); and remember that accountability depends on a unique, reliable identification, otherwise an action cannot be attributed.

1.3 The risk triad: asset, vulnerability, threat, and risk

Risk does not exist in a vacuum: it arises from the meeting of three elements called the risk triad. An asset is a valuable resource to protect (data, system, personnel, reputation); its value or criticality dictates the safeguards you deploy. A vulnerability is an exploitable weakness (an unpatched system, a datacenter without backup power, a non-earthquake-resistant building). A threat is a potentially harmful event (earthquake, outage, malware, malicious employee).

Two intermediate actors sharpen the picture. The threat agent (or threat actor) is the entity that triggers the threat: a cybercriminal, a natural disaster, an insider. The exploit is the concrete means by which a vulnerability is used to realize the threat. Risk is the probability that a threat exploits a vulnerability against an asset, multiplied by the resulting impact.

The conceptual formula Risk = Threat × Vulnerability × Asset captures the essence: if any factor equals zero, risk is zero. A Linux system has no vulnerability to Conficker, so it carries no risk from that worm, even though the threat exists elsewhere. Exam trap: a threat with no matching vulnerability creates no risk, and a worthless asset deserves no safeguard. Clearly distinguish threat (the event) from threat agent (who carries it) and vulnerability (the weakness).

1.4 Defense in depth and the three control types

Defense in depth rests on a simple principle: no single control is infallible, so you stack several independent protection layers. If an attacker breaches one layer, the next stops them or at least slows them and makes them detectable. This is also called layered security. An example: a firewall (technical), complemented by an access policy (administrative) and a badge at the datacenter entrance (physical).

CISSP classifies controls into three broad categories by their nature. Administrative (or managerial) controls are policies, procedures, training, employment contracts, separation of duties: they shape human behavior. Technical (or logical) controls are implemented in systems: encryption, firewalls, ACLs, authentication, logging. Physical controls protect the material environment: fences, lighting, locks, guards, fire-suppression systems.

These categories by nature combine with control functions (preventive, detective, corrective, etc.), covered in a later module. Exam trap: a surveillance camera is a physical control by nature but detective by function; encryption is technical and preventive. The exam often tests your ability to classify a single control along two different axes. Defense in depth precisely requires mixing the three natures so as not to depend on a single barrier.

1.5 Due care vs due diligence and negligence

Due care and due diligence are two governance and legal-liability concepts that are often confused. The most useful mnemonic: due diligence is knowing what is right, due care is doing the right thing. In other words, due diligence means investigating, assessing, planning, and understanding risks; due care means acting prudently and continuously to address them.

Concretely, conducting a risk analysis, auditing a vendor, or studying regulatory obligations is due diligence. Applying patches, enforcing the security policy, training employees, and continuous monitoring is due care. Due diligence precedes and feeds due care: you cannot act properly on risks you have not first identified.

The link to negligence is central for the exam. An organization that shows neither due care nor due diligence exposes itself to negligence lawsuits: it did not act as a prudent person would have under the same circumstances. The prudent man rule (or prudent person rule) is the comparison standard. Exam trap: if the question is about investigating, assessing, or understanding, think due diligence; if it is about acting, maintaining, or enforcing over time, think due care. Together they protect executives from accusations of negligence.

1.6 Privacy and safety: the attributes beyond the five pillars

The ISC2 manual objectives (1.2) list seven attributes to explain: confidentiality, integrity, availability, authenticity, nonrepudiation, but also privacy and safety. The last two are often forgotten even though they are testable. Privacy is not a synonym for confidentiality: confidentiality protects information against unauthorized disclosure, whereas privacy protects an individual's right (the data subject) to control the collection and use of data about them. You can keep data confidential while still violating privacy, for example by processing it for an unconsented purpose. Privacy relies on frameworks such as the eight OECD principles (collection limitation, data quality, purpose specification, use limitation, security safeguards, openness, individual participation, accountability) and the GDPR, which governs any data about a person in the EU/EEA.

Safety concerns preventing or controlling unwanted or unauthorized harm to persons or property: it belongs to the physical world. Safety of information relates to ensuring that the use of information does not endanger people. The manual's example: leaking a list of employees with their home addresses while they are all at the annual corporate retreat compromises the safety of those employees and their families, beyond a mere confidentiality breach.

Exam trap: do not confuse privacy (the individual's right over their data) with confidentiality (non-disclosure), nor safety (protection of persons/property, physical world) with security (protection of the asset). PII (personally identifiable information) is the data whose protection underpins the data subject's right to privacy.

1.7 The value of information and the status of security models

The ISC2 manual opens section 1.2 with a structuring idea often overlooked: information has value because it is used to make decisions, which lead to actions, which produce results. Information security is the science and practice of ensuring information is correct, complete, and available to support those decisions, that it is produced in reliable and repeatable ways, and that what must stay secret stays secret. Insecure information can lead to actions causing property damage, injury, or even death. This framing justifies why an information asset is protected: it is not the data in itself that matters, but the decision-making use it enables.

A second nuance is essential for the exam: the CIA triad and the five pillars are not the source of security requirements; they are memory-joggers meant to keep these concerns at the forefront of designers' and analysts' thinking. You therefore do not derive a list of controls directly from the triad; you use it as a questioning grid.

Exam trap: if a question implies the CIA model is itself a regulatory requirement or a controls standard, that is wrong. The model is a conceptual framework; requirements come from risks, laws, and business obligations. The triad's popularity stems from its simplicity, and extended models (five pillars, Parkerian) address better-funded, more motivated threats.

2.1 The (ISC)² Code of Ethics: preamble and 4 canons

The (ISC)² Code of Ethics opens with a preamble setting the guiding principle: the safety and welfare of society, the common good, the duty to our principals, and the duty to each other require that we adhere - and be seen to adhere - to the highest ethical standards. The preamble concludes that strict adherence to the Code is a condition of certification.

Next come the 4 canons, in this exact order: (1) Protect society, the common good, necessary public trust and confidence, and the infrastructure; (2) Act honorably, honestly, justly, responsibly, and legally; (3) Provide diligent and competent service to principals; (4) Advance and protect the profession.

The order is PRESCRIPTIVE: it acts as a tie-breaker. When two canons conflict, the higher-ranked canon prevails over the lower-ranked one. Thus protecting society (canon 1) outweighs the duty to one's employer (canon 3); and acting legally (canon 2) prevails over the commercial interest of the profession (canon 4). It is this hierarchical reasoning - not mere recitation - that the exam tests.

Classic trap: scrambling the order, for example placing "advance and protect the profession" before "protect society." The welfare of society is ALWAYS first; the profession comes last.

2.2 RFC 1087 (IAB) and other professional codes

RFC 1087 "Ethics and the Internet" is published by the Internet Architecture Board (IAB). It does not describe positive canons like ISC2; instead it explicitly declares UNETHICAL six categories of activity: (1) seeking unauthorized access to Internet resources; (2) destroying the integrity of information; (3) disrupting normal Internet use; (4) wasting resources (people, capacity, etc.) through such actions; (5) compromising the privacy of users; (6) practicing negligence in the conduct of Internet experiments.

The logic of RFC 1087 maps onto the CIA triad: unauthorized access and privacy compromise touch confidentiality, destroying integrity touches integrity, and disruption and waste touch availability. This is a handy exam angle for memorizing the list.

Other organizations maintain their own codes: IEEE and ACM (computing and software engineering), ISACA (IS audit and governance). They share the spirit - integrity, competence, primacy of the public interest - but differ in scope and authority. Key point: only the (ISC)² Code of Ethics conditions the CISSP certification. RFC 1087 and the IEEE/ACM/ISACA codes are complementary references, not the disciplinary basis of ISC2.

Classic trap: attributing the list of unethical activities to the (ISC)² Code of Ethics. That list comes from RFC 1087 / the IAB, not to be confused with the 4 canons.

2.3 Promoting ethics in practice: reporting and consequences

Promoting ethics (the verb "promote" in Key Area A) goes beyond personal adherence: the professional must also report violations and defuse conflicts of interest. A conflict of interest arises when a personal interest - family ties, financial gain, animosity - may compromise objectivity. The expected response is disclosure and recusal, not concealment.

Reporting follows a formal process. At ISC2, a complaint triggers a procedure: a finding of facts, an opportunity for the accused member to offer a rebuttal, then review by the ISC2 Ethics Committee. The committee lets the member review the findings and recommendations before submitting them to the ISC2 board, which rules.

The ultimate consequence of a breach is revocation of the certification: it is the ISC2 board, on the recommendation of the ethics committee, that decides whether to revoke membership. Beyond that, unethical conduct destroys the organization's trust, which can no longer accept the professional's security advice.

Classic trap: believing the manager or employer "revokes" the CISSP. Revocation of the certification belongs to ISC2 (ethics committee + board), not the employer. The employer may terminate employment; only ISC2 withdraws the certification.

2.4 The organizational code of ethics and the Enron / SOX illustration

Beyond the (ISC)² Code of Ethics, you must distinguish the organizational code of ethics: a policy document approved and supported by the organization's senior management. Where the (ISC)² Code binds the certified individual, the organizational code binds all personnel and sets the acceptable modes of behavior. It is often merged with the overall personnel policies and may state the organization's mission and core values.

An organizational code concretely defines what is forbidden: discriminatory and unproductive behavior (racial, religious, or sexual harassment), unfair trade practices such as nepotism, bribery, and awarding contracts in exchange for favors. Some codes are also designed to ensure compliance with legislation the organization is subject to (compliance-driven).

Application point: ethics, like everything else, must be embedded in policies and procedures, and the ethics committee must continually review and monitor them. The security professional sets the example: their conduct becomes the reference practice (tone at the top).

History illustrates the stakes. In the late 1990s / early 2000s, a series of accounting scandals - WorldCom, Adelphia, Enron - led to bankruptcies. Enron's auditing firm, Arthur Andersen, provided both audit AND business consulting: an inherent conflict of interest (the roles are adversarial). Andersen then ordered the destruction of documents during a regulatory investigation. In response, the U.S. Congress created the Sarbanes-Oxley Act (SOX) - requiring greater transparency in the financial reporting of publicly traded companies - and amended the Federal Rules of Evidence: a data owner can no longer destroy information once notice of a legal action or investigation is received.

Classic trap: confusing the organizational code of ethics (internal, approved by management, enforced by the employer) with the (ISC)² Code (which conditions certification, enforced by ISC2). And: Andersen showed that having a data-destruction policy does not make destruction ethical during an investigation - which is exactly what SOX corrected.

3.1 Aligning security with the business

Security governance is the meta-process that links the organization's efficiencies to its goals and objectives: it governs how policies are written, how people are trained and how actions are performed. Founding rule: the business can exist without the security department, but the security department has no reason to exist without the business. Security must therefore enhance and support business goals, never needlessly hinder them.

Three levels not to confuse. Governance = the WHAT: the board / directors / top management set direction, risk appetite and policies; they are accountable. Management = the HOW: managers translate this into programs, allocate resources and remain responsible for execution. Operations = the DOING: teams apply controls day to day. The risk appetite (the level of risk the organization accepts) is set by top management, not by operations.

Example: a board sets "zero tolerance for patient data leakage" (governance); the CISO designs an encryption and DLP program (management); the SOC team monitors alerts (operations). Exam trap: a risk acceptance decision made by a technical administrator is invalid - accepting residual risk is a senior management responsibility, not an operator's.

3.2 Roles and responsibilities

The Senior Manager (CEO, board) is ultimately accountable for security: they sign the policies and carry the risk before shareholders and the law. The Information Security Officer / CISO is functionally responsible: they design, run and maintain the security program. Key exam distinction: accountable (the single one, at the top, answerable for the outcome) vs responsible (the one who executes, delegable).

Data roles. The Data Owner (often a business executive) classifies the data and defines its sensitivity; they decide who may access it. The Custodian (Data Custodian / steward, often IT) preserves CIA day to day: backups, technical rights, encryption - they apply the owner's decisions, they do not make them. The User / Operator applies the rules and signs the AUP (Acceptable Use Policy). The Auditor independently assesses and measures the gap between policy and reality.

Regulatory vocabulary (GDPR). The Data Controller determines the purposes and means of processing (decides WHY and HOW); the Data Processor processes on the controller's behalf (executes, on instruction). Trap: do not confuse Owner (internal, classifies) with Controller (legal notion, accountable for processing); nor Custodian (internal, technical) with Processor (third party, legal).

3.3 Control frameworks

ISO 27001 states the requirements of an ISMS (Information Security Management System): it is the certifiable standard - an organization is audited and certified for its conformance. ISO 27002 is the catalog of best-practice controls (the detailed "how" of measures); it is NOT certifiable. Classic trap: you certify against ISO 27001, never ISO 27002.

COBIT (ISACA) is an IT governance and management framework, widely used by auditors; it links IT objectives to business objectives. NIST SP 800-53 is an exhaustive catalog of security and privacy controls (for US federal systems): you start from a baseline (Low/Moderate/High per FIPS 199/200), then apply scoping (drop irrelevant controls) and tailoring (adapt the rest to context). ITIL is the set of IT service management best practices (service delivery), mapped to ISO 20000. The CIS Controls (18 of them) are a prioritized, concrete list of defensive controls, free and action-oriented.

Example: to earn an internationally recognized certification, target ISO 27001; to build a US federal program, rely on NIST 800-53; to align IT and governance for auditors, COBIT. Trap: NIST 800-53 is not "certifiable" like ISO 27001 - it is a catalog, not a certification scheme.

3.4 Organizational processes impacting security

Some business decisions deeply alter the security posture. In an acquisition, the buyer inherits the target's legacy systems, policies, procedures and data - often poorly secured - and may suddenly fall under new legislation and regulations. A merger requires aligning the security governance of the resulting entity. A divestiture or spinoff forces an assessment of what must leave, what stays, and how to separate accesses and data without breaking confidentiality.

The major M&A risk: the acquiring organization inherits the target's vulnerabilities. Real case cited by the CBK: Marriott acquired Starwood in 2016; a Starwood reservation system had already been compromised since 2014 - the breach was discovered only after the acquisition, exposing hundreds of millions of customers. Hence the importance of security due diligence BEFORE signing.

Governance of these processes: a governance committee (often mandatory for non-profits) frames decisions; digital transformation and reorganization also introduce risks (orphan accounts, unmigrated data). Exam trap: due diligence must precede integration; integrating first then "auditing later" amounts to importing the target's compromises into your own network.

3.5 Documentation hierarchy

Security documentation is structured in tiers. The Policy is the highest-level document: it expresses intent and direction, is issued and signed by senior management, and stays stable and general (the "why"). It is mandatory.

Beneath the policy: the Standard imposes precise, uniform choices (technologies, configurations) - it is mandatory. The Baseline defines the minimum security level to reach (a configuration floor) - mandatory. The Procedure describes the detailed step-by-step execution of a task - mandatory within its scope. The Guideline, however, is a recommendation: flexible and optional, it advises without compelling (the "if you wish").

Exam memo: Policy > Standard / Baseline > Procedure are mandatory; only the Guideline is optional. Recurring trap: "A standard is a suggestion" is FALSE (it is mandatory); "a guideline is mandatory" is FALSE (it is optional). Another trap: the policy does not contain technical details - those go down into standards and procedures so the policy stays stable over time.

3.6 Due care, due diligence and business alignment

Aligning security with the business means fitting plans and resources to goals and objectives: spending time, material or money on nonessential activities signals poor alignment. The manual stresses that the security practitioner must first understand how the organization functions and its objectives, and only then determine how security fits in to enhance those functions. The BIA (business impact analysis, covered in 1.8) is the recognized form that captures this alignment of goals, resources and risks. Misaligned governance produces policies that needlessly inhibit productivity, impose undue costs and hinder strategic intent.

Two legal and ethical duties shape this effort. Due care = taking all reasonable and prudent actions to plan and carry out a task or responsibility, across its whole life cycle (from conception to disposal). It is putting in place the systems that control or prevent threat events. Due diligence = taking all reasonable and prudent actions to monitor, control, manage and, as needed, redirect the plans and actions you are responsible for; it is staying aware of the environment and new risks. Manual phrasing: "constant vigilance" expresses due diligence; you pay attention to the alarms the systems (due care) generate. Management dictum: "you cannot manage what you do not measure."

Two legal notions refine these duties. Prudent actions = what people of comparable training, experience and authority would do in the same circumstances. Reasonable actions = decisions with a clear, logical and defensible justification after the fact (acting on a hunch is not reasonable). Central exam trap: publishing a policy is NOT sufficient due diligence; to meet the legal duty, the organization must also have a documented and active monitoring and enforcement capability ensuring it adheres to its own policy. Due diligence also includes the security review of vendors/suppliers before using them, and personnel background checks.

3.7 Extended frameworks: RMF, FedRAMP, SABSA and categories

Beyond the ISO 27001/27002-COBIT-NIST 800-53-ITIL-CIS core, the manual details several frameworks worth knowing. ISO 27000 family: 27001 (ISMS requirements, certifiable), 27002 (control catalog, advisory), 27003 (implementation guidance), 27005 (risk management). 27001's first action: read 27002 and justify the inclusion/exclusion of each control - this exercise produces the Statement of Applicability (SoA).

The NIST/FIPS ecosystem cascades. A FIPS is a requirement, a SP (Special Publication) is a guideline that helps meet it. FIPS 199 categorizes the system (Low/Moderate/High per C-I-A); NIST SP 800-60 explains how to perform that categorization; FIPS 200 mandates minimum controls per category; NIST SP 800-53 provides the control catalog satisfying FIPS 200. The NIST RMF (SP 800-37) transforms the old Certification & Accreditation into a six-step process (Categorize, Select, Implement, Assess, Authorize, Monitor); it is mandatory only for US federal but is widely adopted in the private sector and offers NO private certification. FedRAMP applies this logic to the cloud: the JAB (Joint Authorization Board) grants reusable provisional authorizations, and 3PAOs (Third-Party Assessment Organizations) independently verify a CSP's controls.

SABSA (Sherwood Applied Business Security Architecture) is a business-driven, risk- and opportunity-focused security architecture methodology that traceably supports business objectives (advantages: value-assured, prioritized, scalable, agile, open source, auditable). Finally, the manual distinguishes CATEGORIES of frameworks: privacy (PMF, ex-GAPP from AICPA, incorporates GDPR/TSC); risk/ERM (ISO 31000, ISO 27005, COSO ERM, ISACA Risk IT, NIST SP 800-37); cybersecurity (ISO 270XX, HITRUST CSF for HIPAA, CSA STAR for the cloud with its 3 tiers and the CAIQ); and Security Control Frameworks (SCF) that provide minimum implementation practices (PCI DSS, SWIFT CSCF, NIST, COBIT, CIS). Cross-cutting tool: gap analysis compares controls in place to what an SCF requires. Trap: NIST RMF/800-53 and SABSA do not deliver private certification like ISO 27001.

The NIST Cybersecurity Framework (CSF) organizes security around five functions: Identify, Protect, Detect, Respond, Recover. Widely adopted, it serves as a common language to steer and communicate the security posture at executive level.

4.1 Determining Compliance - Laws, Regulations, Contracts, Standards

The first skill is classifying an obligation. A law is enacted by a legislature and binds everyone. A regulation is issued by an agency under the authority of a law and also carries the force of law. A contract is a commitment between parties (e.g., adhering to PCI-DSS to process cards). A standard is a technical or best-practice framework, binding only when imposed by a law or contract.

Landscape of major regimes. SOX (Sarbanes-Oxley): a US law targeting the integrity of financial reporting for publicly traded companies, after the accounting scandals. PCI-DSS: a private standard from the PCI Security Standards Council imposed by contract on anyone who stores, processes, or transmits cardholder data. SOC 1/2/3 (AICPA, under SSAE 18): attestation reports - SOC 1 on internal control over financial reporting (ICFR), SOC 2 on the Trust Services Criteria (security, availability, confidentiality, processing integrity, privacy), SOC 3 a public, lighter version of SOC 2.

HIPAA: a US law protecting health data (PHI). GDPR: an EU regulation, expanded individual rights, breach notification within 72 hours, fines up to 4 percent of annual worldwide turnover. FISMA: a law imposing a security program on US federal agencies and their contractors, aligned with the NIST RMF.

Exam trap: do not confuse the nature of the instruments. PCI-DSS is not a law - its force comes from the contract with the payment networks. A SOC report is not an absolute security certification but an auditor's attestation on controls at a point in time or over a period.

4.2 Legal Systems and Categories of Law

Legal systems differ by country. Common law (Anglo-Saxon) relies on case law and precedent. Civil law (continental) rests on comprehensive written codes. Customary law derives from customs and traditions, and religious law draws its rules from a sacred text. Many countries are hybrids.

Within common law, three categories matter for the exam. Criminal law protects society: the State prosecutes, the burden of proof is 'beyond a reasonable doubt', and the penalty can be imprisonment. Civil law (in the tort sense) resolves disputes between private parties: the standard is 'preponderance of the evidence', and the penalty is financial (damages). Administrative/regulatory law is issued by agencies: it carries the force of law, and its burden of proof is generally low.

Example: an employee embezzles funds. The State may prosecute criminally (prison); the company may also sue civilly to recover the money (damages). Both actions coexist with different proof standards.

Exam trap: the highest burden of proof is criminal (beyond a reasonable doubt). Civil and regulatory only require preponderance of evidence, which is lower. Do not just memorize the names, but the order of severity.

4.3 Cybercrime and Data Breaches

Cybercrime refers to any offense where the computer acts as a tool of the offense (e.g., fraud, phishing) or as a target of the offense (e.g., intrusion, denial of service). This tool/target distinction shapes the legal characterization and the type of investigation.

We must distinguish breach from data disclosure. A breach is the loss of control, confidentiality, or integrity of a system or data. A data disclosure is the actual revelation of data to an unauthorized party. Not every breach leads to a disclosure, but a disclosure almost always reflects a breach. Notification laws (GDPR, US state laws) often require alerting regulators and affected individuals within a deadline.

Landmark laws. In the US, the Computer Fraud and Abuse Act (CFAA) criminalizes unauthorized access, or access exceeding authorization, to a protected system. Many countries have equivalent statutes; the challenge is extraterritoriality, since an attack often crosses several jurisdictions.

Exam trap: a breach is not synonymous with data disclosure. The scenario may describe a compromised system with no proven exfiltration; the right answer speaks of breach (loss of control), not disclosure. Also be careful not to confuse the notification obligation (legal trigger) with mere technical detection.

4.4 Intellectual Property, Import/Export, and Transborder

Four intellectual property regimes must be mastered. A trademark protects a distinctive sign (name, logo, slogan) identifying the origin of a product; renewable indefinitely as long as it is used. A patent protects a new, useful, and non-obvious invention; typical 20-year term in exchange for public disclosure. A copyright protects the expression of a work (code, text, image), not the idea; generally the life of the author plus 70 years. A trade secret protects confidential information with economic value (formula, algorithm); unlimited duration as long as the secret is maintained, but no protection if it leaks.

Infringement is unauthorized use: using a protected mark, making a patented product, copying a work, or misappropriating a secret. DRM (Digital Rights Management) adds technical controls to enforce licenses (e.g., a lock preventing copying).

Import/export controls restrict the movement of sensitive goods. The Wassenaar Arrangement coordinates control of dual-use goods (civilian/military), including certain encryption technologies. Transborder data flow refers to the transfer of data across borders; it is governed by regimes such as GDPR, which restrict transfers to countries without adequate protection.

Exam trap: to protect a secret algorithm, a trade secret can outperform a patent. A patent requires public disclosure and expires after 20 years; a trade secret stays protected indefinitely as long as it is not revealed. The choice depends on the reverse-engineering risk and the duration of the advantage sought.

4.5 Privacy and OECD Principles

Privacy concerns the protection of PII (Personally Identifiable Information), any data that can identify a person. The organization that collects PII assumes obligations: minimize collection, secure, inform, and enable individuals to exercise their rights.

The eight OECD principles (1980, revised) form the most-cited international foundation. 1) Collection Limitation: collect lawfully and fairly, ideally with consent. 2) Data Quality: relevant, accurate, up-to-date data. 3) Purpose Specification: purpose stated before collection. 4) Use Limitation: do not use beyond the stated purpose without consent or legal basis. 5) Security Safeguards: protect with reasonable measures. 6) Openness: transparency about practices. 7) Individual Participation: the person can access, challenge, and correct their data. 8) Accountability: the data controller answers for compliance with all these principles.

Key point: the data controller remains accountable, even when it outsources processing to a data processor. Outsourcing an activity does not outsource legal responsibility.

Exam trap: the question often contrasts data controller and data processor. The processor acts on behalf of the controller, but ultimate accountability - and thus the penalty - targets the controller. Do not pick the processor as responsible for compliance with the OECD principles or GDPR.

4.6 Investigation Types, Forensics, and Chain of Custody

Four investigation types differ by their actors, burden of proof, and purpose. The administrative investigation is internal to the organization, aims to inform a management decision (HR, internal compliance), and has a low burden of proof. The criminal investigation is conducted with law enforcement, seeks a criminal conviction, and requires the highest burden of proof (beyond a reasonable doubt). The civil investigation supports a dispute between private parties and rests on preponderance of evidence. The regulatory investigation is conducted by a regulator to verify compliance with a regulation, with a generally low burden of proof.

The choice of type drives collection rigor. An investigation that may become criminal must, from the outset, follow the strictest forensic standards, because rigor cannot be reconstructed afterward. Reference standards: ISO/IEC 27037 (identification, collection, acquisition, preservation of digital evidence), ISO/IEC 27043 (investigation process principles), and NIST SP 800-86 (integrating forensics into incident response).

Evidence admissibility depends on its relevance, reliability, and lawful acquisition. The chain of custody documents who handled each item, when, where, and why, from collection to court. A broken chain of custody can make evidence inadmissible, even if it is technically valid.

Exam trap: after an incident, if a criminal investigation begins, immediately treat the scene to the highest standards. The classic trap suggests 'start internally then see' - but sloppy collection destroys evidentiary value. When criminal proceedings are plausible, align with their requirements.

4.7 Software Licensing and Import/Export Controls (ITAR, EAR, Wassenaar)

Software is a form of intellectual property: the buyer acquires not a copy but a right to use, framed by a license. The CISSP must recognize four main models. A contractual (negotiated) license is a signed written agreement between the parties, with tailored clauses (scope, duration, number of seats); it is the legally strongest form. A shrink-wrap license takes its name from the plastic packaging: acceptance of the terms is deemed given upon opening the package, with no signature. A click-through (also click-wrap) license asks the user to click 'I agree' before installing or using the software; consent is the act of clicking. Finally, the EULA (End-User License Agreement), notably for cloud services, defines use limitations: who may use it, how, for how long, and whether derivative work is allowed and protected.

The exam point is that a EULA charges for the right to use, not ownership of the copy. Clearly defining use limitations (who, how, how long) is essential; in some EU countries, the license agreement must be registered with a national intellectual property office. DRM adds technical controls (locks, geolocation, 'phone home') to enforce the license, which raises fair use debates.

Import/export controls restrict the movement of sensitive technologies, especially cryptography. Beyond the Wassenaar Arrangement (already covered: 42 countries, dual-use goods and encryption), two US regimes are essential. ITAR (International Traffic in Arms Regulations), administered by the Department of State, governs strictly military articles and services listed on the US Munitions List. EAR (Export Administration Regulations), administered by the Department of Commerce (BIS), covers commercial and dual-use goods, including much encryption, via the Commerce Control List. The Militarily Critical Technologies List (MCTL) further details technologies requiring specific export permission.

Exam trap: do not reduce import/export to Wassenaar alone. Distinguish ITAR (pure military, Department of State) from EAR (commercial and dual-use, Department of Commerce). Countries such as Russia, China, and North Korea additionally impose strong restrictions on citizens' use of cryptography, which can make merely bringing an encrypting device while traveling illegal.

4.8 Privacy Law Landscape (US and International)

US privacy is described as sectoral: there is no single federal law, but a patchwork of sector-specific statutes, supplemented by state laws and overseen for general commerce by the FTC (Federal Trade Commission). Three federal statutes recur on the exam. HIPAA protects health data (PHI). GLBA (Gramm-Leach-Bliley Act) protects the financial data of financial-institution customers. COPPA (Children's Online Privacy Protection Act) protects the online data of children under 13. At the state level, the CCPA (California Consumer Privacy Act, 2018) is the strongest US protection, yet was not ruled adequate under GDPR; CalOPPA already required publishing a privacy policy.

Two statutes govern surveillance. ECPA (Electronic Communications Privacy Act) protects electronic communications against interception. The Fourth Amendment protects against unreasonable searches and seizures, but only against the government: it does not constrain what a private organization does with its own data, and that organization may voluntarily hand information to the State on simple request. The USA PATRIOT Act (2001) extended search-and-seizure powers, authorizing national security letters served without a judge or subpoena, and often bars disclosing to the data subject that such a letter was received.

Internationally, transfers out of the EU depend on GDPR adequacy decisions (Japan, New Zealand, Argentina, Canada are approved; the US is not). Successive US arrangements - Safe Harbor then Privacy Shield - were struck down by the CJEU (Schrems II, 2020) for failing to offer sufficient protection against US surveillance. What remains are Standard Contractual Clauses (SCCs, smaller companies) and Binding Corporate Rules (BCRs, large groups, approved by a supervisory authority), both weakened by Schrems II. The EU Digital Markets Act targets 'gatekeepers' (Amazon, Apple, Meta, Microsoft) with fines up to 10 percent of worldwide turnover (20 percent for repeat infringement).

Many countries have GDPR-like laws: Brazil (LGPD), Argentina, Chile (privacy declared a constitutional right), Colombia, Australia (Notifiable Data Breaches: breach to be reported within 30 days above AU 3M turnover), South Africa (POPIA). Data localization requires storing certain data within national territory: Russia requires that any data about a Russian citizen physically reside on servers in Russia, forcing local data centers. APEC's Cross-Border Privacy Rules (CBPR) and the right to be forgotten (right to erasure, GDPR) round out this shifting landscape.

Exam trap: do not confuse the sectoral US regimes (HIPAA = health, GLBA = finance, COPPA = children) and never claim the US has a general federal law equivalent to GDPR. Know that Safe Harbor and Privacy Shield were struck down (Schrems), that the US has no adequacy decision, and that the data controller remains accountable for international transfers.

In Canada, the baseline law is PIPEDA (2000). In the EU, privacy of electronic communications also falls under the ePrivacy Directive (2002/58/EC), which predates and complements GDPR.

5.1 Risk fundamentals and terminology

Risk rests on a triad: asset, threat, vulnerability. An asset is anything of value to the organization (data, systems, people, reputation), and its value (asset value, AV) dictates the reasonable level of protection. A threat is a potentially harmful event - natural (earthquake, flood), technical (power outage, malware) or human (disgruntled employee). A vulnerability is a weakness that lets a threat cause harm (datacenter with no UPS, unpatched OS). Remember the exclusion principle: a Linux system has no vulnerability to the Conficker worm, hence no associated risk - no vulnerability, no risk.

The conceptual formula for inherent risk is: Threat x Vulnerability x Asset value. This is the raw risk, BEFORE any control. No control fully eliminates risk: a control gap always remains (the portion the control does not cover). Residual risk is therefore: (Threat x Vulnerability x Asset value) x control gap, that is, what remains AFTER controls are applied. Classic trap: do not confuse residual risk with risk acceptance. Residual risk is a quantity; acceptance is a decision (the organization chooses to do nothing more).

The exposure factor (EF) is the fraction of an asset's value destroyed by a single occurrence of a risk event: an asset totally destroyed has an EF of 1.0, a triply redundant system that loses one node has an EF of about 1/3. On the tolerance side, distinguish risk appetite (the level of risk the organization is willing to pursue to meet its objectives) from risk tolerance (the acceptable variance around that level for a given risk). Acceptable risk is the minimum risk the organization is willing to carry. All these identified, assessed and treated risks are recorded in the risk register, the central log that tracks each risk, its owner, its treatment and its status.

5.2 The NIST SP 800-30 risk analysis process

NIST SP 800-30, Risk Management Guide for Information Technology Systems, describes a risk analysis process structured in six steps. Following it ensures the analysis is repeatable and defensible before management.

Step 1 - System Characterization: bound the scope of the effort and describe the systems analyzed (data, interfaces, boundaries). Step 2 - Threat Identification: enumerate the relevant threat sources. Step 3 - Vulnerability Identification: enumerate the exploitable weaknesses. These two steps feed the formula Risk = Threat x Vulnerability x Asset.

Step 4, in three parts: 4a Control Analysis (analyze the controls/safeguards already in place or planned to reduce risk), then 4b Likelihood Determination and Impact Analysis (cross probability with impact to surface the critical risks: high probability x high impact). Step 5 - Countermeasure Recommendations: recommend controls based on cost criteria (purchase, design, implementation, environment modifications, compatibility with other countermeasures, repair/replace, operating support, effect on productivity). Step 6 - Document results: report the findings to senior management and sponsors. Trap: the analyst recommends (step 5), but the treatment decision and the final documentation belong to management (step 6) - the analyst does not decide alone.

5.3 Qualitative analysis and the Probability x Impact matrix

Qualitative analysis is scenario-based: for each major threat to an asset, the team builds a What if? scenario and assesses the exposure and the loss potential if the threat were realized. It assigns no dollar amounts; it produces a relative ranking from subjective scales. That is its strength (fast, low data, easy to communicate) and its weakness (subjectivity).

The central tool is the Probability x Impact matrix. A typical probability scale runs Frequent (A) -> Probable (B) -> Occasional (C) -> Remote (D) -> Improbable (E). A typical impact scale runs Negligible (1) -> Marginal (2) -> Important/Critical (3-4) -> Catastrophic (5). The crossing rates each scenario as Low / Medium / High / Very High risk. Example: a Frequent x Catastrophic scenario lands in Very High risk and demands immediate action; an Improbable x Negligible scenario lands in Low risk and can often be accepted.

Major exam trap: never add or average qualitative ratings. A 1-10 scale misleads the user into thinking a risk rated 8 is four times as severe as one rated 2, which is false - these are ordinals, not arithmetic magnitudes. To do arithmetic (compare an expected loss to a control cost), you must switch to quantitative.

5.4 Quantitative analysis: SLE, ALE, ARO

Quantitative analysis assigns real monetary values, which lets you do arithmetic and directly compare an expected loss to a safeguard cost - the language management understands. Three key quantities chain together.

The single loss expectancy (SLE) is the expected loss from ONE occurrence: SLE = AV x EF, where AV is the asset value and EF the exposure factor (fraction <1 destroyed by the event). The annual rate of occurrence (ARO) is the number of times per year the event is expected. The annual loss expectancy (ALE) is the expected loss over one year: ALE = SLE x ARO.

Worked example. A vehicle is worth AV = $5,000. In a collision, expected damage is EF = 20% (0.2). This kind of collision occurs once every 4 years, so ARO = 0.25. Compute: SLE = 5,000 x 0.2 = $1,000; ALE = SLE x ARO = 1,000 x 0.25 = $250. Decision: the rule is to compare the ALE to the annual cost of the safeguard. If insurance costs $200/year (< the $250 ALE), transferring is rational; if it costs $400/year (> ALE), paying the safeguard would spend more than the expected loss - better to accept or find cheaper. Golden rule: never spend more to treat a risk than the cost of the risk itself. Trap: EF is a fraction, ARO can be < 1 (rarer than annual), and ARO is NOT the SLE.

5.5 Risk treatment: Avoid, Transfer, Mitigate, Accept

Once a risk is prioritized, the organization picks a treatment among four options (mnemonic MART: Mitigate, Avoid, Reduce/Transfer, Transfer). Risk avoidance: cease the exposed activity (close a store in a high-crime area, relocate a plant out of a hurricane zone). Used when the potential impact is too high to be offset by the rewards. Risk mitigation (reduce, renamed Modify by ISO 27005): take remediation measures or deploy controls (technical, physical, administrative) to reduce likelihood or impact. Whatever you do, residual risk always remains.

Risk transference (renamed Sharing by ISO 27005): pay a third party to absorb the financial impact - typically insurance, whose premium depends on likelihood/impact, controls in place and claims history. Crucial point: transfer shifts the financial impact, it does NOT eliminate the risk. The organization remains operationally exposed and keeps its legal and reputational liability; the insurer pays a fraction, not the whole, and often requires evidence of a reasonable security program. Risk acceptance: run the activity with no further action, because the impact or likelihood is negligible, or the benefit outweighs the risk. Note: acceptance means the organization does nothing more - not to be confused with residual risk.

Decision and sign-off: prioritizing and choosing the treatment are business decisions owned by senior management (the risk owner). The security professional advises, but it is the risk owner who formally signs off on accepting a risk. Recurring trap: if a question asks who accepts the risk, the answer is the business/senior management, never the analyst or the CISO alone.

5.6 Control types and categories on the incident timeline

Two orthogonal axes classify controls. First the control TYPE - how it is implemented: administrative (policies, separation of duties, job rotation), technical/logical (firewalls, IDS, ACLs, biometrics), physical (fence, lighting, fire suppression). Then the control CATEGORY - what function it serves, split into seven categories placed on an incident timeline.

Before the incident (planning and defense): Directive (guides expected behavior - policy, Authorized personnel only signs), Deterrent (discourages the attacker - electric fence, warning banner), Preventive (stops the event - change control, password login, 8-ft fence), Compensating (alternative control when the intended one does not meet the requirement - layered defense in depth). During/after detection: Detective (signals an event happened - motion detector, antivirus, supervision). After the incident: Corrective (corrects - an IDS dynamically altering a router ACL, reboot, fire extinguisher), Recovery (restores to normal - backup restoration, redundant server).

Central exam trap: NEVER confuse type and category. A firewall is technical type and preventive category; a policy is administrative type and directive category; a fire extinguisher is physical type and corrective category. A single cell therefore always combines a type AND a category. Another trap: Compensating is not a temporal category but a substitute control, chosen when the primary control cannot be implemented.

5.7 Continuous monitoring, SCA, KPIs and frameworks

Selecting and implementing controls is not enough: they must be monitored over time. The Security Control Assessment (SCA) is the periodic evaluation of control effectiveness and uses three complementary methods: Examine (review documents, configurations, policies), Interview (question staff) and Test (exercise the control under real conditions). The Examine / Interview / Test triad is the one to remember.

Monitoring relies on key performance indicators (KPIs) that quantify control performance over time and feed reporting to leadership, regulators and stakeholders. The goal is continuous improvement: continually verifying that the organization is improving its risk management and the return on investment (ROI) of its controls. The Risk Maturity Model (RMM) assesses the strength of the security program and lays out a continuous-improvement plan based on the maturity level reached.

On frameworks, several risk frameworks structure the approach: ISO 31000:2018 (general, enterprise-wide risk management), ISO 27005:2018 (information-security-specific risk management, aligned with ISO 27001), and on the NIST side, the NIST RMF (Risk Management Framework, described by SP 800-37) which leans on SP 800-30 for risk analysis. ISO Guide 73:2009 provides the common vocabulary. Trap: ISO 31000 is generic (enterprise), while ISO 27005 is dedicated to information security; do not confuse them, and do not confuse SP 800-30 (risk analysis guide) with SP 800-37 (the full RMF process).

5.8 Choosing qualitative/quantitative, FAIR, safeguard cost-benefit and frameworks

Knowing how to compute an ALE does not tell you WHEN to choose quantitative over qualitative. The ISC2 manual decides by context. Qualitative suits Newness (activity, market or organization too new to have a measurable track record), Uniqueness (products or ways of working so singular that no industry comparison exists), lack of time/money/talent to take the measurements, and the absence of a reliable measuring method. Quantitative suits cases where the business processes tied to the risk are well understood, where measurement techniques of sufficient precision and reliability exist, and where experience yields a sample large enough to be statistically significant. Trap: that last requirement (significant sample) is also the argument against over-using quantitative - without enough data the result is not significant; quantitative advocates reply that even two or three measurements good to one significant digit say more than anecdotal qualitative estimates.

The quantitative alternative the manual highlights is the FAIR method (Factor Analysis of Information Risk): it makes most assessment tasks start out quantitative and stay that way, in a numerically straightforward and managerially simple manner. FAIR is integrated into the NIST CSF and HITRUST, and compatible with ISO 31000, COBIT and COSO. It is the antidote to qualitative's logic flaw (you cannot average five Highs, three Mediums and one Low into a portfolio rating).

The term risk exposure has three distinct meanings. The exposure window measures over time the probability of occurrence of a risk event (you are not exposed to the car-accident risk while asleep at home; a firm backing political causes sees its threat probability climb near an election) - useful to risk-based access control systems. The exposure factor (EF) is the fraction (<1) of an asset's value reduced by a single occurrence (already seen: 1.0 = total destruction). The exposure estimate describes that a risk is categorically much lower or higher than another for a given organization (a company with no ties to a country has low exposure to that country's risks).

On control selection, the NIST RMF (Select step) offers two approaches. Baseline control selection starts from control baselines (predefined control sets for a group or community) then tailors by removal (top-down) - this provides consistency at broad scale. Organization-generated control selection starts from no predefined set: the organization picks controls through its own process (bottom-up), fitting for a highly specialized system (weapon, medical device, smart meter). Both then derive requirements via a life-cycle systems engineering process (ISO 15288, NIST SP 800-160 Vol 1).

Selection is decided by cost-benefit analysis. Key manual distinction: a safeguard reduces impact/likelihood BEFORE the risk is realized, a countermeasure reduces them AFTER. You compare the cost of acquiring, deploying and maintaining the control against its ability to reduce impact/likelihood AND against the cost of the risk if realized. Every control has a negative impact (monetary cost or loss of user capability/convenience): weigh this operational impact against the benefit. Broadened golden rule: in most cases, do not spend far more mitigating, transferring or avoiding a risk than the worst possible impact - even an acceptance decision is made in light of this trade-off. Practically, a safeguard's one-year value is: ALE before safeguard - ALE after safeguard - annual safeguard cost; a positive result justifies the control.

Finally, deploying overlapping controls of several types AND categories is defense in depth (layered defense), for two reasons: to avoid a single failure (e.g. a power cut neutralizing all technical controls, or a new vulnerability in the sole control) fully exposing you; and to force the attacker to prepare multiple means of attack, reducing their number. All of it must be reported: reporting serves two purposes on two timelines - in near real time it keeps managers informed of posture and issues alerts/alarms during an incident; periodically it provides accountability to management, and sometimes to regulators or even law enforcement, with the organization's approval. Beyond the risk frameworks already seen (ISO 31000, ISO 27005, NIST SP 800-30/800-37), the manual also cites NIST SP 800-39, COBIT, SABSA and PCI; ISO Guide 73 supplies the vocabulary and COSO/COBIT frame governance.

6.1 Threat modeling concepts

Threat modeling is a technique for examining an environment, system, or application from an attacker's point of view to determine the vulnerabilities they are likely to exploit, then identifying suitable countermeasures. The attack surface is the total range of areas where an attacker can potentially trigger a compromise: the larger it is, the higher the risk. Reducing the attack surface (disabling services, closing ports, removing accounts) is a first-order defensive strategy.

Threat modeling requires a nontechnical abstraction of the target before diving into detail. This is done with a data flow diagram (also called a dataflow diagram or workflow diagram): a conceptual view of how data and processes move through the target from start to finish. This abstraction lets the team pinpoint where (in time, space, and process) an attacker could act.

Three approaches structure the analysis. The attacker-centric approach starts from the actors who could cause harm (e.g., AML analysis, threat profiling) and works out their goals and capabilities. The asset-centric approach starts from the valuable assets to protect (e.g., PHI, PII) and works back toward the threats targeting them. The software-centric (or system-centric) approach represents the system as a set of interconnected processes via architecture diagrams, which analysts evaluate component by component; it is the most useful for most information system environments.

Exam trap: threat modeling is a form of testing; it identifies that a problem exists but does not fix it. Remediation is a later, separate step.

6.2 The threat modeling process

Threat modeling follows an ordered process. First step, assessment scope: identify the critical assets to protect. This step is closely tied to BIA (Business Impact Analysis) priorities; what is critical for business continuity is also critical to protect. You do not model everything indiscriminately: the scope frames the effort.

Second step, identify the threat agents and possible attacks: who or what wants to attack? Consider both insiders and outsiders, and both malicious and accidental threats. Third step, understand existing countermeasures: an audit of what is already in place and how effective it really is. Without this baseline, you risk proposing redundant controls or overestimating protection.

Fourth step, identify exploitable vulnerabilities, prioritizing those affecting the critical path defined by the BIA. Fifth step, prioritize the identified risks: threat modeling operates on priorities, because you cannot protect everything. Any residual risk left as-is must be justified and formally accepted. Sixth step, identify countermeasures to reduce risk: complete the defensive posture by deploying controls against the prioritized vulnerabilities (IDS/IPS, firewalls, access control, biometrics, etc.).

Exam trap: scope and prioritization rely on the BIA. A question asking where to start in threat modeling usually expects identifying/prioritizing critical assets, not immediately deploying countermeasures.

6.3 Methodologies: STRIDE, DREAD, PASTA

STRIDE is a threat classification system from the Microsoft Security Development Lifecycle (SDLC), used to inform developers about threats during development. Its six categories: Spoofing identity, Tampering with data (unauthorized data modification), Repudiation (the attacker can deny or conceal their participation), Information disclosure (accidental or malicious data exposure), Denial of service (an attack on availability, the A in the CIA triad), and Elevation of privilege (the attacker gains a level of control to disable or destroy the target). STRIDE categorizes: it tells you what type of threat it is.

DREAD is a scoring model: Damage, Reproducibility, Exploitability, Affected users, Discoverability. You rate each dimension to obtain a relative score that helps prioritize threats. STRIDE and DREAD are complementary: one classifies, the other quantifies.

PASTA (Process for Attack Simulation and Threat Analysis) is a seven-step, risk-centric methodology that aligns business objectives with technical threat analysis and simulates attacks to assess real risk. It runs from defining objectives to risk and impact analysis.

Also worth knowing (at least by name): OCTAVE (organization-wide view of IT systems risk, variants OCTAVE and OCTAVE-S), TRIKE, VAST, CORAS, LINDDUN (privacy-oriented), and NIST SP 800-154 (data-centric threat modeling guide). ATASM (Architecture, Threats, Attack Surfaces, Mitigations) is another cited approach.

Exam trap: do not confuse STRIDE (threat categorization) with DREAD (scoring/prioritization). PASTA stands out for being risk-centric with its 7 steps.

6.4 Supply Chain Risk Management (SCRM)

No organization operates alone: it depends on suppliers, vendors, contractors, and customers. SCRM applies to this chain the same risk management methodologies the organization applies to its internal operations. Historically, supply chain risks targeted tangible assets (fires, natural disasters), but information and communication technologies are just as vulnerable, accidentally and maliciously, especially for critical systems.

Risks fall into three families. Hardware: purchased equipment (servers, workstations, cameras, legacy factory systems) that can be counterfeited or tampered with; a Silicon Root of Trust and a Software Bill of Materials (SBOM) help verify integrity. Software: off-the-shelf software with bugs or poorly designed functions that are exploitable; a flaw unknown to the vendor and exploited by an attacker is a zero-day. Services / Cloud: attacking a small supplier shared by large companies is often easier than attacking those large companies directly.

Acquisition best practices impose cybersecurity requirements as a condition of contract award, and favor buying from OEMs (Original Equipment Manufacturers), their trusted sources, and authorized resellers, to avoid counterfeit equipment. Beware of 4th parties: your own suppliers' subcontractors extend the chain and the risk beyond your direct visibility.

Classic examples: Target (2013, access via an HVAC third party to payment terminals), XCodeGhost (2015, counterfeited XCode compiler), and above all SolarWinds/Sunburst (2020): a legitimate network monitoring tool, infected at the source, distributed the Sunburst malware to thousands of organizations - a textbook software supply chain attack.

Exam trap: compromising a single service provider to reach all of its customers (SolarWinds) is the core SCRM argument. The weakest third party often defines the real security level.

6.5 Third-party assessment and due diligence

Before any binding supply chain agreement, the security professional must conduct due diligence on the third party. It combines three activities: the on-site assessment (visiting and inspecting the supplier's premises), the document exchange (exchanging documentation: policies, certifications, audit reports), and the process/policy review (reviewing processes and policies to verify the supplier follows an acceptable security control framework). The security professional must be involved in all three to understand the transaction's risks. External assurances complete the assessment: ISO audits, CSA STAR for cloud, or AICPA attestations (SOC).

Minimum security requirements are defined during the project's requirements gathering phase. A best practice is to write a Statement of Requirements covering: a concise requirement specification for management, a statement of key objectives, a description of the operating environment, background and references, and major design constraints.

Two documents structure the relationship. The SLR (Service Level Requirements) describes the expected service from the client's viewpoint: it is the upstream expression of need. The SLA (Service Level Agreement) is the signed agreement between the third party and the client, documenting the IT service provided, the service level targets (measurable goals), and the respective responsibilities of supplier and customer. In short: the SLR expresses what you want, the SLA contractually commits to what will be delivered and measured.

Contractual clauses reinforce governance: right to audit to verify the supplier's compliance, breach/incident notification obligations, subcontracting requirements (governing 4th parties), and jurisdiction clauses when the third party operates under a different regulation.

Exam trap: due diligence happens BEFORE the contract is signed; the right to audit and the SLA govern the execution phase. And never confuse SLR (need, client-side) with SLA (signed, bilateral, measurable agreement).

6.6 Reduction analysis (decomposition) and prioritization

Once the data flow diagram is drawn, the decisive step of software-centric threat modeling is reduction analysis, also called decomposition. To decompose means breaking the system into its constituent elements to make visible the exact places where an attacker can act. Five elements must be identified systematically.

First, trust boundaries: any boundary where the level of trust or privilege changes (between the Internet and the DMZ, between the DMZ and the internal network, between the application and the database). Threats concentrate at these boundaries, because data crosses from one trust zone into another there. Next, data flow paths: the route data follows through the system, from one point to another. Then input points (or entry points): any place where external data enters the system (forms, APIs, uploads, parameters); these are the doors through which the attacker injects. Then privileged operations: actions requiring elevated rights (changing a config, creating an admin account, accessing a key) that are prime targets for elevation of privilege. Finally, the description of the security stance / approach: the application's security posture and assumptions (policies, dependencies, controls presumed in place), which must be made explicit so they are not taken for granted.

Decomposition feeds prioritization directly, because threat modeling works by priorities: you cannot address everything. Two simple, frequently tested methods. First, Probability x Damage Potential, which combines the likelihood that a threat materializes with the magnitude of damage if it does, yielding a risk ranking. Second, a qualitative High / Medium / Low ranking, faster when quantified data is lacking. DREAD is a finer scoring variant of this same logic.

Two methodologies round out the landscape beyond STRIDE/DREAD/PASTA. VAST (Visual, Agile, and Simple Threat modeling) is designed to scale across agile organizations: it distinguishes application threat models (developer-oriented, via process flow diagrams) from operational threat models (infrastructure- and architect-oriented), and integrates into DevOps pipelines. Trike is a risk-management- and audit-oriented methodology built on a requirements model that assigns an acceptable risk level to each asset and generates threat models from that model.

Exam trap: remember that threat modeling, decomposition included, is a form of testing. It reveals where the weak trust boundaries, exposed input points, and risky privileged operations are, but it fixes nothing: remediation is a later, separate step.

7.1 Business Continuity and the BIA

Business continuity (BC) covers the actions, processes and tools that let the organization keep its critical operations running during a contingency; disaster recovery (DR) covers restoration back to normal operations. Together they are called BCDR. Everything starts with the Business Impact Analysis (BIA), the effort that determines the value of each asset, the likely threats and the potential for those threats to materialize. The BIA reveals the critical path: the set of activities without which the organization cannot survive. Example: an insurer whose systems go down can keep issuing policies manually - a costly but viable workaround.

The BIA is above all a management process. It requires senior leadership support, because leaders set the tolerable level of risk (risk appetite / risk tolerance) and weigh the costs. The risks to assess go beyond the technical: financial impact (revenue loss), reputational (loss of customer trust), and regulatory (HIPAA mandates a data backup plan and an emergency operations mode; noncompliance means penalties). Several methods feed the BIA: surveys of asset owners (close to the ground but biased), financial audit (thorough but value varies over time), customer feedback, industry benchmarks.

The BIA then prioritizes Critical Business Functions. A classic grid distinguishes: Critical (a halt immediately threatens survival - e.g. a payment engine), Essential (needed short term but tolerates a brief interruption), Supporting (assists critical functions without being vital - e.g. internal reporting), Nonessential (can be suspended for a long time - e.g. internal audit, hiring). Exam pitfall: the BIA is not a recovery plan; it provides the data (critical path, values, dependencies) that feed the BCP/DRP. Confusing BIA with BCP is a classic mistake.

7.2 The Three Key BIA Outputs: MTD, RTO, RPO

The BIA produces three control parameters that senior management hands to the BCDR designers. The Maximum Tolerable Downtime (MTD), also called Maximum Allowable Downtime (MAD) or Maximum Allowable Outage (MAO), is the maximum duration a business process can be disrupted without causing significant or unacceptable harm to the mission. It is a ceiling: beyond it, the organization suffers serious damage. Example: for a trading platform the MTD may be a few hours; for a brochure website, several days.

The Recovery Time Objective (RTO) is the target duration to restore availability of the critical path after an interruption. Fundamental constraint: RTO <= MTD. Setting the RTO equal to or greater than the MTD defeats its purpose, since the harm threshold would be crossed. Note: "recovery" here is not the return to normal operations, but the return to temporary functional availability of the critical path. The shorter the RTO, the costlier the BCDR solution: it is a cost/speed trade-off.

The Recovery Point Objective (RPO) measures how much data the organization can lose without unacceptable harm. It is expressed in units of time (minutes, hours, days), generally the gap between the last good backup and the moment of the incident - not in gigabytes. For a bank the RPO tends toward zero (no transaction lost); other sectors tolerate more. On the timeline: RPO looks backward (data lost before the incident), RTO looks forward (time to recover after). Also note the Work Recovery Time (WRT), the period for catching up accumulated transactions. Exam pitfall: RTO = time, RPO = data (expressed in time). Confusing the two is the most frequent mistake.

7.3 Personnel Security: the Lifecycle

People are double-edged: a source of error and malice, but also the first line of defense. The insider threat is addressed as early as possible, before access to data. Candidate screening precedes hiring: a precise job description (reference to assess performance and ground any later termination), verification of references, employment history, background check (criminal record, degrees, certifications) and, for highly sensitive roles, a financial profile (reveals exploitable instability). Once hired, access follows least privilege and ideally an RBAC model where rights derive from the described role.

At hiring, employment agreements are signed: employee handbook (policies and standards, receipt acknowledged), employment contract (terms, pay, performance), Nondisclosure Agreement (NDA, non-disclosure during and after employment), Acceptable Use Policy (AUP, approved use of assets) and Code of Conduct. These documents are signed no later than onboarding, ideally before a representative, each party keeping a copy. Onboarding includes review of the contract and job description, initial security training, and secure issuance of access (ID/password, badges, tokens).

Termination must be equally codified. We distinguish friendly (amicable departure, e.g. resignation, retirement) - an exit interview can be held to learn the reasons and remind of NDA obligations - and unfriendly (dismissal, conflictual departure) which demands stronger, faster controls. In all cases: immediately lock IT accounts to prevent last-minute changes, recover equipment and access control items (badge, keys, tokens), review NDA terms, and escort the person off premises if the role is not remote. Exam pitfall: for an administrator dismissed without notice (unfriendly), access revocation must precede or accompany the announcement, never follow it; a forewarned admin can sabotage or exfiltrate.

7.4 Internal Third-Party Controls: Vendor, Consultant, Contractor

Internal third parties - vendor, consultant, contractor, subcontractors, visitors - gain physical or logical access without falling under the same HR controls as employees. They are an often-underestimated insider-threat vector. The guiding principle remains least privilege: access is limited to the strict minimum, for the strictly required duration, and revoked as soon as the engagement ends. Before any access, a reliable identity verification is performed and, depending on sensitivity, a background check, which may be required of the third party or of their employer.

Contractually, the third party signs a specific NDA (often distinct from the employees' one, sometimes a mutual NDA / two-way NDA when sensitive information flows both ways) and accepts an AUP covering the assets they access. The contract must codify security obligations, ownership of deliverables and the conditions for ending access. For subcontractors accessing systems, the organization can impose explicit people-facing instructions and monitoring and surveillance activities.

Typical operational controls: physical escort for visitors and workers in sensitive zones, activity monitoring (supervised screen sharing, session recording, logging), and access restricted to the relevant systems only. Any surveillance must strictly comply with applicable laws, which vary widely across jurisdictions. Exam pitfall: a consultant is not an employee; do not apply the same onboarding controls by default, but a dedicated regime (specific NDA, escort, reinforced monitoring, temporary access) - and remember to revoke access at the end of the engagement, otherwise you leave exploitable orphan accounts.

7.5 Awareness Program: Awareness, Training, Education

A human-security program is a matter of due care (providing effective training) and due diligence (verifying it works). The exam distinguishes three types of learning activity. Awareness ("the why", for everyone) attracts and engages attention by acquainting people with an issue; it shapes beliefs and behaviors (signage, screensavers, newsletters, reminders). Training (role-related skills) builds proficiency in a precise set of tasks: recognizing phishing and applying the right response. Education (deep understanding) explains causes and concepts for a targeted audience, often tied to certifications. Mnemonic: Awareness changes what you notice, Training what you can do, Education what you understand.

The program particularly targets social engineering (phishing, vishing, smishing). Methods: Computer-Based Training (CBT, self-paced, standardized, but click-through risk - effective coupled with fake phishing tests), live training (counters click-through, builds rapport), regular communications, reward mechanisms (rewarding good behavior rather than punishing), gamification (greater engagement and retention, e.g. OWASP Cornucopia) and Security Champions (volunteers from each business area spreading good reflexes). Content must be reviewed periodically (laws, policy, new attacks, new tools).

Due diligence requires measuring effectiveness through metrics tied to objectives. Examples: phishing-simulation click rate (expected to fall over time), module completion rate, signed attestation (proof of acknowledgement), number of incident reports, assessment results. Exam pitfall: do not confuse the three levels. A mandatory CBT module on "how to recognize phishing" is Training, not Education; a poster reminding to lock your screen is Awareness. The typical question gives an example and asks you to name the level - the right answer depends on the verb: to make aware (Awareness), to make capable (Training), to make deeply understand (Education).

7.6 HR Anti-Fraud Controls: SoD, Least Privilege, Job Rotation, Mandatory Vacation, Dual Control

Beyond the joiner-mover-leaver lifecycle, personnel security rests on a family of administrative controls that reduce insider threat and fraud. They split into preventive (they stop abuse from happening) and detective (they reveal it afterward). The manual in fact opens the topic with the two-person integrity control, showing these mechanisms sit at the heart of Domain 1.

Preventive controls. Separation of duties (SoD) breaks a sensitive transaction into several steps assigned to different people, so no single individual can carry it out end to end (e.g. whoever creates a vendor cannot approve its payment). Least privilege grants the minimum rights needed for the role, ideally via RBAC. Need-to-know goes further: even when cleared, one accesses only the information strictly required for the task at hand (least privilege governs system permissions, need-to-know governs knowledge). Dual control / two-person control (sometimes two-person integrity or the two-person rule) requires two people to act together for a critical operation (e.g. two keys for a vault, dual approval of a wire transfer). Note: SoD spreads different steps across people; dual control requires two people for the same step.

Detective and hybrid controls. Job rotation moves people between functions; it makes sustained fraud harder (a collusion becomes unstable) and surfaces wrongdoing when a successor finds the anomalies, while reducing single points of knowledge. Mandatory vacation forces an employee to be away for a continuous period during which another person fills the role: a fraud that needs daily presence to be maintained (account falsification, lapping) eventually surfaces. Job rotation and mandatory vacation are mainly detective (and deterrent), whereas SoD, least privilege, need-to-know and dual control are preventive. Exam pitfall: do not confuse the three. SoD = split a task across several people (preventive); job rotation = move people between roles over time (detective); mandatory vacation = remove the person so another uncovers the fraud (detective). If the question asks "which control reveals a fraud an employee hides by staying at their post", the answer is mandatory vacation.

7.7 BCMS and Continuity Standards: ISO 22301, NIST SP 800-34, BC vs DR

An organization that wants to formalize its continuity can build its Business Continuity Plan (BCP) from scratch or rely on recognized standards, either as a reference or by fully adopting them. Knowing these frameworks and the notion of a Business Continuity Management System (BCMS) - the management system that runs continuity as an ongoing process, not a frozen document - is expected at the exam.

Standards to remember. NIST SP 800-34 (Contingency Planning Guide for Federal Information Systems) provides instructions and recommendations for federal-system contingency planning. The ISO 22300 series defines the requirements and guidelines of a BCMS: ISO 22300 (vocabulary, the glossary), ISO 22301 (requirements, the certifiable standard setting BCMS requirements), ISO 22313 (guidance, help in implementing 22301) and ISO/TS 22315 (guidelines for business impact analysis, the BIA). Mnemonic: 22301 = what to do (requirements, certifiable); 22313 = how to do it (guidance). The organization may also have to meet continuity requirements of legal, regulatory or contractual origin (e.g. HIPAA mandates a data backup plan and an emergency operations mode; some financial venues mandate a BCP).

BC vs DR: the distinction the exam tests. These are two separate elements. Business Continuity (BC) is the organization's ability to keep its core functions running and to keep delivering products and services during a major disruption - the business and organizational side. Disaster Recovery (DR) is how that continuity is technically achieved and restored: the technologies, infrastructure and tools required; DR is part of the BCP. Plainly: BC = stay operational on the business side; DR = restore the systems and return to normal. Both start from a policy and rely on the BIA, which sets the scope and extent of the plans. Finally, once the critical path is identified, all external dependencies (supply chain, providers, cloud) are captured and a stakeholder map is built feeding a communications plan; for a cloud-based operation the plan must cover failure modes of losing a local data center, a region, or even the global SaaS provider (the hardest to recover from). Exam pitfall: do not reduce BC to DR. If the question contrasts "keep functioning" (BC) with "restore the systems" (DR), or asks which standard is certifiable (ISO 22301), keep the distinction sharp.