Cybersecurity, Privacy and Digital Resilience

Introduction

Digital transformation expands an organisation’s dependence on data, software, cloud services, connected devices, application programming interfaces (APIs), and external technology partners. The same technologies that improve customer experience and operational efficiency also increase exposure to fraud, disruption, surveillance, data loss, regulatory sanctions, and reputational damage. Cybersecurity is therefore not merely an information-technology control function. It is a strategic capability concerned with protecting value, sustaining operations, and enabling trustworthy innovation.

A transformation strategy is incomplete if it describes new digital capabilities without explaining how those capabilities will remain secure, lawful, available, and recoverable. Cyber risk should be considered during investment decisions, operating-model design, product development, procurement, and performance management. Privacy must be embedded into the design of data practices rather than added after systems are implemented. Resilience requires the organisation to anticipate disruption, withstand it, recover critical services, and learn from incidents.

This chapter integrates cyber risk management, zero-trust architecture, privacy by design, identity and access management, third-party risk, business continuity, disaster recovery, and incident response. It adopts a managerial and architectural perspective suitable for leaders responsible for digital transformation.

Learning objectives

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

1. Explain why cybersecurity and privacy are strategic dimensions of digital transformation.
2. Analyse cyber risk using threats, vulnerabilities, assets, impacts, and controls.
3. Apply zero-trust principles and identity-centred security thinking.
4. Design privacy safeguards across the data life cycle.
5. Evaluate identity management and third-party technology risk.
6. Distinguish business continuity, disaster recovery, crisis management, and incident response.
7. Use recovery objectives and risk metrics to support executive decisions.
8. Critically evaluate governance, ethics, regulation, artificial intelligence, and organisational culture in digital resilience.

1. Cyber risk as a transformation issue

Cybersecurity protects the confidentiality, integrity, and availability of information and services. Confidentiality limits information access to authorised parties; integrity protects accuracy, completeness, and trustworthy processing; availability ensures that authorised users can access systems and data when needed. These properties are often called the CIA triad, although modern programmes also address authenticity, accountability, safety, privacy, and resilience.

A digital transformation portfolio may include a customer mobile application, an enterprise resource planning platform, cloud analytics, robotic process automation, connected equipment, and an ecosystem of vendors. Each capability introduces dependencies and possible attack paths. For example, a compromised software supplier may provide attackers with privileged access; a poorly governed analytics lake may expose personal information; or an unavailable identity provider may prevent employees from accessing multiple critical services simultaneously.

A useful risk statement identifies an asset, a threat, a vulnerability, a consequence, and existing controls. A threat is a potential cause of harm, such as ransomware, credential theft, insider misuse, supply-chain compromise, or accidental disclosure. A vulnerability is a weakness that can be exploited, such as unpatched software, excessive privileges, weak authentication, or an untested recovery process. Risk is not identical to threat. A severe threat may create little organisational risk if exposure is low and controls are strong, while an ordinary weakness in a critical payment process may create substantial risk.

Risk assessment commonly combines qualitative judgement with quantitative estimates. A simplified expected-loss model is:

Here, ALE is annualised loss expectancy, SLE is single-loss expectancy in monetary units, and ARO is annual rate of occurrence. The model assumes that loss events can be reasonably estimated, that the average loss per event is meaningful, and that frequency is sufficiently stable for planning. It is a decision aid, not a prediction of actual future losses. SLE may include direct restoration costs, lost margin, legal expenses, notification costs, customer compensation, and credible reputational effects. ARO should not be presented with false precision when evidence is weak.

For example, if a critical service has an estimated loss of $400,000 per serious outage and an estimated frequency of 0.25 events per year, the ALE is $100,000 per year. A proposed control costing $60,000 annually may appear economically attractive, but the decision must also consider uncertainty, safety, regulatory obligations, correlated failures, and whether the control reduces probability, impact, or both.

Risk treatment can involve avoiding an activity, reducing likelihood or impact, transferring selected financial consequences, or accepting risk within approved limits. Senior management owns business risk; security teams advise, implement, monitor, and report. This distinction prevents cybersecurity from becoming an isolated technical responsibility.

2. Governance and strategic alignment

Effective governance connects business objectives with security outcomes. A board or executive committee should approve risk appetite, oversee material cyber exposures, ensure adequate resources, and test management’s preparedness. Management should establish accountability through an enterprise security strategy, policies, risk registers, control ownership, investment priorities, and escalation thresholds.

Common reference points include the NIST Cybersecurity Framework, ISO/IEC 27001 information-security management systems, CIS Controls, sector-specific regulations, and national critical-infrastructure requirements. These frameworks should not be treated as interchangeable compliance checklists. A framework organises thinking; it does not guarantee that an organisation is secure. The correct choice depends on industry, geography, risk profile, customer commitments, and organisational maturity.

A transformation business case should include security and resilience costs across the life cycle: architecture, secure development, testing, identity services, monitoring, training, vendor assurance, backup, recovery exercises, and eventual decommissioning. Security debt accumulates when projects defer these activities. Like technical debt, it may accelerate delivery initially but increases future cost and fragility.

Useful executive measures include the percentage of critical assets with known owners, privileged accounts protected by phishing-resistant authentication, critical vulnerabilities exceeding remediation deadlines, mean time to detect (MTTD), mean time to contain (MTTC), recovery-test success rate, and the proportion of high-risk suppliers with current assurance evidence. Metrics require definitions and context. A lower incident count can indicate improvement, but it can also indicate under-reporting or weak detection.

3. Zero-trust security architecture

Traditional perimeter security assumes that a trusted internal network can be separated from an untrusted external network. Cloud computing, remote work, mobile devices, APIs, and software-as-a-service weaken that boundary. Zero trust replaces broad implicit trust with continuous, context-sensitive verification.

Zero trust does not mean trusting nobody or repeatedly blocking legitimate work. It means that access is granted to a specific resource for a specific purpose, after evaluating identity, device condition, application, location, behaviour, and risk. Its central principles include:

• verify explicitly using strong identity and contextual signals;
• apply least privilege and limit access to what is necessary;
• assume breach and design for containment, monitoring, and rapid recovery;
• segment applications, workloads, data, and administrative functions;
• continuously reassess access rather than treating authentication as permanent trust.

A practical zero-trust architecture includes an identity provider, policy engine, policy administrator, policy enforcement points, endpoint and workload telemetry, security analytics, and protected resources. Access policies should be understandable and testable. For example, a finance analyst may access aggregated financial data from a managed device, but not raw customer identifiers from an unmanaged personal device. A privileged administrator may receive time-limited access only after strong authentication and approval.

Zero trust has organisational implications. It requires accurate asset inventories, reliable identity data, device management, application modernisation, network and data segmentation, logging, and processes for removing access promptly. It can fail when leaders purchase a product and label it “zero trust” without redesigning trust assumptions and governance.

4. Identity, authentication and access management

Identity is the control plane for modern digital operations. Identity and access management (IAM) establishes who or what is requesting access, what it is allowed to do, and how access is reviewed. It covers workforce identities, customers, partners, service accounts, machines, APIs, and increasingly autonomous software agents.

Important IAM practices include:

• a single authoritative identity life cycle linked to joiner, mover, and leaver events;
• multi-factor authentication, preferably using phishing-resistant methods such as hardware-backed credentials or passkeys for high-risk access;
• role-based access control where stable job responsibilities map to permissions;
• attribute-based access control where context such as location, device status, data classification, or transaction value affects decisions;
• privileged access management with approval, time limits, session recording, and emergency procedures;
• periodic access certification by accountable business owners;
• secrets management for keys, tokens, certificates, and service credentials;
• separation of duties for sensitive transactions.

Authentication establishes confidence in an identity; authorisation determines permitted actions; accounting and logging support traceability. These functions should not be conflated. A valid login does not justify unrestricted access.

A common transformation failure is the persistence of orphaned accounts and excessive privileges after organisational changes. Another is treating non-human identities as less important than employees. Service accounts often have long-lived credentials, broad permissions, and limited monitoring, making them attractive targets. Their ownership, rotation, purpose, and permitted scope should be documented.

5. Privacy by design and responsible data use

Privacy concerns how personal information is collected, used, shared, retained, secured, and deleted, as well as how individuals can exercise rights over it. Privacy is not equivalent to secrecy. An organisation may lawfully collect data yet still violate expectations through excessive surveillance, opaque profiling, discriminatory inference, or incompatible secondary use.

Privacy by design integrates privacy into architecture and operating processes from the beginning. Its practical principles include:

1. Purpose limitation: collect and use data for specified, legitimate purposes.
2. Data minimisation: collect only what is reasonably necessary.
3. Transparency: explain processing in accessible language.
4. User control: support applicable rights such as access, correction, deletion, objection, or portability.
5. Security: protect data through access controls, encryption, pseudonymisation, monitoring, and resilient storage.
6. Retention limitation: define and enforce retention periods.
7. Accountability: document decisions, responsibilities, assessments, and evidence.
8. Privacy-enhancing defaults: make the least intrusive option the normal setting.

A data life-cycle analysis asks: What data is collected? From whom? For what purpose? Where is it stored? Who can access it? With whom is it shared? How long is it retained? How will it be corrected, deleted, or returned? What happens when a vendor or system is retired?

Privacy impact assessments are especially valuable for large-scale monitoring, sensitive data, biometric systems, location services, behavioural profiling, and artificial intelligence. They should assess necessity, proportionality, foreseeable harms, bias, security, legal basis, affected stakeholders, and mitigations. Consent is not a universal solution: it may be invalid where there is an imbalance of power, and it does not excuse insecure processing.

Encryption reduces exposure but does not eliminate privacy risk. Encryption at rest protects stored data; encryption in transit protects communications; end-to-end encryption can limit intermediary access. Key management, access governance, recovery, and lawful operational requirements remain essential. Pseudonymised data may still be personal data if re-identification is reasonably possible.

6. Third-party and supply-chain risk

Transformation depends on cloud providers, payment processors, consultants, software libraries, managed service providers, logistics firms, and data brokers. A third party may process confidential information, operate a critical service, or introduce code into the organisation’s environment. Supplier risk therefore includes cyber risk, privacy risk, concentration risk, operational risk, geopolitical exposure, and exit risk.

A proportionate supplier-risk process includes:

• classification according to data sensitivity, service criticality, connectivity, substitutability, and concentration;
• pre-contract due diligence and evidence review;
• security and privacy requirements in contracts;
• defined notification periods for incidents and vulnerabilities;
• rights to audit or receive independent assurance reports;
• controls over subcontractors and data locations;
• recovery, portability, and termination provisions;
• ongoing monitoring and periodic reassessment.

A certification is useful evidence but is not proof that every control is effective in the organisation’s context. Contractual rights are also weak if the buyer lacks the resources to exercise them. Critical suppliers should participate in scenario exercises, and exit plans should identify alternative providers, data formats, dependencies, skills, and transition time.

Software supply-chain practices include software bills of materials, signed artefacts, dependency scanning, secure build pipelines, vulnerability disclosure, code review, and separation of development and production credentials. Open-source software can be highly reliable, but its risk depends on maintenance, provenance, dependency complexity, and response capability rather than on its licensing model alone.

7. Business continuity, disaster recovery and resilience

Business continuity management (BCM) maintains or restores priority business activities during disruption. Disaster recovery (DR) focuses more specifically on restoring technology, infrastructure, applications, and data. Crisis management coordinates leadership decisions, stakeholder communication, legal obligations, safety, and reputation. Incident response handles the detection, analysis, containment, eradication, and learning associated with a security event. These disciplines overlap but are not identical.

Business impact analysis identifies critical activities, dependencies, maximum tolerable disruption, resource requirements, and consequences over time. It should include people, facilities, technology, suppliers, data, communications, and manual workarounds. A service that appears non-critical in isolation may be essential because other processes depend on it.

Two central recovery measures are:

• Recovery time objective (RTO): the target time within which a service or process should be restored after disruption.
• Recovery point objective (RPO): the maximum tolerable period of data loss measured backward from the disruption.

If a payment service has an RTO of four hours and an RPO of fifteen minutes, the recovery design should aim to restore service within four hours and limit lost transactions or data to approximately the preceding fifteen minutes, subject to system and business assumptions. RTO and RPO are business requirements, not automatically achievable technical settings. Tighter objectives generally require greater investment, redundancy, testing, and operational complexity.

A recovery strategy may use backups, replication, high availability, alternate processing sites, immutable storage, manual procedures, or a different service provider. Backups must be protected from ransomware, tested for restoration, monitored for completeness, and governed by retention and privacy requirements. Replication alone is not always sufficient: corruption or malicious deletion may be replicated immediately.

Resilience is broader than recovery. It includes anticipation, resistance, adaptation, recovery, and improvement. A resilient organisation can continue a degraded but safe service, communicate honestly, prioritise scarce resources, and revise its design after learning from disruption.

8. Incident response and learning

An incident-response capability normally includes preparation; detection and analysis; containment; eradication; recovery; and post-incident activity. Preparation establishes plans, roles, contacts, legal guidance, forensic readiness, communications templates, evidence handling, and exercises. Detection uses logs, endpoint telemetry, network monitoring, threat intelligence, user reports, and anomaly analysis.

Containment may be short-term, such as isolating an endpoint, and long-term, such as applying compensating controls while rebuilding a system. Eradication removes malicious persistence and addresses the exploited weakness. Recovery restores trusted services in a controlled order and increases monitoring. Post-incident review should identify control, process, architectural, and cultural causes rather than assigning blame to the nearest individual.

An incident playbook should specify decision rights. Security teams may recommend isolation, but business and crisis leaders may need to balance containment against safety, customer obligations, or operational continuity. Legal and privacy specialists should assess notification duties, evidence preservation, contractual requirements, and cross-border implications. Communications should be accurate, timely, and coordinated; speculation can cause additional harm.

The distinction between event, alert, incident, and crisis supports proportional response. Not every alert is an incident, and not every incident becomes a crisis. Escalation criteria may include impact on safety, critical services, regulated data, national infrastructure, material financial exposure, or public confidence.

9. Artificial intelligence and emerging developments

Artificial intelligence creates both defensive opportunities and new attack surfaces. Security teams can use machine learning for anomaly detection, malware classification, triage, and threat intelligence, but models may generate false positives, miss novel attacks, or be manipulated by adversarial inputs. Generative AI can accelerate phishing, social engineering, malicious coding, and deepfake-enabled fraud. It can also assist defenders with investigation and knowledge retrieval, provided sensitive data is not improperly submitted to external services.

Organisations should govern AI systems through data classification, approved tools, human oversight, model access controls, prompt and output logging where appropriate, testing for bias and leakage, supply-chain review, and clearly defined accountability. An AI system with authority to execute transactions or change infrastructure requires stronger identity, least privilege, approval, monitoring, and rollback controls than a system that only drafts text.

Other important developments include passkeys, confidential computing, software supply-chain regulation, quantum-resistant cryptography research, operational technology security, privacy-enhancing computation, and increasing regulatory expectations for executive accountability. Emerging technology should be assessed through risk scenarios rather than adopted solely because it is fashionable.

10. Illustrative case: Meridian Health Network

Background

Meridian Health Network, a fictional regional healthcare provider, launched a digital transformation programme involving a patient mobile application, cloud analytics, connected diagnostic devices, and an outsourced appointment platform. The programme improved access and reduced administrative work, but its architecture contained multiple identity stores, legacy systems, and inconsistent supplier controls.

Problem

An employee received a convincing phishing message and surrendered credentials. The attacker accessed a cloud analytics environment through a legacy account, downloaded a large volume of patient records, and attempted to deploy ransomware. Backups existed, but several were connected to the production identity system. The appointment platform was unavailable, and the organisation could not immediately determine which data had been accessed.

Analysis

The incident was not caused only by one employee’s mistake. Contributing conditions included weak authentication for a privileged account, excessive access to analytics data, incomplete logging, insufficient segmentation, inadequate vendor assurance, and recovery designs that had not been tested against compromised credentials. Privacy risk arose because the data lake combined more information than was necessary for several analytical purposes.

The business impact analysis identified emergency care, medication records, and clinical communications as priority services. The appointment platform was important but could be operated temporarily through a controlled manual process. This prioritisation helped leaders allocate scarce technical and communications resources.

Approach and solution

Meridian implemented phishing-resistant multi-factor authentication for privileged and remote access, removed dormant accounts, and introduced privileged access management. It separated clinical, administrative, analytics, and backup environments. Data owners reviewed access by purpose, and the analytics team replaced unnecessary direct identifiers with appropriately governed pseudonymous values.

The organisation renegotiated supplier contracts to require incident notification, evidence of access control, subcontractor disclosure, recovery testing, and assistance with investigations. Immutable and offline-protected backups were introduced. The incident-response plan was exercised with clinical, legal, privacy, communications, and supplier representatives. A board dashboard was redesigned to show material risk, recovery-test results, unresolved high-risk findings, and time-bound remediation ownership.

Outcome

Meridian restored priority clinical services within its defined recovery objectives and completed the required investigation and notifications under applicable law. The organisation did not eliminate all cyber risk, but it reduced blast radius, improved visibility, clarified accountability, and strengthened confidence in its digital strategy.

Learning points

First, resilience is an enterprise design property, not an emergency IT project. Second, identity and segmentation are central to limiting attacker movement. Third, privacy minimisation reduces both regulatory exposure and the value of stolen data. Fourth, supplier dependencies must be tested rather than assumed. Finally, exercises should include business leaders and operational users because recovery decisions involve service priorities, ethics, and stakeholder trust.

11. Implementation roadmap for transformation leaders

A practical roadmap can proceed in stages:

Establish visibility. Inventory critical services, information assets, identities, applications, suppliers, data flows, and dependencies. Assign accountable owners and classify information and services.

Prioritise material risks. Use business impact analysis and threat-informed scenarios. Focus first on identity compromise, ransomware, critical supplier failure, data exposure, and loss of essential technology services.

Design target controls. Define zero-trust access principles, secure architecture patterns, privacy requirements, recovery objectives, logging standards, and supplier controls. Embed them in portfolio governance and procurement.

Implement foundational capabilities. Strengthen authentication, privileged access, vulnerability management, endpoint protection, segmentation, secure development, backup protection, incident monitoring, and privacy operations.

Exercise and measure. Test restoration, crisis decision-making, supplier response, communications, and manual workarounds. Measure outcomes rather than counting policies. Track exceptions with owners and expiry dates.

Learn and adapt. Use incidents, near misses, exercises, audit findings, and changes in the threat environment to update architecture and investment. Resilience is maintained through continuous improvement.

Challenges and limitations

No security control provides absolute protection. Strong authentication can still be undermined by social engineering, recovery weaknesses, or compromised endpoints. Encryption can create key-management and lawful-access challenges. Zero trust may be difficult in legacy environments and can create user friction if policies are poorly designed. Privacy requirements differ across jurisdictions, and data transfers may involve complex legal and operational constraints.

Quantitative risk estimates are uncertain because cyber events are dependent, adaptive, and sometimes rare. A risk register can create an illusion of control if it excludes systemic dependencies or treats compliance evidence as actual resilience. Excessive monitoring can damage employee trust and create privacy concerns. Security programmes can also reinforce inequity when automated fraud or access decisions produce biased outcomes.

Leaders should therefore combine technical controls with governance, skilled people, transparent decision-making, independent challenge, and a culture in which reporting mistakes and near misses is encouraged. The goal is not perfect prevention; it is trustworthy digital performance under adverse conditions.

Chapter Summary

Cybersecurity, privacy, and digital resilience are strategic capabilities that determine whether transformation creates sustainable value. Cyber risk should be expressed through assets, threats, vulnerabilities, impacts, and controls, with financial models used cautiously and assumptions made explicit. Governance aligns risk appetite, accountability, investment, and assurance.

Zero trust replaces implicit network trust with explicit, contextual, least-privilege access and continuous evaluation. IAM is the central control plane for employees, customers, machines, applications, and service accounts. Privacy by design embeds purpose limitation, minimisation, transparency, user control, retention, security, and accountability throughout the data life cycle.

Third-party risk requires proportional due diligence, contractual safeguards, continuous monitoring, resilience testing, and credible exit plans. Business continuity, disaster recovery, crisis management, and incident response are related but distinct disciplines. RTO and RPO translate business priorities into recovery requirements, while exercises and protected backups test whether those requirements are realistic.

Finally, resilience depends on learning. AI and other emerging technologies can improve defence but also introduce new attack, privacy, and governance risks. Effective transformation therefore treats security and privacy as design conditions, not post-implementation additions.

Key Terms

Cyber risk: The possibility that a cyber-related event will harm assets, objectives, people, or stakeholders.

Confidentiality: Protection against unauthorised disclosure of information.

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

Availability: The ability of authorised users to access systems and information when required.

Annualised loss expectancy (ALE): Estimated annual loss, calculated in the simplified model as single-loss expectancy multiplied by annual rate of occurrence.

Zero trust: A security approach that grants no implicit trust and continuously evaluates access to specific resources.

Least privilege: Limiting permissions to the minimum necessary for an authorised task.

Identity and access management (IAM): Governance and technology for identifying subjects and controlling their access.

Privileged access management: Controls for high-risk administrative accounts and sessions.

Multi-factor authentication: Authentication using two or more distinct factors.

Privacy by design: Integrating privacy safeguards into systems, processes, and products from inception.

Data minimisation: Collecting and processing no more personal data than is necessary for a defined purpose.

Pseudonymisation: Replacing direct identifiers with substitutes while retaining a controlled possibility of re-identification.

Third-party risk: Risk arising from suppliers, partners, platforms, or other external dependencies.

Business continuity management: Capability to sustain or restore priority activities during disruption.

Disaster recovery: Restoration of technology, applications, infrastructure, and data after disruption.

Recovery time objective (RTO): Target time for restoring a service or process.

Recovery point objective (RPO): Maximum tolerable period of data loss measured backward from disruption.

Incident response: Coordinated detection, containment, eradication, recovery, and learning following a security incident.

Digital resilience: Capacity to anticipate, withstand, recover from, and adapt to disruptive digital events.

Review Questions

Short Answer Questions

1. Distinguish confidentiality, integrity, and availability.
2. What is the purpose of an RTO and an RPO?
3. Explain the principle of least privilege.
4. Identify four principles of privacy by design.
5. Why is supplier exit planning important?

Long Answer Questions

1. Explain why cybersecurity should be governed as a business and transformation issue rather than solely as an IT function.
2. Describe the architecture and organisational implications of a zero-trust approach.
3. Discuss how IAM controls should address workforce, privileged, service, and customer identities.
4. Analyse how privacy by design can be integrated across the data life cycle.
5. Compare business continuity, disaster recovery, crisis management, and incident response.

Analytical / Application Questions

1. A cloud analytics supplier processes sensitive customer data and has access to production APIs. Design a proportionate third-party risk assessment and contract-control programme.
2. A ransomware attack has compromised production credentials, but backups appear available. Recommend a response and recovery sequence, explaining how identity, segmentation, evidence preservation, and RTO/RPO should influence decisions.
3. An organisation proposes an AI fraud-detection system that automatically blocks customer transactions. Evaluate the cybersecurity, privacy, fairness, governance, and resilience controls required before deployment.

Multiple Choice Questions with Answers

Question 1

Which statement best describes zero-trust security?

A. All users inside the corporate network are trusted by default.

B. Access is continuously evaluated and limited to specific resources and purposes.

C. Perimeter firewalls eliminate the need for identity management.

D. Users are denied access to all cloud services.

Correct Answer: B. Access is continuously evaluated and limited to specific resources and purposes.

Question 2

A serious incident has an estimated single-loss expectancy of $400,000 and an annual rate of occurrence of 0.25. Using ALE = SLE × ARO, what is the estimated ALE?

A. $100,000

B. $160,000

C. $400,000

D. $1,600,000

Correct Answer: A. $100,000

Question 3

Which practice most directly supports data minimisation?

A. Retaining all collected data indefinitely

B. Collecting only data necessary for a specified purpose

C. Sharing raw identifiers with every supplier

D. Using consent to justify every type of processing

Correct Answer: B. Collecting only data necessary for a specified purpose

Question 4

What does an RPO primarily specify?

A. The maximum acceptable time to restore service

B. The maximum tolerable amount of data loss measured in time

C. The number of employees needed for recovery

D. The annual probability of a cyberattack

Correct Answer: B. The maximum tolerable amount of data loss measured in time

Question 5

Which control most directly reduces the risk of orphaned accounts?

A. A joiner-mover-leaver identity life cycle

B. Increasing the number of network perimeter devices

C. Retaining former employees’ accounts for convenience

D. Removing all access reviews

Correct Answer: A. A joiner-mover-leaver identity life cycle

Question 6

Why can replication fail to provide adequate ransomware recovery?

A. Replication always prevents availability.

B. Malicious encryption or deletion may be replicated immediately.

C. Replication cannot copy any data.

D. Replication eliminates the need for backups.

Correct Answer: B. Malicious encryption or deletion may be replicated immediately.

Question 7

Which activity belongs primarily to incident-response preparation?

A. Deleting forensic evidence

B. Establishing roles, contacts, playbooks, and exercises

C. Publishing unverified speculation

D. Ignoring supplier dependencies

Correct Answer: B. Establishing roles, contacts, playbooks, and exercises

Question 8

Which statement about third-party assurance is most accurate?

A. A certification guarantees that every supplier control is effective.

B. A contract eliminates all supplier risk.

C. Assurance evidence should be evaluated in the organisation’s specific context.

D. Only the supplier’s price matters for risk assessment.

Correct Answer: C. Assurance evidence should be evaluated in the organisation’s specific context.

Question 9

A service has an RTO of four hours and an RPO of fifteen minutes. Which interpretation is correct?

A. It must never experience an outage.

B. It should be restored within four hours with approximately no more than fifteen minutes of data loss.

C. It may lose four hours of data but must recover in fifteen minutes.

D. It must be backed up exactly four times per hour regardless of business need.

Correct Answer: B. It should be restored within four hours with approximately no more than fifteen minutes of data loss.

Question 10

Which principle is central to privacy by design?

A. Privacy is considered only after deployment.

B. Maximum data collection is always preferred.

C. Privacy safeguards are integrated from the beginning of system design.

D. Security controls replace the need for transparency.

Correct Answer: C. Privacy safeguards are integrated from the beginning of system design.