Chapter 4 — Data Privacy for Cloud Infrastructure and Services

Data privacy is the human-rights-anchored dimension of cloud security. Where security broadly protects systems and data from harm, privacy specifically protects individuals from inappropriate use of their personal data. The two overlap substantially but are not identical — a system can be secure but privacy-violating, or privacy-respecting but insecure. This chapter focuses sharply on the data-privacy dimension as it applies to cloud computing: the lifecycle of data in cloud, the controls that protect confidentiality and integrity, the threats data faces, the specific protection techniques (encryption, redaction, tokenization, obfuscation, PKI, key management), the assurance of deletion, the retention and archiving procedures for tenant data, and the data-protection plans and strategies that organise everything into operational practice.

4.1 Cloud-based information life cycle

Data lifecycle

The data lifecycle is the sequence of stages through which data passes from initial creation or collection through processing, storage, sharing, archiving, and eventual deletion, with each stage having distinct privacy and security characteristics, controls, and risks.

In cloud environments, data flows through these stages across services and across organisational boundaries. Understanding the lifecycle is foundational to protecting data appropriately at each stage.

Stages of the cloud data lifecycle

Create. Data is created or collected. Web form submissions, API calls, sensor readings, uploaded files, system-generated logs, user actions captured. The point of creation establishes initial accountability — the data is now in the organisation's care.

Store. Data placed in persistent storage. Databases, object storage, file systems, caches. The decision of where to store has security implications — encryption defaults, access controls, redundancy.

Use. Data processed for its intended purpose. Application logic operates on the data; users view and modify it; analytics derive insights.

Share. Data transmitted to other systems, organisations, or individuals. APIs, file exchanges, reports, integrations. Each share is a new accountability boundary.

Archive. Data moved to long-term storage. Lower-cost storage with less-frequent access. Often subject to retention requirements rather than active use.

Destroy. Data deleted. Verifying deletion is non-trivial in distributed cloud environments.

Lifecycle controls

At each stage, specific controls apply:

Stage	Key controls
Create	Input validation, classification, consent
Store	Encryption at rest, access controls, backup
Use	Access controls, audit logging, masking
Share	Encryption in transit, recipient validation, DLP
Archive	Long-term encryption, retention policies
Destroy	Verified deletion, cryptographic shredding

Data classification

Data classification is the process of categorising data according to its sensitivity, regulatory requirements, business value, and other characteristics, with each classification determining the controls that apply throughout the data lifecycle, providing a foundation for proportional protection.

Common classifications:

Public. Information freely shareable. Press releases, marketing material, public datasets.

Internal. Information for use within the organisation. Employee directories, internal procedures.

Confidential. Information whose unauthorised disclosure would harm the organisation. Customer lists, financial projections.

Restricted / Highly Confidential. Information whose disclosure would cause significant harm. Personal data of customers, regulated financial data, trade secrets.

For Nepali banks under NRB directives, additional classifications apply:

• Customer-identifiable financial data.
• Material non-public information.
• Authentication credentials and cryptographic material.

Classification in practice

Effective classification:

• Built into data-creation workflows.
• Persists with the data (metadata tagging).
• Drives automated controls.
• Reviewed and updated as appropriate.
• Trained into staff making classification decisions.

Cloud platforms support classification:

• AWS Macie classifies S3 data automatically.
• Azure Purview / Microsoft Purview for unified data governance.
• GCP Data Catalog with sensitivity tagging.

Personal data — special category

Within sensitive classifications, personal data has specific legal status under privacy laws.

Personal data = any information relating to an identified or identifiable natural person.

Special categories (often called "sensitive personal data"): health information, biometric data, financial details, religious beliefs, political opinions, sexual orientation, genetic data, racial or ethnic origin. These warrant heightened protection in most privacy regimes.

For Nepali context:

• Privacy Act 2075 specifies protection requirements for personal information.
• Sectoral regulations (NRB, NTA, MOHP) layer additional requirements.
• Constitutional Article 28 establishes privacy as fundamental right.

Data sovereignty and residency

Data sovereignty is the principle that data is subject to the laws of the country in which it is physically located, with implications for which government authorities can compel access, which regulations apply, and what legal protections data subjects have.

Data residency is the related operational concept of where data physically resides, often determined by the geographic region where cloud resources are provisioned.

For Nepali enterprises using cloud:

• AWS Mumbai (ap-south-1) stores data on Indian soil; subject to Indian law for many purposes.
• Azure Central India / South India similar.
• NRB directives specify some data must be accessible from Nepal and have specific arrangements for cross-border transfer.
• Some regulatory data may need to remain on Nepali soil.

The choice of cloud region has both operational and legal implications.

4.2 Data protection for confidentiality and integrity

The classical CIA properties applied specifically to data.

Confidentiality controls

Encryption at rest. Data stored in encrypted form. All major cloud providers support encryption by default for most services.

Encryption in transit. TLS for everything moving across networks.

Access controls. Who can read the data. IAM-based authorisation.

Network isolation. Data accessible only from authorised network locations.

Data masking. Showing only what users need to see (last 4 digits of card number rather than full number).

Tokenization. Replacing sensitive data with non-sensitive tokens.

Field-level encryption. Specific fields encrypted with different keys than the overall storage.

Confidential computing. Encryption during processing, not just at rest and in transit. Emerging capability — AWS Nitro Enclaves, Azure Confidential VMs, Google Confidential VMs.

Integrity controls

Cryptographic hashes. Object hashes published; tampering detectable.

Digital signatures. Cryptographically signed data; signature verifies origin and integrity.

Object versioning. Multiple versions retained; can revert to known-good.

Backup and replication. Multiple copies; corruption in one detectable through inconsistency with others.

Access controls. Limiting who can modify data.

Audit logs. Recording who changed what when.

Write-once-read-many (WORM) storage. S3 Object Lock, Azure Immutable Storage. Data cannot be modified or deleted within retention period.

Defence in depth for data

Multiple layers protect data:

Application controls
       ↓
Database controls
       ↓
Storage encryption
       ↓
Disk encryption
       ↓
Physical security

Each layer adds protection. Compromise of one layer alone shouldn't expose data; multiple layers must fail.

Data protection by service

Block storage (EBS, Managed Disks, Persistent Disk):

• Encryption at rest by default with provider keys.
• Customer-managed keys via KMS.
• Snapshot encryption.
• Access via IAM.

Object storage (S3, Blob, Cloud Storage):

• Encryption at rest by default.
• Bucket policies and ACLs for access control.
• Versioning for accidental deletion.
• Object Lock for WORM compliance.
• Cross-region replication.
• Access logging.

Databases:

• Transparent Data Encryption (TDE) at rest.
• TLS for connections.
• Column-level or field-level encryption for specific fields.
• Database-level access controls.
• Audit logging.
• Automated backups.

File storage (EFS, Azure Files, Filestore):

• Encryption at rest and in transit.
• Posix permissions and ACLs.
• Access through specific network locations.

For Nepali bank cloud workloads, layered data protection is standard practice. Audit findings often relate to gaps — particular fields not encrypted, specific access patterns not logged, replication not configured.

4.3 Common attack vectors and threats

The threats specifically applicable to data in cloud.

External threats

Account takeover. Attacker obtains valid credentials (phishing, credential stuffing, leaked credentials) and accesses cloud accounts.

API exploitation. Vulnerabilities in cloud APIs or customer application APIs exploited.

Misconfigured public access. Storage buckets, databases, APIs unintentionally exposed.

Direct attacks on cloud services. Attempts to exploit vulnerabilities in cloud-provider services.

DDoS. Overwhelming services to deny access.

Supply chain attacks. Compromise via third-party software or services.

Internal threats

Malicious insiders. Employees, contractors with legitimate access who misuse it.

Negligent insiders. Inadvertent exposure through misconfiguration or mistakes.

Compromised insiders. Employees whose credentials have been compromised.

Provider personnel. Cloud provider operations staff with technical access capability.

Sophisticated threats

Advanced Persistent Threats (APT). Long-term, targeted, well-resourced attackers — often nation-state-backed. South Asian organisations have been targeted by APT groups including those identified publicly.

Ransomware. Encrypting data and demanding payment. Increasing focus on cloud data and backups.

Cryptomining. Attackers using compromised cloud accounts to mine cryptocurrency at the customer's expense.

Data exfiltration to legitimate-looking destinations. Using cloud services (Dropbox, public S3 buckets, GitHub) as exfiltration channels harder to block than traditional command-and-control.

Common attack patterns

The misconfigured S3 bucket pattern. Exposed bucket with sensitive data; attacker (or researcher) discovers via scanning; data downloaded. Capital One 2019; multiple smaller incidents continuously.

The over-privileged IAM pattern. Service account or role with excessive permissions; compromise of one resource provides broad access.

The forgotten resource pattern. Resource created and forgotten; not maintained or monitored; eventually compromised.

The shadow IT pattern. Cloud resources created outside formal IT governance; not subject to standard controls.

The dependency chain pattern. Compromise via a third-party library or service.

The credential leak pattern. API keys or credentials accidentally committed to public code repositories.

Real-world incidents

Capital One (2019). Misconfigured AWS WAF allowed exfiltration of 100M+ records. Customer-side misconfiguration; AWS infrastructure not compromised.

Various Microsoft 365 / Azure AD incidents (2023-25). Identity-system compromises affecting many customers.

Codecov (2021). Compromise of CI/CD tool used by many organisations; credentials of many downstream customers exposed.

SolarWinds (2020). Supply-chain attack with broad implications including on cloud services.

Foodmandu (Nepal, 2020). Cloud-hosted services; misconfiguration allowed exposure of ~50,000 customer records.

Vianet (Nepal, 2020). Customer data exposure; ~170,000 records.

Nepal Police website (2025). Reported breach with claimed exposure of millions of records.

Each illustrates patterns relevant elsewhere.

Threat intelligence

Sources for cloud-specific threat intelligence:

• CSA Top Threats reports updated periodically.
• Provider security advisories (AWS, Azure, GCP all publish).
• CISA cloud-related alerts.
• Industry-specific intelligence (FS-ISAC for finance).
• Commercial intelligence (Mandiant, CrowdStrike, others).

For Nepali context, npCERT publishes advisories relevant to Nepali infrastructure including cloud-related concerns.

4.4 Encryption, data redaction, tokenization, obfuscation, PKI and key management

The cluster of techniques used to protect data confidentiality through cryptographic and pseudonymisation methods.

Encryption recap

Covered in detail in the Cryptography subject. In cloud:

Symmetric encryption. AES dominant. Used for bulk data encryption.

Asymmetric encryption. RSA, ECC. Used for key exchange, digital signatures.

Modes. GCM and other AEAD modes preferred over CBC.

Key sizes. AES-256 standard; RSA-2048 minimum, 4096 preferred; ECC P-256 or P-384.

Encryption in cloud services

Patterns:

Provider-managed encryption. Provider generates and manages keys. Simplest; least customer control.

Customer-managed keys (CMK). Keys generated by customer or provider but managed by customer. Provider uses keys for encryption operations.

Customer-supplied keys. Customer supplies keys for each operation. Most control; most operational burden.

Bring-your-own-key (BYOK). Customer-generated keys imported into provider's KMS.

Hold-your-own-key (HYOK). Keys stored in customer's HSM, accessed by provider on demand.

For sensitive data, customer-managed keys with provider KMS is the typical pattern. For highest-sensitivity data, HYOK with customer HSM.

Data redaction

Data redaction is the process of removing or obscuring sensitive information from documents or records, typically by replacing the sensitive content with placeholders or removing it entirely, used when documents must be shared but specific portions must be protected.

Use cases:

• Sharing documents externally with sensitive content removed.
• Showing reports with personal information hidden.
• Preparing data for analytics without exposing personal details.

Tools:

• AWS Comprehend. Identifies PII for redaction.
• Azure Cognitive Services / Azure AI. PII detection.
• Google Cloud Data Loss Prevention. Detects and de-identifies sensitive data.
• Third-party. Many options.

Tokenization

Tokenization is the process of replacing sensitive data with unique reference values (tokens) that have no extrinsic meaning or value, with a separate, secured mapping table maintained to retrieve the original data when needed, used widely for payment card data and other sensitive identifiers.

Example: A credit card number 4532-1234-5678-9012 is replaced in operational systems with a token TKN-A8B3X9 — meaningless without the mapping. Only systems with explicit access to the token vault can retrieve the original.

Advantages over encryption:

• Token has no mathematical relationship to original data.
• Token can match format of original (preserving system compatibility).
• Reduces compliance scope (PCI-DSS reduced for tokenised data).
• Token compromise doesn't expose the original.

Considerations:

• Token vault becomes high-value target.
• Vault availability critical to operations.
• Tokenization service performance affects all transactions.

For Nepali payment processors (eSewa, Khalti, IME Pay, FonePay), tokenization is widely used for handling card data. PCI-DSS compliance benefits substantially.

Obfuscation

Obfuscation is the process of making data harder to understand or interpret without removing it entirely, often used for non-sensitive data that benefits from protection against casual inspection, distinct from encryption (which provides cryptographic protection) and tokenization (which replaces with unrelated values).

Examples:

• Masking parts of values (last 4 digits visible, rest hidden).
• Pseudonymisation (replacing names with consistent codes).
• Generalising specific values (age ranges instead of exact ages).

Obfuscation provides operational utility — masked values are still useful for analytics, troubleshooting, customer service — without exposing full sensitive data.

Data masking

A specific form of obfuscation. Common patterns:

• Static masking. Database copies for development/testing have sensitive fields masked.
• Dynamic masking. Application or middleware presents masked values based on user role.
• Format-preserving. Masked values retain original format (number stays a number).

Cloud services offer masking:

• Azure SQL Database Dynamic Data Masking.
• AWS RDS with PostgreSQL extensions or application-layer.
• GCP BigQuery Dynamic Data Masking.

PKI in cloud

Public Key Infrastructure (PKI) is the framework of policies, procedures, hardware, software, and personnel that manages the lifecycle of digital certificates and asymmetric cryptographic keys — issuance, distribution, validation, revocation — providing the foundation for trusted identities and secure communications.

In cloud:

TLS certificates. For service endpoints. Cloud-provider services (AWS ACM, Azure Key Vault Certificates, GCP Certificate Manager) issue and manage TLS certificates.

Code signing. Signing software artifacts to verify origin.

Client certificates. For mTLS in service-to-service communication.

Document signing. Signing PDFs or other documents.

S/MIME. Email signing and encryption.

Cloud PKI patterns

Provider-managed CA. Cloud provider's CA issues certificates. Convenient; limited control.

Customer-managed CA in cloud. Customer operates a CA using cloud services (AWS Private CA, Azure Private Link, GCP Certificate Authority Service).

On-premises CA. Customer's traditional CA; certificates used in cloud.

Hybrid. Mix as appropriate.

Key management

Key management is the comprehensive process of generating, storing, distributing, using, rotating, archiving, and destroying cryptographic keys, foundational to any cryptographic protection — strong cryptography with weak key management provides no real security.

Cloud KMS services

Each major cloud has a KMS:

• AWS KMS. Key Management Service. Hardware-security-module-backed.
• Azure Key Vault. Keys, secrets, certificates.
• Google Cloud KMS. Symmetric and asymmetric keys.

Features:

• Key generation in HSMs.
• Encryption and decryption operations.
• Key rotation (manual and automatic).
• Audit logging of all operations.
• IAM integration for access control.
• Integration with virtually all other cloud services for encryption.

Hardware Security Modules (HSMs)

A Hardware Security Module is a physical computing device that safeguards and manages cryptographic keys, performing cryptographic operations within the protected boundary of the device with hardware-level tamper resistance, providing the highest assurance for key protection.

Cloud HSM services:

• AWS CloudHSM. Dedicated HSM instances.
• Azure Dedicated HSM.
• Google Cloud HSM.

Use cases:

• Highest-sensitivity keys.
• Regulatory requirements specifying HSM (some financial regulations).
• Customer-controlled keys for cloud services.

Key management best practices

• Never use default keys for sensitive data. Customer-managed keys.
• Rotate keys regularly. Annually for typical use; more frequently for high-sensitivity.
• Separate keys by purpose. Don't reuse the same key across unrelated systems.
• Audit all key operations. Comprehensive logging.
• Restrict access narrowly. Few people and few systems should have access.
• HSM for highest sensitivity. Hardware protection where warranted.
• Plan for key compromise. What happens if a key is compromised? Rotation, re-encryption, notification.
• Test key restoration. Backup keys must be restorable.

4.5 Assuring data deletion

The challenge of deletion in cloud

Deleting data in cloud is technically straightforward — delete the object, the record, the file. But assuring deletion — proving that no copies remain — is more complex than on-premises:

Replication. Cloud storage typically replicates across multiple physical devices.

Backup. Backup systems may have copies after the primary deletion.

Caches. Multiple cache layers may retain data.

Provider operations. Provider may have operational copies (for recovery, for auditing).

Subprocessors. Provider may use third parties that have copies.

Levels of deletion

Logical deletion. Marking data as deleted; data still physically present.

Physical deletion. Data removed from storage.

Cryptographic erasure. Encryption key destroyed; data unreadable.

Sanitisation. Storage media overwritten to remove all traces.

Physical destruction. Storage media physically destroyed.

The right level depends on data sensitivity and applicable requirements.

Cryptographic erasure

For cloud, cryptographic erasure is often the practical approach:

1. Data encrypted with specific keys.
2. To delete, destroy the keys.
3. Without keys, data is unrecoverable even if physical bits remain.

Properties:

• Effective for distributed copies.
• Fast (key destruction is quick).
• Verifiable (key destruction can be audited).
• Standard for cloud-scale deletion.

Cloud KMS supports key scheduled deletion:

• AWS KMS. Pending deletion period (7-30 days); cancellable.
• Azure Key Vault. Soft delete; purge after retention.
• GCP Cloud KMS. Scheduled destruction.

Compliance requirements for deletion

Various regulations specify deletion:

GDPR Article 17 (Right to Erasure). Data subjects can request deletion under specified circumstances.

Sectoral regulations. Various requirements for data retention with eventual deletion.

NRB directives. Specific requirements for Nepali banks.

Privacy Act 2075 (Nepal). Specifies handling of personal information including deletion.

Operational deletion procedures

For an organisation processing personal data in cloud:

1. Identify deletion triggers. Subject request, retention expiry, business decision.
2. Locate all instances of data. Across services, regions, backups, logs.
3. Determine deletion approach. Logical, physical, cryptographic.
4. Execute deletion. Through documented procedures.
5. Verify. Confirm deletion across all locations.
6. Record. Document what was deleted, when, by whom.
7. Notify if required. Some regulations require deletion confirmation to data subjects.

Provider commitments

Cloud providers publish deletion commitments:

AWS data deletion. Customer data deletion within set timeframe after termination; verified by provider.

Azure data retention and deletion. Specified timeframes; verifiable.

GCP data deletion. Documented process; multiple verification stages.

For Nepali enterprises selecting providers, deletion commitments are part of due diligence and contractual review.

4.6 Data retention, deletion and archiving procedures for tenant data

The operational disciplines surrounding retention and disposition.

Retention policies

A data retention policy is the formal organisational document specifying how long different categories of data must or may be retained, based on legal requirements, regulatory requirements, business needs, and operational considerations, providing the basis for systematic deletion of data no longer needed.

Drivers for retention:

Legal requirements. Statutes specifying minimum retention.

Regulatory requirements. Sector-specific (NRB requires banking records for specified periods).

Litigation hold. Data preserved for active or anticipated litigation.

Business needs. Operational, analytical, historical value.

Storage cost. Retention has cost; cheaper to delete what is not needed.

Balancing these factors produces retention schedules — different categories of data retained for different periods.

Example retention categories (Nepali bank context)

Category	Minimum retention	Source
Core banking transactions	7 years (typical)	NRB directives
Tax records	5 years	Income Tax Act
Employee records	Per Labour Act	Various
Customer communications	3-7 years (varies)	Sectoral
Application logs	1 year (typical)	Operational/security
Audit logs	7 years (for regulated)	NRB, audit
Backups	Per policy	Operational

Each category has its own retention; storage tiers and locations align with retention.

Archival storage

Archival storage is long-term, low-cost storage designed for data that must be retained but is rarely accessed, characterised by lower per-GB cost, longer retrieval latency, and different access patterns than active storage.

Cloud archival options:

• AWS S3 Glacier and S3 Glacier Deep Archive. Minutes to hours retrieval; very low cost.
• Azure Archive Storage. Similar characteristics.
• GCP Coldline and Archive. Lower cost than standard storage.

Use cases:

• Compliance retention.
• Historical records.
• Backup data not for short-term restore.

Lifecycle policies

Cloud storage services support automatic lifecycle transitions:

# Terraform example — S3 lifecycle for transactional data
resource "aws_s3_bucket_lifecycle_configuration" "trans_data" {
  bucket = aws_s3_bucket.trans_data.id

  rule {
    id     = "transition-and-expire"
    status = "Enabled"

    transition {
      days          = 30
      storage_class = "STANDARD_IA"
    }
    transition {
      days          = 90
      storage_class = "GLACIER"
    }
    transition {
      days          = 365
      storage_class = "DEEP_ARCHIVE"
    }
    expiration {
      days = 2555  # ~7 years
    }
  }
}

The data automatically moves through tiers as it ages; eventually deleted after 7 years (typical bank retention).

Operational discipline for retention

Documentation. Written retention policy approved by management.

Implementation in code. Lifecycle policies on storage; database TTLs; application retention logic.

Audit. Periodic verification that retention is enforced.

Legal hold capability. Mechanism to suspend retention/deletion for litigation.

Exception handling. Documented exceptions and approvals.

Reporting. Retention status reported to governance bodies.

Backup retention

Backups have their own retention:

• Operational backups. Last few weeks for restore capability.
• Compliance backups. Long-term for regulatory.
• Disaster recovery backups. Recent copies in DR location.

Each with own retention and deletion.

Multi-region considerations

Replicated data may be in multiple regions:

• Primary region.
• DR region.
• Backup region.

Retention/deletion must apply consistently across all. Cloud lifecycle policies typically replicate; manual processes need explicit attention.

4.7 Data protection plan and strategies

Bringing everything together into operational practice.

Data protection plan

A data protection plan is the comprehensive documented strategy that establishes how an organisation will protect its data throughout the lifecycle, identifying the data categories handled, the protection requirements for each, the controls applied, the responsibilities assigned, and the operational procedures followed.

Elements of a comprehensive plan:

Scope. What data, systems, organisational units.

Data inventory. What data exists; where; in what form.

Classification. Sensitivity categories; assignment criteria.

Roles and responsibilities. Who does what.

Controls. Technical and procedural controls for each classification.

Compliance mapping. Which controls address which requirements.

Lifecycle procedures. Creation, use, sharing, archiving, deletion.

Incident response. What to do if data is compromised.

Training. What staff need to know.

Audit. Periodic verification.

Continuous improvement. Updates based on findings, changes, lessons.

Strategy elements

Defence in depth. Multiple layers as discussed.

Privacy by design. Built into systems and processes.

Least privilege. Minimum access necessary.

Encryption everywhere. Default state.

Comprehensive logging. Auditability foundational.

Tested incident response. Capability proved before need.

Vendor management. Third parties contractually bound and verified.

Continuous compliance. Not periodic; continuous.

Implementation steps

For an organisation building or improving its data protection programme:

1. Executive sponsorship. Senior management committed.
2. Current-state assessment. What is the current state; what gaps exist.
3. Risk assessment. What data faces what risks.
4. Regulatory mapping. What requirements apply.
5. Strategy and roadmap. Phased improvement plan.
6. Quick wins. Address most-critical gaps immediately.
7. Foundational improvements. Data inventory, classification, logging.
8. Control implementation. Layer by layer.
9. Verification. Audits and tests.
10. Continuous improvement. Ongoing.

Common gaps in Nepali enterprise data protection

Audit findings often identify:

• Incomplete data inventory. Don't fully know what data is held where.
• Inconsistent classification. Same type of data classified differently in different systems.
• Weak access controls. Excessive access granted; not periodically reviewed.
• Insufficient encryption. Some data unencrypted; weak key management.
• Inadequate logging. Access not logged comprehensively.
• Retention not enforced. Data retained beyond requirement.
• Deletion not verified. Deletions assumed but not confirmed.
• Backup not protected adequately. Backups less protected than production.
• Vendor management gaps. Cloud providers and SaaS not contractually addressed sufficiently.
• Incident response untested. Procedures exist but never exercised.

Addressing these systematically transforms an organisation's data protection posture over multi-year programmes.

Operational continuous improvement

Mature data-protection programmes operate continuously:

• Monthly. Compliance metrics reviewed; exceptions investigated.
• Quarterly. Risk assessments updated; new threats considered.
• Annually. Full programme review; strategy adjusted.
• Ongoing. Incidents investigated; lessons learned; controls adjusted.

The investment is substantial. The return — reduced incident likelihood, reduced incident impact, demonstrable compliance, customer and regulator trust — justifies it for organisations handling sensitive data at scale.

The next chapter takes up the operational disciplines for monitoring, auditing, and incident response in cloud environments — the practices that detect when controls fail and respond when they do.