Security Risk, Architecture and Control Frameworks

Introduction

Data security is not achieved by installing a firewall or encrypting a database in isolation. It is the result of a coordinated system of governance, architecture, technology, processes, people and assurance. For data-science organisations, this challenge is intensified by distributed data platforms, cloud services, machine-learning pipelines, third-party data sharing and the large volume of sensitive information processed by analytical systems.

A sound security programme begins by understanding what must be protected, from whom, why it may be attacked, and what consequences could follow. It then translates that understanding into architectural safeguards and a structured control framework. This chapter develops that progression through asset assessment, threat modelling, risk analysis, defence in depth, secure-by-design principles and major security frameworks, including the NIST Cybersecurity Framework (CSF), NIST Risk Management Framework (RMF), ISO/IEC 27001 and CIS Controls.

The frameworks discussed are complementary rather than interchangeable. NIST CSF is primarily an organising and communication model; NIST RMF is a lifecycle for managing information-system risk; ISO/IEC 27001 specifies requirements for an information security management system (ISMS); and CIS Controls provide a prioritised set of practical safeguards. Effective practitioners use them as parts of an integrated governance and engineering system.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Identify and classify data, systems, services and other security assets.
2. Analyse threats, vulnerabilities, attack paths and potential business impact.
3. Distinguish inherent, residual and accepted risk.
4. Apply qualitative and quantitative approaches to risk assessment.
5. Design defence-in-depth and secure-by-design architectures.
6. Interpret and relate NIST CSF, NIST RMF, ISO/IEC 27001 and CIS Controls.
7. Select controls proportionately, document risk decisions and evaluate control effectiveness.
8. Recognise ethical, legal, privacy and governance implications of data-security decisions.

1. The Security Risk Perspective

1.1 Assets, threats, vulnerabilities and risk

An asset is anything that has value to an organisation or whose compromise could cause harm. Assets include personal data, credentials, source code, models, datasets, cloud accounts, computation environments, networks, business processes, intellectual property and organisational reputation. A data-science asset may be the training data itself, a feature store, an experiment-tracking service or a model that influences credit, employment or medical decisions.

A threat is a potential cause of an unwanted incident. Threat sources may be external attackers, malicious insiders, negligent employees, criminal groups, competitors, suppliers, natural hazards or software failures. A vulnerability is a weakness that can be exploited or triggered. Examples include excessive privileges, unpatched software, weak authentication, exposed storage, insecure application programming interfaces and inadequate backup testing.

A security event is an observable occurrence relevant to security. An incident is an event that actually or potentially compromises confidentiality, integrity or availability, or violates security policy. These concepts should not be conflated: a failed login may be an event, whereas a successful credential compromise may become an incident.

The traditional security objectives are represented by the CIA triad:

• Confidentiality: information is disclosed only to authorised subjects.
• Integrity: information and systems remain accurate, complete and protected from unauthorised alteration.
• Availability: authorised users can access information and services when required.

Modern data-security programmes extend the triad with authenticity, accountability, non-repudiation, privacy, resilience and safety. In machine-learning systems, integrity also includes protection against training-data poisoning and unauthorised model modification. Confidentiality may include resistance to membership inference or model inversion, while availability includes resilience against denial-of-service attacks and destructive ransomware.

1.2 Risk as a decision concept

Risk is not merely the presence of a vulnerability. It is the possibility that uncertainty will affect objectives. A useful conceptual expression is:

Here, likelihood describes the estimated chance or frequency of a harmful event under stated assumptions, and impact describes the magnitude of consequences if it occurs. The expression is a decision aid, not a universal physical law. Likelihood and impact may be ordinal categories rather than precise probabilities, so multiplying arbitrary scores can create false precision.

A more explicit expected-loss model is:

where E(L) is expected loss over a defined period, P(I_i) is the probability of incident outcome I_i, C(I_i) is its cost or consequence, and n is the number of mutually exclusive outcomes considered. This model assumes that the outcomes are defined consistently and that the probability estimates are meaningful. It is useful for economic comparison, but it cannot capture all ethical, legal or strategic consequences in monetary terms.

Risk assessment should therefore combine evidence, expert judgement, scenario analysis and stakeholder values. A low-probability event involving irreversible harm to individuals may require stronger treatment than its expected monetary loss suggests.

1.3 Inherent, residual and accepted risk

Inherent risk is the risk before controls are applied. Control effectiveness is the degree to which safeguards reduce likelihood, impact or both. Residual risk is the risk remaining after controls operate. Risk acceptance is a deliberate decision by an authorised owner to tolerate residual risk within specified boundaries. Acceptance is not the same as ignoring risk; it should be documented, time-bounded where appropriate and subject to review.

Risk treatment normally consists of four choices:

1. Avoid: stop the activity or redesign it so the risk no longer arises.
2. Mitigate: reduce likelihood or impact through controls.
3. Transfer or share: allocate some consequences contractually or through insurance, without assuming that accountability disappears.
4. Accept: retain the risk after informed evaluation.

2. Asset Assessment and Classification

2.1 Establishing an asset inventory

Risk analysis is unreliable when the organisation does not know what it owns or operates. An asset inventory should identify the asset owner, custodian, location, business purpose, dependencies, data types, users, interfaces, lifecycle state and recovery requirements. Discovery should cover formal systems and informal or shadow systems, including personal notebooks, unmanaged cloud storage, open-source repositories and temporary analytical environments.

For data assets, lineage is particularly important. A lineage record describes where data originated, how it was transformed, where it is stored, who can access it and which decisions depend on it. It supports breach investigation, reproducibility, regulatory response and deletion requests.

2.2 Classification and criticality

Classification schemes differ, but a practical model may include public, internal, confidential and restricted information. Classification should be based on potential harm from unauthorised disclosure, alteration or loss. Examples of restricted information include health records, authentication secrets, payment data, biometric data and certain government information.

Classification is not sufficient by itself. Criticality assessment asks how strongly a service or process depends on an asset. A public dataset may be low in confidentiality but high in integrity if manipulated data would corrupt a public-health model. Consequently, classification should consider confidentiality, integrity and availability separately.

Business impact analysis converts asset importance into operational requirements. Common outputs include recovery time objective (RTO), the target maximum time to restore a service, and recovery point objective (RPO), the target maximum tolerable age of recovered data. RTO is measured in time; RPO is also measured in time, representing potential data loss. Neither is a security control by itself, but both guide resilience design.

3. Threat Modelling and Vulnerability Analysis

3.1 Threat sources and attack surfaces

Threat modelling is a structured examination of how a system could be misused or harmed. It should begin early in the design process and be updated when architecture, data, suppliers or threats change. The attack surface includes exposed interfaces, identities, software dependencies, administrative pathways, data exports, physical locations and human processes.

A useful workflow is:

1. Define the system purpose, trust boundaries and security objectives.
2. Identify assets and data flows.
3. Enumerate threat sources and abuse cases.
4. Identify vulnerabilities and preconditions.
5. Estimate likelihood and impact.
6. Select treatments and verify assumptions.
7. Monitor changes and re-assess.

Threat modelling approaches include STRIDE, which examines spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege; attack trees, which decompose an attacker’s objective into alternative paths; and misuse cases, which describe harmful use from an adversarial perspective. These methods are complementary. STRIDE is useful for design reviews, while attack trees support path analysis and prioritisation.

3.2 Data-science-specific threats

Data-science environments introduce threats beyond conventional application security:

• Data poisoning: malicious or low-quality records influence training outcomes.
• Model theft: unauthorised parties reconstruct or extract a valuable model.
• Membership inference: an attacker infers whether a person’s record was in training data.
• Model inversion: sensitive features are inferred from model outputs.
• Prompt or instruction injection: untrusted content manipulates an AI system into violating intended rules.
• Supply-chain compromise: a package, pretrained model, dataset or pipeline component is malicious or tampered with.
• Re-identification: supposedly de-identified records are linked with external information.
• Credential and secret exposure: tokens appear in notebooks, logs or repositories.

Threat analysis should include both malicious and non-malicious failure modes. A poorly documented transformation may create systematic bias or corrupt labels without any attacker being present.

3.3 Vulnerability and control evidence

Vulnerability scanning, penetration testing, configuration assessment, code review, dependency analysis and red-team exercises provide different forms of evidence. A scanner may identify an outdated library but cannot determine alone whether the vulnerability is exploitable in the organisation’s architecture. Conversely, a clean scan does not prove that access rights are appropriate or that backups can be restored.

Security evidence should be traceable to an asset, control, test method, date, result and responsible party. This makes assurance auditable and supports trend analysis.

4. Secure-by-Design and Defence in Depth

4.1 Secure-by-design principles

Secure-by-design means that security and privacy are treated as design requirements rather than post-deployment additions. Important principles include:

• Least privilege: grant only the access necessary for an approved task and duration.
• Separation of duties: divide sensitive actions among roles so that no single person can abuse a complete process without detection.
• Fail-safe defaults: deny access unless a legitimate rule permits it.
• Complete mediation: validate access on every relevant request, not only at initial login.
• Economy of mechanism: reduce unnecessary complexity and attack surface.
• Open design: do not depend on secrecy of design; protect keys, credentials and sensitive configuration.
• Psychological acceptability: controls should be usable enough that people do not routinely bypass them.
• Secure failure and recovery: errors should not disclose sensitive information, and recovery should preserve trustworthy states.
• Data minimisation: collect and retain only what is justified.
• Privacy by default: use the least intrusive processing compatible with the purpose.

These principles require trade-offs. For example, extensive logging improves accountability but may create a new sensitive dataset. A mature design therefore protects logs, limits retention and controls access to them.

4.2 Defence in depth

Defence in depth uses multiple, partially independent layers so that failure of one safeguard does not expose the entire system. A data platform may employ physical security, network segmentation, identity controls, application validation, encryption, database permissions, endpoint protection, monitoring, backups and incident response.

Layers should not be treated as a checklist of duplicated controls. Their value depends on independence, correct configuration and timely detection. If every layer relies on the same compromised identity provider, the apparent depth may be illusory. Diversity of mechanisms and separation of administrative paths can reduce correlated failure.

A simplified architecture may separate:

1. Data layer: classification, encryption, masking, retention and integrity controls.
2. Application layer: input validation, secure APIs, session controls and authorisation.
3. Identity layer: strong authentication, federation, privileged-access management and lifecycle governance.
4. Network and platform layer: segmentation, hardened configurations, vulnerability management and workload isolation.
5. Detection layer: central logging, alerting, threat intelligence and behavioural analysis.
6. Response and recovery layer: containment, forensics, tested backups, continuity and lessons learned.

Zero trust is consistent with defence in depth but is not identical to it. Zero trust rejects implicit trust based solely on network location and requires continuous evaluation of identity, device, resource, context and policy. It does not mean that every request can be perfectly verified; it means that access decisions are explicit, risk-informed and continually reconsidered.

5. Control Selection and Assurance

A control is a measure that modifies risk. Controls may be preventive, detective, corrective, deterrent or compensating. They may also be administrative, technical or physical. Encryption is technical; a classification policy is administrative; a locked server room is physical. A control objective states the desired outcome, while a control activity describes how the outcome is achieved.

Control selection should consider:

• the asset and threat scenario;
• legal, contractual and policy obligations;
• control strength and coverage;
• implementation and operating cost;
• usability and operational friction;
• dependencies and single points of failure;
• evidence required for assurance;
• residual risk and risk appetite.

A control is not effective merely because it exists in documentation. Its design must be suitable, and its operation must be consistent and timely. For example, an access-review control requires defined scope, accountable reviewers, meaningful evidence, timely removal of inappropriate access and escalation of unresolved exceptions.

Control testing may involve inquiry, inspection, observation, reperformance and technical testing. Continuous monitoring is valuable for rapidly changing cloud and software environments, but automated signals require calibration to avoid alert fatigue and blind spots.

6. Major Security Frameworks

6.1 NIST Cybersecurity Framework

The NIST Cybersecurity Framework 2.0 organises cybersecurity outcomes into six functions: Govern, Identify, Protect, Detect, Respond and Recover. Govern is a central function addressing organisational context, risk strategy, roles, policy, oversight and supply-chain risk. The other functions describe outcomes rather than prescribing one technology.

The CSF is useful for executive communication, current-state assessment, target-state definition and prioritisation. Organisations can create a current profile, identify gaps, define a target profile and develop an improvement plan. The framework’s flexibility allows mapping to detailed controls such as CIS Controls, ISO/IEC 27001 controls or sector requirements.

A limitation is that the CSF does not by itself provide a complete implementation method, risk valuation model or audit certificate. It must be supported by policies, procedures, architecture and evidence.

6.2 NIST Risk Management Framework

The NIST RMF is a system-oriented lifecycle for managing security and privacy risk. Its commonly used steps are Prepare, Categorize, Select, Implement, Assess, Authorize and Monitor.

• Prepare: establish context, risk assumptions, stakeholders and system dependencies.
• Categorize: determine the potential impact of loss of confidentiality, integrity and availability.
• Select: choose and tailor controls according to risk.
• Implement: document how controls operate.
• Assess: determine whether controls are correctly implemented and effective.
• Authorize: an accountable official decides whether residual risk is acceptable.
• Monitor: track changes, control performance and emerging threats.

RMF emphasises traceability from system context to control selection and authorization. It is particularly valuable in regulated and high-assurance environments. Its documentation burden can be substantial, so organisations should automate evidence collection and scale rigor according to impact.

6.3 ISO/IEC 27001 and the ISMS

ISO/IEC 27001 specifies requirements for establishing, implementing, maintaining and continually improving an ISMS. The ISMS is a management system, not merely a list of technical safeguards. It requires organisational context, leadership, planning, support, operation, performance evaluation and improvement.

Risk treatment leads to a documented Statement of Applicability, which records selected controls, their justification and implementation status. ISO/IEC 27001 certification is performed by an independent certification body and concerns conformity of the ISMS within a defined scope. Certification does not mean that every possible attack is prevented or that every product used by an organisation is secure.

ISO/IEC 27002 provides guidance on information-security controls, while ISO/IEC 27701 extends the management-system perspective toward privacy information management. Organisations should verify the current editions and sector-specific requirements before relying on a standard.

6.4 CIS Controls

CIS Controls are a prioritised set of safeguards intended to reduce common attack paths. They are operationally oriented and often easier for engineering teams to translate into actions than high-level governance frameworks. Examples include maintaining an enterprise asset inventory, protecting accounts, managing software, establishing data protection processes, enabling audit logging, conducting vulnerability management and preparing incident response.

Implementation groups help organisations apply safeguards according to resources and risk. CIS Controls are not a replacement for legal obligations, risk governance or system-specific analysis. A technically mature organisation can still fail if it applies safeguards without understanding business context, privacy consequences or critical dependencies.

6.5 Relationship among the frameworks

Framework mapping should avoid “checkbox compliance.” Two controls may have similar names but different scope, evidence or effectiveness. A mapping is useful only when it explains equivalence, gaps, ownership and implementation evidence.

7. Worked Risk Example

Consider a university data-science platform containing identifiable student records and research datasets. The platform uses cloud object storage, notebooks, a feature store and a model-serving API.

The assessment identifies a threat scenario: a compromised researcher credential is used to download restricted records. Existing controls include password authentication, broad project-level access and provider-managed encryption. The assessment team rates the pre-control likelihood as 4 on a five-point ordinal scale and impact as 5, producing a score of 20 under the organisation’s stated scoring convention. This number is meaningful only within that convention; it is not a probability or monetary loss.

Treatment options include phishing-resistant multifactor authentication, role-based access, time-limited privileged access, dataset masking, download monitoring and tested incident response. After implementation, the team rates likelihood as 2 and impact as 4 because masking reduces the consequence of some exports. The residual score is 8. The risk owner may accept it if it is within appetite, or require further treatment if restricted records remain directly downloadable.

The example illustrates three important points. First, controls can reduce likelihood, impact or both. Second, a numerical score does not replace explanation of assumptions. Third, the owner must decide whether residual risk is acceptable; the security team does not silently make that governance decision.

8. Applied Case: Illustrative Health-Analytics Platform

Background

A fictional regional health authority, HealthData North, develops a machine-learning model to predict hospital readmission. Data comes from hospitals, laboratories and community providers. Analysts use a cloud workspace, while an application exposes predictions to authorised clinicians.

Problem

An internal review finds that the original design granted analysts access to full patient identifiers, service accounts were shared across pipeline jobs, and model-training data was copied into temporary notebooks. Logs recorded API errors but not all data exports. The organisation also lacked a tested process for deleting data supplied under a time-limited research agreement.

Analysis

The asset assessment classifies patient records and linkage keys as restricted. The model and feature definitions are confidential, while prediction availability is operationally important but not safety-critical because clinicians retain decision authority. Threat modelling identifies credential theft, insider misuse, re-identification, supply-chain compromise and accidental disclosure through notebooks.

The architecture review identifies a trust-boundary problem: analysts, pipelines and model-serving services share a broad project identity. This violates least privilege and makes accountability weak. The data lifecycle review identifies excessive replication and unclear retention. The governance review identifies a mismatch between research consent, operational use and actual data flows.

Approach and solution

HealthData North redesigns the platform around separate identities for people, workloads and administrators. Analysts receive views containing pseudonymous identifiers, while the linkage service is isolated and access is logged. Workload identities obtain narrowly scoped, short-lived credentials. Restricted datasets are stored in segmented repositories, and notebooks use controlled ephemeral environments with export restrictions.

The organisation introduces a data inventory and lineage register, formal retention schedules, encryption with managed key separation, centralised tamper-evident logging and alerts for unusual downloads. The model pipeline uses approved dependencies, signed artefacts and validation checks for unexpected changes in training-data distributions. A privacy review assesses re-identification risk and documents the permitted purposes of processing.

Controls are mapped to a CSF target profile, selected and assessed using an RMF-style lifecycle, documented within the ISMS, and prioritised operationally through CIS safeguards. A tabletop exercise tests credential compromise, while restore testing verifies that critical services can recover.

Outcome

The redesigned system reduces unnecessary access, improves attribution and makes data flows visible. It does not eliminate risk: privileged administrators remain a high-impact threat, model outputs may still be biased, and third-party dependencies require continuing review. The authority therefore establishes quarterly access recertification, continuous monitoring of high-risk events and annual reassessment of purpose, retention and model performance.

Learning points

1. Architecture, privacy and security decisions are inseparable in sensitive analytics.
2. Pseudonymisation reduces exposure but is not equivalent to anonymisation.
3. Workload identities and short-lived privileges improve accountability and containment.
4. Frameworks are most useful when translated into system-specific evidence.
5. Security controls cannot substitute for lawful purpose, ethical review and human accountability.

9. Governance, Ethics and Regulation

Security decisions affect rights and social outcomes. Data minimisation, purpose limitation, transparency, fairness and accountability should be considered alongside confidentiality and operational efficiency. An organisation may have authority to access data technically but lack a legitimate purpose to use it. Likewise, a model may be secure from intrusion but harmful because its training data encodes discrimination.

Regulatory obligations vary by jurisdiction and sector. Common requirements concern breach notification, privacy rights, records retention, critical infrastructure, payment information, health information and cross-border transfers. Frameworks do not replace law. Legal interpretation should involve qualified counsel, and control design should preserve evidence needed for regulatory response.

AI systems require additional governance. Security teams should evaluate training-data provenance, prompt and tool permissions, output handling, model supply chains, evaluation datasets and monitoring for abuse. Human oversight must be meaningful rather than a nominal approval step. Logging AI interactions can support accountability but may itself expose personal or confidential information.

10. Contemporary Developments and Limitations

Cloud-native infrastructure, software supply-chain attacks, ransomware, remote work, generative AI and geopolitical threats are changing risk profiles. Infrastructure as code and policy as code can improve consistency, while continuous control monitoring can identify drift. Confidential-computing technologies may reduce exposure during processing, but they introduce operational complexity and do not solve flawed authorisation or poor data governance.

Common limitations in risk programmes include stale inventories, overreliance on compliance certificates, unsupported probability estimates, excessive control complexity, untested recovery procedures and weak ownership. Risk registers can become administrative artefacts if they are not connected to architecture decisions, budgets and measurable treatment plans.

A mature programme uses proportionality. High-impact systems require stronger evidence, segregation, testing and independent assurance than low-risk applications. At the same time, essential baseline safeguards should be automated wherever possible. Security should be measurable through indicators such as privileged-access review completion, mean time to contain incidents, backup restoration success, vulnerability remediation age and coverage of critical assets. Metrics must be interpreted carefully: a high number of detected incidents may indicate improved detection rather than worsening security.

Best-Practice Design Checklist

• Maintain an authoritative inventory of assets, data, identities and dependencies.
• Classify information using confidentiality, integrity, availability and privacy consequences.
• Model trust boundaries and abuse cases before implementation.
• Use least privilege, separation of duties and strong identity lifecycle management.
• Segment sensitive data and administrative pathways.
• Encrypt data in transit and at rest, while protecting keys separately.
• Record meaningful, protected and privacy-conscious audit logs.
• Test backups, incident response and recovery rather than merely documenting them.
• Map controls to accountable owners and objective evidence.
• Reassess risk after major changes, incidents, supplier changes or new uses of data.
• Integrate security, privacy, safety and fairness reviews into the data-science lifecycle.
• Treat frameworks as decision-support structures, not substitutes for judgement.

Chapter Summary

Security risk management begins with an accurate understanding of assets, data flows, threats, vulnerabilities and consequences. Risk treatment may avoid, mitigate, transfer or accept risk, but acceptance must be informed and authorised. Asset classification should distinguish confidentiality, integrity, availability, privacy and criticality, while threat modelling should address conventional attacks and data-science-specific risks such as poisoning, model theft and re-identification.

Secure-by-design principles embed security and privacy in architecture. Defence in depth combines independent preventive, detective, corrective and recovery layers. Effective controls require both suitable design and evidence that they operate consistently. NIST CSF provides a flexible outcomes-based structure; NIST RMF provides a system lifecycle; ISO/IEC 27001 establishes an auditable ISMS; and CIS Controls provide prioritised practical safeguards. Their value increases when they are mapped thoughtfully rather than used as compliance checklists.

Finally, security is a governance and ethical responsibility as well as a technical function. Sensitive data platforms must address lawful purpose, privacy, fairness, accountability, resilience and human impact. Continuous monitoring, reassessment and tested recovery are essential because risk changes with technology, threats, business purpose and society.

Key Terms

Asset: Something valuable that requires protection.

Attack surface: The set of exposed interfaces, pathways and conditions through which compromise may occur.

Availability: The property that authorised users can access systems and information when required.

Confidentiality: Protection against unauthorised disclosure.

Control: A measure that modifies security or privacy risk.

Defence in depth: Use of multiple complementary security layers.

Impact: The magnitude of harm resulting from an adverse event.

Inherent risk: Risk before controls are applied.

Integrity: Protection of information and systems against unauthorised or improper alteration.

Least privilege: Restricting access to the minimum necessary for an authorised task.

Residual risk: Risk remaining after controls are implemented.

Risk appetite: The level and type of risk an organisation is willing to pursue or retain.

Risk treatment: A decision to avoid, mitigate, transfer or accept risk.

RTO: Target maximum time for restoring a service.

RPO: Target maximum tolerable age of recovered data.

Secure-by-design: Integrating security and privacy requirements into design from the beginning.

Threat: A potential cause of an unwanted security event.

Vulnerability: A weakness that may be exploited or triggered.

Zero trust: An approach that avoids implicit trust and evaluates access explicitly and continuously.

Review Questions

5 Short Answer Questions

1. Distinguish an asset, threat and vulnerability, giving one data-science example of each.
2. What is the difference between inherent risk and residual risk?
3. State the six functions of NIST CSF 2.0.
4. Why is pseudonymisation not the same as anonymisation?
5. Explain the purpose of RTO and RPO.

5 Long Answer Questions

1. Explain how an organisation should conduct an asset and data-classification assessment for a cloud analytics platform.
2. Compare NIST CSF, NIST RMF, ISO/IEC 27001 and CIS Controls in terms of purpose, scope and likely users.
3. Discuss defence in depth and secure-by-design, including their relationship to least privilege and zero trust.
4. Analyse the role of control effectiveness evidence in security assurance and audit.
5. Discuss the ethical and governance issues that arise when security controls are applied to health or student data.

3 Analytical / Application Questions

1. A research team stores restricted records in a shared cloud bucket and uses long-lived service credentials. Identify the principal assets, threats, vulnerabilities and recommended treatments. Justify your priorities.
2. Design a target security profile for a machine-learning API using the NIST CSF functions. Specify at least one measurable outcome for each function.
3. An organisation’s risk score falls from 20 to 8 after controls are implemented. Explain what this change does and does not prove, and identify the evidence required before accepting the residual risk.

Multiple Choice Questions with Answers

Question 1

Which statement best describes residual risk?

A. Risk that exists before any controls are applied

B. Risk remaining after controls have been implemented

C. Risk transferred entirely to an insurer

D. Risk that has been eliminated by compliance certification

Correct Answer: B. Risk remaining after controls have been implemented

Question 2

Which NIST CSF 2.0 function focuses on organisational context, risk strategy, roles and oversight?

A. Govern

B. Protect

C. Detect

D. Recover

Correct Answer: A. Govern

Question 3

A model-training dataset is altered so that the resulting model produces attacker-chosen classifications. Which threat is most directly illustrated?

A. Model inversion

B. Data poisoning

C. Denial of service

D. Credential rotation

Correct Answer: B. Data poisoning

Question 4

Which principle requires access to be granted only when explicitly permitted by an applicable rule?

A. Open design

B. Fail-safe defaults

C. Psychological acceptability

D. Economy of mechanism

Correct Answer: B. Fail-safe defaults

Question 5

What is the primary purpose of NIST RMF’s Authorization step?

A. To purchase cyber-insurance

B. To decide whether documented residual risk is acceptable

C. To classify every employee as a threat

D. To replace vulnerability scanning

Correct Answer: B. To decide whether documented residual risk is acceptable

Question 6

Which framework primarily specifies requirements for an information security management system that may be independently certified?

A. ISO/IEC 27001

B. CIS Controls

C. STRIDE

D. NIST CSF

Correct Answer: A. ISO/IEC 27001

Question 7

A recovery point objective of four hours means that, under the stated recovery design, the organisation targets losing no more than approximately:

A. Four minutes of service availability

B. Four hours of data changes

C. Four days of historical data

D. Four security controls

Correct Answer: B. Four hours of data changes

Question 8

Which control most directly improves accountability for automated data-processing jobs?

A. Using one shared service account for all jobs

B. Using distinct workload identities with auditable permissions

C. Disabling all logs to protect privacy

D. Granting every analyst administrator access

Correct Answer: B. Using distinct workload identities with auditable permissions

Question 9

What is a central limitation of multiplying ordinal likelihood and impact scores?

A. The result is always a monetary loss

B. The result is a probability with a known unit

C. The numerical result may create false precision

D. The method cannot compare any risks

Correct Answer: C. The numerical result may create false precision

Question 10

Which statement about security frameworks is most accurate?

A. A framework automatically guarantees that attacks cannot succeed

B. Frameworks eliminate the need for system-specific threat modelling

C. Frameworks provide structures that must be implemented, evidenced and interpreted in context

D. All frameworks contain identical controls and have identical purposes

Correct Answer: C. Frameworks provide structures that must be implemented, evidenced and interpreted in context