11. Cloud Security, Compliance and Ethical Governance

Introduction and Context

Cloud deployment changes the location, ownership, and operating model of information technology. Applications, data, identities, networks, and security controls are distributed across provider-managed and customer-managed environments. This distribution creates significant advantages: elastic capacity, rapid provisioning, managed services, global reach, and operational automation. It also creates a security reality in which responsibility is shared rather than transferred entirely to a cloud provider.

A cloud customer may select secure infrastructure, yet still expose data through an incorrectly configured storage bucket, an excessive identity permission, an unprotected application programming interface, or an inadequately monitored workload. Security therefore depends not only on technical controls but also on governance, accountability, legal interpretation, professional judgement, and ethical administration.

For full-stack developers and cloud engineers, security is not a final testing activity. It begins during architectural design and continues through coding, deployment, monitoring, incident response, and decommissioning. This chapter examines cloud security as a strategic discipline, integrating defense in depth, encryption, vulnerability management, threat modeling, security posture management, compliance, privacy, data sovereignty, auditability, and responsible governance across AWS, Microsoft Azure, and Google Cloud.

Learning Objectives

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

1. Explain the shared-responsibility model and its implications for cloud security.

2. Design a defense-in-depth approach for cloud-hosted applications.

3. Apply threat modeling, vulnerability management, encryption, and identity controls.

4. Distinguish compliance obligations from broader security and privacy responsibilities.

5. Evaluate ISO 27001, SOC 2, PCI DSS, and GDPR in a cloud context.

6. Analyse data sovereignty, auditability, ethical administration, and third-party risk.

7. Develop a practical cloud incident-response strategy.

8. Make defensible managerial and technical decisions under security, cost, usability, and legal constraints.

The Cloud Security Responsibility Model

The shared-responsibility model is the starting point for cloud governance. The provider is generally responsible for security of the cloud: physical facilities, hardware, core networking, and the managed platform. The customer remains responsible for security in the cloud, including identities, data, application configuration, access permissions, operating systems in infrastructure-as-a-service environments, and the secure use of provider services.

The division changes according to the service model. In infrastructure as a service, the customer normally manages guest operating systems, applications, patches, identities, and data. In platform as a service, the provider manages more of the runtime and infrastructure, while the customer remains responsible for code, data, access control, and configuration. In software as a service, the provider operates most technical components, but the customer still controls users, business data, retention decisions, integrations, and organizational use.

The model is not a legal contract by itself. Service agreements, provider documentation, certifications, regional offerings, and organizational policies determine the precise allocation of duties. A frequent failure occurs when an organization assumes that a certified provider automatically makes its own application compliant. Provider certifications provide evidence about the provider’s controls; they do not certify every customer workload.

Security governance should therefore document, for each asset and control, the responsible party, evidence required, review frequency, and escalation route. A responsibility matrix can include identity lifecycle, encryption keys, patching, backup restoration, logging, vulnerability remediation, privacy requests, and incident notification.

Defense in Depth as an Architectural Strategy

Defense in depth uses multiple, partially independent safeguards so that failure of one control does not immediately produce compromise. It is more than placing several firewalls around a system. Effective defense in depth addresses people, process, technology, and recovery.

At the identity layer, organizations use centralized identity providers, multifactor authentication, role-based access control, short-lived credentials, privileged-access management, and periodic access reviews. At the network layer, private subnets, segmentation, security groups, network firewalls, web application firewalls, and service endpoints reduce unnecessary exposure. At the application layer, secure coding, input validation, dependency management, authentication, authorization, and secrets protection limit exploitable weaknesses.

At the data layer, classification, encryption, tokenization, masking, retention controls, backups, and data-loss prevention reduce the impact of unauthorized access. At the operational layer, vulnerability scanning, configuration assessment, centralized logging, alerting, threat detection, and tested incident procedures improve detection and response. At the resilience layer, immutable backups, multi-zone design, recovery exercises, and documented recovery objectives limit business damage.

Layering must not become an excuse for poorly configured controls. Ten weak controls do not necessarily equal one strong control. Each layer should have a defined purpose, known failure modes, measurable coverage, and an owner. Security architecture should also consider independence: storing both primary data and backups in the same compromised account may provide apparent redundancy without genuine recovery protection.

Identity, Access, and the Human Control Plane

Cloud identity is often the most important security boundary. A leaked password or access key can bypass physical perimeter controls and reach resources globally. Identity and access management therefore follows least privilege: a principal receives only the permissions needed for a defined task, for the shortest practical period.

Practical controls include multifactor authentication for human users, federated single sign-on, separate administrative accounts, role-based permissions, workload identities instead of embedded keys, just-in-time elevation, approval workflows, and automatic removal of dormant access. Policies should distinguish read, write, delete, administrative, and billing privileges. Production access should be more restricted than development access, and emergency access should be logged and reviewed.

Least privilege is not achieved by granting broad permissions and hoping that users behave responsibly. It requires analysing actual access patterns, removing unused permissions, testing denial conditions, and reviewing service-to-service trust relationships. Developers should avoid storing credentials in source repositories, container images, or configuration files. Secrets managers and managed identity services reduce exposure, although their own access policies must be governed carefully.

Encryption, Key Management, and Data Protection

Encryption transforms readable information into ciphertext using a cryptographic algorithm and a key. Encryption at rest protects stored data, while encryption in transit protects data moving between clients, services, and regions. Application-level or client-side encryption may protect data even from some infrastructure administrators, but it increases key-management responsibility and may affect search, analytics, and recovery.

Transport security normally relies on current versions of TLS, valid certificates, strong cipher configuration, and verification of endpoint identity. Internal traffic should not automatically be considered safe merely because it remains within a cloud virtual network. Service-to-service communication should be authenticated and, where risk justifies it, encrypted.

Encryption at rest is valuable but not sufficient. If an attacker obtains an application’s decryption permission, encrypted storage may be readable. Key management therefore involves generation, storage, rotation, access separation, backup, revocation, and audit. Managed key services offered by major cloud providers can simplify these functions, while hardware security modules may be appropriate for highly sensitive or regulated workloads.

Organizations must decide who controls keys, where keys are located, how recovery works, and what happens if a provider account is suspended. Customer-managed keys can improve control and auditability but create operational risks. A lost key can make data permanently inaccessible; an over-permissive key policy can undermine confidentiality. Key decisions should be connected to data classification, legal requirements, recovery objectives, and threat assumptions.

Threat Modeling and Secure Design

Threat modeling is a structured method for identifying what can go wrong before implementation. It is especially valuable in cloud systems because applications often depend on managed services, external identity providers, third-party packages, event queues, APIs, and cross-account or cross-subscription access.

A useful process begins by defining system scope and business objectives. The team then identifies assets, trust boundaries, actors, data flows, entry points, and dependencies. Threats can be classified using approaches such as spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. The team estimates likelihood and impact, selects mitigations, assigns owners, and records residual risk.

For example, a serverless order system may contain a public API, an identity service, a function layer, an order database, a payment provider, and an administrative dashboard. Threat modeling may reveal risks including forged tokens, injection through order fields, excessive function permissions, replayed payment messages, unvalidated webhooks, and sensitive data in logs. Mitigations may include token validation, schema enforcement, narrowly scoped roles, idempotency keys, signed webhook verification, and log redaction.

Threat modeling is not a one-time document. New data flows, provider services, business features, and regulatory requirements should trigger reassessment. Its value lies in making assumptions visible and connecting design choices to explicit risks.

Vulnerability and Configuration Management

Vulnerability management is a lifecycle rather than a scanning event. It includes asset discovery, identification, prioritization, remediation, verification, and reporting. Cloud environments complicate asset discovery because resources may be created dynamically through infrastructure as code, temporary environments, containers, functions, and automated pipelines.

Prioritization should consider exploitability, exposure, asset criticality, data sensitivity, compensating controls, and business impact. A severe vulnerability in an isolated development account may be less urgent than a moderate vulnerability in an internet-facing payment service. However, risk ratings must not be manipulated simply to avoid remediation deadlines.

Configuration management addresses insecure settings such as public storage, unrestricted administrative ports, disabled logging, excessive permissions, weak encryption policies, and unapproved regions. Cloud security posture management tools can continuously compare environments with organizational policies and recognized benchmarks. They assist with visibility, but automated findings require human interpretation. A tool may report a technically noncompliant setting that is justified by a documented exception, or fail to understand a business dependency.

Infrastructure as code improves consistency and reviewability. Security checks can be placed in version control and deployment pipelines to detect risky configurations before release. Preventive controls are preferable to discovering the same misconfiguration repeatedly after deployment. Exceptions should have an owner, justification, expiry date, compensating controls, and approval authority.

Monitoring, Auditability, and Incident Response

Security monitoring depends on trustworthy evidence. Logs should record authentication events, administrative actions, configuration changes, network activity, application errors, data access where feasible, and security alerts. Centralizing logs in a protected account or security project reduces the risk that an attacker can erase evidence. Time synchronization, retention rules, integrity protection, and restricted log access support investigations.

Auditability means more than collecting large volumes of logs. Evidence must answer who performed an action, what changed, when it occurred, from where, through which identity, and whether the action was authorized. Excessive collection may create privacy risk and unnecessary cost. Logging should be proportionate, protected, searchable, and connected to investigation objectives.

Incident response normally includes preparation, detection and analysis, containment, eradication, recovery, and lessons learned. Preparation includes contact lists, playbooks, forensic access, backups, legal coordination, provider escalation, and exercises. During detection, the team validates alerts and establishes scope without destroying evidence. Containment may involve disabling credentials, isolating workloads, blocking indicators, or restricting network paths. Eradication removes persistence and root causes; recovery restores trusted operations while maintaining heightened monitoring.

Cloud incidents require special planning. The customer may not control physical evidence or provider infrastructure. Investigators must understand provider logging limits, retention periods, snapshot procedures, regional constraints, and chain-of-custody requirements. Notification obligations may be triggered by the type of data affected, the jurisdiction of individuals, contractual commitments, or sector-specific regulation. Legal and privacy teams should participate early rather than after technical decisions have already been made.

Compliance, Privacy, and Data Sovereignty

Compliance is the demonstrable fulfilment of applicable legal, contractual, regulatory, and internal requirements. It is narrower than security. A compliant organization can still experience a breach, and a technically secure control may not satisfy a particular legal obligation. Compliance should therefore be treated as a risk and accountability system, not as a certificate-collection exercise.

ISO/IEC 27001 specifies requirements for an information security management system. Its emphasis is organizational: risk assessment, governance, control selection, continual improvement, leadership responsibility, and documented evidence. It does not prescribe one architecture or guarantee that every system is secure.

SOC 2 is an attestation framework concerning controls relevant to trust-service criteria such as security, availability, processing integrity, confidentiality, and privacy. Customers should examine the scope, period, system description, control exceptions, and complementary customer controls rather than relying on the existence of a SOC report alone.

PCI DSS applies to entities that store, process, or transmit payment card data, or that can affect the security of the cardholder-data environment. Scope reduction, segmentation, strong access control, vulnerability management, monitoring, and secure development are important, but outsourcing payment processing does not automatically eliminate all responsibilities.

GDPR establishes obligations relating to the processing of personal data of individuals within its territorial scope in applicable circumstances. Important concepts include lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity and confidentiality, and accountability. Organizations must determine roles such as controller and processor, establish a lawful basis, manage data-subject rights, control processors, assess transfers, and report certain breaches within prescribed time requirements. Technical controls support these obligations but cannot replace legal analysis.

Data sovereignty concerns the authority of a jurisdiction over data, systems, or service providers. Data residency refers more specifically to where data is stored or processed. These concepts are related but not identical. A workload stored in a chosen region may still be subject to laws affecting the provider or corporate group elsewhere. Architecture decisions should examine primary data, replicas, backups, logs, support access, encryption keys, subprocessors, and disaster-recovery regions.

Ethical Governance and Responsible Administration

Cloud administrators possess extensive power. They may access confidential records, change production systems, alter audit trails, or create surveillance capabilities. Ethical administration requires authorization, necessity, proportionality, confidentiality, competence, and accountability.

An administrator should not inspect customer content merely because technical access exists. Break-glass access should be exceptional, time-limited, approved where possible, logged, and reviewed. Monitoring should have a legitimate purpose and should not collect personal information indiscriminately. Security teams must also avoid discriminatory outcomes when automated detection or risk scoring affects employees or customers.

Responsible governance includes separation of duties, transparent policies, documented decisions, conflict-of-interest management, accessible reporting channels, and protection for good-faith security research. Organizations should not conceal material incidents, suppress evidence, or blame individuals for systemic weaknesses without examining training, workload, incentives, and design failures.

Strategic Choices and Organizational Implementation

Senior decision-makers must balance security with cost, speed, resilience, privacy, and usability. Maximum restriction may undermine productivity and encourage shadow IT; excessive convenience may enlarge attack surfaces. A mature strategy establishes risk appetite and uses it to guide architecture, investment, exceptions, and escalation.

Implementation can proceed through a risk-based programme. First, inventory workloads, data, identities, dependencies, and regulatory obligations. Second, classify information and identify critical services. Third, establish baseline controls for identity, logging, encryption, vulnerability management, backup, and incident response. Fourth, integrate security into architecture review, source control, continuous integration, infrastructure as code, and release approval. Fifth, measure outcomes and improve controls through exercises, audits, incidents, and changing threats.

Useful measures include the proportion of assets inventoried, multifactor authentication coverage, privileged-access review completion, mean time to remediate prioritized vulnerabilities, logging coverage, backup restoration success, age of unresolved exceptions, and time to detect and contain incidents. Metrics should illuminate risk rather than reward superficial activity. For example, the number of alerts closed is less meaningful than the percentage of critical systems with tested detection and recovery capabilities.

Illustrative Case Study: A Regional Health Platform

Background

MedAxis, a fictional health-technology company, operates a cloud platform used by clinics to schedule appointments and exchange selected patient information. It uses a managed database, containerized application services, object storage, an identity provider, and an analytics environment. The company plans to expand into another jurisdiction and must satisfy customer security reviews and privacy obligations.

Situation and Problem

An assessment finds that development and production share an account structure, several engineers use long-lived access keys, object storage permits broad internal access, application logs contain unmasked identifiers, and backups are replicated automatically to a region not approved by some customers. The company has a SOC 2 report from a major provider but no formal internal security-management system. A recent dependency vulnerability also remained unpatched for several weeks.

Analysis

The problems are interconnected. Shared environments increase the impact of compromised credentials. Long-lived keys weaken identity governance. Broad storage permissions create unnecessary disclosure risk. Logging personal identifiers conflicts with minimization and increases incident scope. Unapproved replication creates a sovereignty and contractual issue. The provider’s SOC 2 report does not demonstrate that MedAxis configured its own environment correctly. Finally, the delayed patch indicates that vulnerability ownership and prioritization are unclear.

Approach and Strategy

MedAxis establishes separate production and non-production accounts or subscriptions, centralizes identity federation, requires multifactor authentication, and replaces engineer keys with short-lived roles and workload identities. It applies least privilege to containers and storage, blocks public access by policy, and uses private service connectivity where appropriate.

The company classifies health data, encrypts databases, backups, and object storage, and places key administration under a separate security function. Replication regions are reviewed with legal counsel and customers. Logs are centralized, protected from alteration, and redesigned to exclude unnecessary patient identifiers. A threat model is created for the appointment and data-exchange workflows.

Security checks are added to infrastructure-as-code pipelines. A posture-management service identifies drift, while vulnerability management assigns owners and remediation targets based on exposure and criticality. MedAxis writes an incident playbook covering credential compromise, data disclosure, provider escalation, regulatory assessment, and customer communication. It then conducts a restoration exercise and a simulated breach exercise.

Outcome

The company reduces unnecessary privileged access, gains evidence for customer assessments, detects configuration drift earlier, and can demonstrate where regulated data is stored and replicated. It does not claim that certification eliminates risk. Instead, it maintains a control register, tracks exceptions, reviews suppliers, and reports residual risks to management.

Learning Points

The case illustrates five principles. First, cloud-provider assurance does not replace customer governance. Second, identity and configuration weaknesses can be more consequential than sophisticated attacks. Third, privacy and sovereignty must be designed into architecture. Fourth, audit evidence should support actual accountability rather than paperwork alone. Finally, security maturity depends on repeatable processes, ownership, testing, and continuous improvement.

Challenges, Limitations, and Common Mistakes

Cloud security programmes commonly fail through misconfiguration, fragmented ownership, excessive permissions, weak asset inventories, insufficient logging, untested backups, and informal exception handling. Multi-cloud environments introduce inconsistent terminology, duplicated tools, differing service capabilities, and complicated identity relationships. Managed services may hide important operational details, while rapid deployment can outpace review processes.

Automation also has limits. A policy engine can block a deployment but may not understand a legitimate business requirement. An artificial-intelligence-based detector may generate false positives, overlook novel attacks, or expose sensitive log data to an external service. Automated remediation can cause outages if context is ignored. Human review remains necessary for high-impact actions.

Another mistake is treating compliance deadlines as the security strategy. Controls should be selected because they reduce material risk and support obligations, not merely because they appear in an audit checklist. Conversely, technically excellent security that ignores data-subject rights, retention, jurisdiction, or transparency is not responsible governance.

Current Developments and Best Practices

Cloud-native security is increasingly integrated into development and operations through DevSecOps. Software composition analysis, static and dynamic testing, secrets detection, signed artifacts, software bills of materials, and provenance controls help organizations understand what is deployed. Runtime protection, identity-aware proxies, zero-trust principles, confidential-computing techniques, and centralized policy-as-code are also expanding.

Organizations adopting artificial intelligence must examine model supply chains, training-data rights, prompt and data leakage, insecure plugins, excessive agent permissions, and the reliability of automated decisions. AI can assist with alert triage, threat summarization, control mapping, and anomaly detection, but its outputs require validation and governance.

Sound practice includes:

• establish clear ownership under the shared-responsibility model;
• classify data and map its complete lifecycle;
• enforce multifactor authentication and least privilege;
• use short-lived workload identities and managed secrets;
• encrypt data and govern keys deliberately;
• treat infrastructure as code and scan it before deployment;
• centralize, protect, and regularly test audit logging;
• maintain tested, isolated backups and recovery procedures;
• threat-model significant architectural changes;
• manage exceptions with expiry and compensating controls;
• review provider, processor, and subprocessor risk;
• conduct incident exercises involving technical, legal, privacy, and executive teams; and
• measure security outcomes, not merely tool activity.

Chapter Summary

Cloud security is a shared and continuously governed responsibility. Defense in depth combines identity, network, application, data, monitoring, and recovery controls so that no single failure determines the outcome. Threat modeling anticipates abuse cases, while vulnerability and posture management control weaknesses across dynamic environments. Encryption protects data, but key governance, access control, and recovery determine its practical value.

Compliance frameworks provide structured expectations and evidence, but certifications do not automatically make a customer workload secure or lawful. ISO 27001 emphasizes an information security management system, SOC 2 evaluates controls against trust-service criteria, PCI DSS addresses payment-card environments, and GDPR governs applicable personal-data processing. Privacy, data sovereignty, auditability, and ethical administration must be integrated into architecture and operations. Mature organizations combine technical safeguards with accountable leadership, tested incident response, measurable improvement, and responsible decision-making.

Key Terms

Shared-responsibility model: Allocation of security duties between a cloud provider and its customer.

Defense in depth: Use of multiple complementary controls to reduce dependence on any single safeguard.

Least privilege: Granting only the access necessary for an authorized task.

Multifactor authentication: Authentication requiring two or more independent evidence factors.

Threat modeling: Structured identification and treatment of threats during system design.

Vulnerability management: The lifecycle of discovering, prioritizing, remediating, and verifying weaknesses.

Security posture management: Continuous assessment of cloud assets and configurations against security policies.

Encryption at rest: Protection of stored data using cryptographic transformation.

Encryption in transit: Protection of data while moving between systems or networks.

Key management: Governance of cryptographic-key creation, use, storage, rotation, and recovery.

Data sovereignty: The effect of jurisdictional authority over data or systems.

Data residency: The physical or logical location where data is stored or processed.

Auditability: The ability to produce reliable evidence about actions, changes, and authorization.

Incident response: Coordinated activities for detecting, containing, investigating, recovering from, and learning from security incidents.

ISO 27001: A standard specifying requirements for an information security management system.

SOC 2: An attestation framework concerning controls associated with specified trust-service criteria.

PCI DSS: Security requirements for environments handling payment-card data.

GDPR: European Union data-protection regulation governing applicable personal-data processing.

Break-glass access: Exceptional emergency access subject to strict control, logging, and review.

Infrastructure as code: Definition and management of infrastructure through version-controlled machine-readable files.

Review Questions

Short Answer Questions

1. Explain why cloud-provider certification does not automatically make a customer application compliant.

2. What is the purpose of defense in depth?

3. Distinguish data sovereignty from data residency.

4. Why are short-lived workload identities preferable to embedded access keys?

5. Identify the main phases of incident response.

Long Answer Questions

1. Analyse the shared-responsibility model across infrastructure, platform, and software as a service.

2. Explain how encryption, key management, and identity controls operate together to protect cloud data.

3. Describe a complete threat-modeling process for a cloud-native application.

4. Compare ISO 27001, SOC 2, PCI DSS, and GDPR in terms of purpose and organizational implications.

5. Develop a governance programme for a multi-cloud organization handling sensitive personal data.

Analytical / Application Questions

1. A storage service is encrypted but accessible to every authenticated employee. Evaluate the security posture and recommend controls.

2. A company discovers that backup replicas containing personal data are stored in an unapproved jurisdiction. Identify the technical, legal, and governance actions required.

3. During an incident, an administrator proposes deleting suspicious logs to reduce storage costs. Assess the proposal ethically and operationally, and design a better response.

22. Multiple Choice Questions with Answers

Question 1

Under the shared-responsibility model, which activity normally remains the customer’s responsibility in a managed platform service?

A. Maintaining the provider’s physical data-centre security

B. Replacing failed provider-owned hardware

C. Managing application data and access permissions

D. Patching the provider’s hypervisor

Correct Answer: C. Managing application data and access permissions

Question 2

Which control most directly reduces the risk created by a compromised long-lived administrator key?

A. Increasing log-retention duration

B. Using federated, multifactor and short-lived privileged access

C. Encrypting only archived backups

D. Adding another public IP address

Correct Answer: B. Using federated, multifactor and short-lived privileged access

Question 3

Why is encryption alone insufficient to protect cloud data?

A. Encrypted data cannot be backed up

B. Encryption eliminates the need for access control

C. Anyone with decryption authority may still read the data

D. Encryption applies only to network traffic

Correct Answer: C. Anyone with decryption authority may still read the data

Question 4

In threat modeling, a trust boundary primarily identifies:

A. The financial cost of a cloud service

B. A point where data or authority crosses between different levels of trust

C. The geographic location of a data centre

D. The age of an operating system

Correct Answer: B. A point where data or authority crosses between different levels of trust

Question 5

Which statement best describes SOC 2?

A. A universal encryption algorithm

B. An attestation framework concerning specified trust-service controls

C. A law governing all personal data in the world

D. A replacement for customer access reviews

Correct Answer: B. An attestation framework concerning specified trust-service controls

Question 6

A cloud security posture tool reports that a storage bucket is publicly accessible. What should happen first?

A. Ignore the finding because the provider operates the storage service

B. Delete all storage immediately

C. Validate business need and exposure, then remediate or document an approved exception

D. Disable all organizational logging

Correct Answer: C. Validate business need and exposure, then remediate or document an approved exception

Question 7

Which practice best supports auditability?

A. Allowing administrators to edit centralized logs freely

B. Recording authorized actions with identity, time, change, and source information

C. Collecting every possible data field without retention limits

D. Keeping logs only on the affected production server

Correct Answer: B. Recording authorized actions with identity, time, change, and source information

Question 8

A company’s backup is in a different region from its primary workload. Which issue requires specific governance review?

A. Whether the backup has any relationship to recovery objectives or jurisdiction

B. Whether the application uses a graphical interface

C. Whether developers prefer one programming language

D. Whether the primary workload has a brand logo

Correct Answer: A. Whether the backup has any relationship to recovery objectives or jurisdiction

Question 9

Which action is an example of ethical break-glass administration?

A. Using emergency privileges for routine convenience without logging

B. Sharing a permanent root password with a team

C. Granting time-limited emergency access, recording it, and reviewing it afterward

D. Inspecting customer content whenever technical access exists

Correct Answer: C. Granting time-limited emergency access, recording it, and reviewing it afterward

Question 10

What is the strongest reason to test backup restoration rather than merely confirm that backups exist?

A. Existence does not demonstrate that data can be recovered reliably within required objectives

B. Testing backups removes the need for encryption

C. Restoration tests automatically satisfy GDPR

D. Backups are useful only for audit reports

Correct Answer: A. Existence does not demonstrate that data can be recovered reliably within required objectives