Contemporary Practice and Future Developments

Introduction

Cloud security and data protection are changing because cloud platforms now provide confidential-computing hardware, machine-learning services, automated security operations, geographically distributed infrastructure and increasingly regulated digital services. Security decisions can no longer be based only on firewalls, passwords and infrastructure location. They must consider who can access data, how evidence is generated, where processing occurs, how quickly controls respond, and whether an organisation can demonstrate compliance.

This chapter evaluates six important developments: confidential computing, artificial-intelligence security, security automation, sovereign cloud, post-quantum cryptography and evolving regulation. It then combines them in a practical security and data-protection planning method based on risk, cost, compliance and operational evidence.

Learning objectives

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

• explain the purpose and limitations of confidential computing;
• identify security risks created or amplified by artificial intelligence;
• distinguish security automation, orchestration and response;
• evaluate sovereign-cloud requirements;
• explain why post-quantum cryptography matters;
• relate cloud controls to evolving privacy and cybersecurity regulation; and
• produce a basic, evidence-based cloud security and data-protection plan.

1. From cloud security to evidence-based assurance

Traditional security asks whether controls exist. Contemporary assurance asks whether controls work, for which assets, under which conditions, and with what evidence. A cloud security decision should therefore connect four dimensions:

1. Risk: the likelihood and impact of harmful events.
2. Cost: financial, operational and opportunity costs of controls.
3. Compliance: applicable legal, contractual and sector requirements.
4. Operations: availability, performance, usability and the organisation’s ability to operate the control consistently.

A simple qualitative risk model is:

Likelihood and impact may be scored on ordinal scales, such as 1–5. This produces a prioritisation aid, not a precise probability. It should not be interpreted as a monetary prediction unless the scales have been calibrated.

For monetary analysis, expected annual loss can be estimated as:

where ALE is annualised loss expectancy, SLE is single-loss expectancy in currency units, and ARO is the expected number of events per year. The estimate is uncertain and should include assumptions. For example, if one incident would cost $80,000 and is estimated to occur 0.25 times per year, ALE is $20,000 per year. This does not prove that a $19,000 control is automatically worthwhile: control effectiveness, residual risk, implementation risk and non-financial consequences must also be considered.

Operational evidence may include access logs, key-use records, vulnerability reports, backup-restore results, incident tickets, configuration baselines, supplier attestations, data-flow maps and audit trails. A policy without evidence is an intention; a control with repeatable evidence is assurance.

2. Confidential computing

Confidential computing protects data while it is being processed. Conventional encryption usually protects data at rest and in transit, but plaintext may appear in memory during computation. Confidential-computing technologies use a trusted execution environment (TEE), hardware-assisted isolation and attestation to reduce exposure during processing.

A typical confidential-computing workflow is:

1. A workload is packaged for a supported confidential environment.
2. The cloud platform starts an isolated execution environment.
3. Hardware measures the boot components and workload configuration.
4. A remote party verifies the measurement through attestation.
5. The remote party releases a key only if the expected policy is satisfied.
6. The workload processes data inside the protected environment.

Figure: A simplified confidential-computing trust and key-release flow.

Confidential computing is valuable for multi-party analytics, healthcare research, financial processing and protection from some cloud-administrator or co-tenant threats. It does not automatically protect data before entry, after release, from authorised application users, from malicious code inside the workload, or from all side-channel attacks. Attestation evidence must be validated, retained and linked to a release policy. Organisations should also assess performance, supported operating systems, debugging restrictions, backup behaviour and incident-response procedures.

3. Artificial intelligence and cloud security

AI affects security in two directions. It can improve detection, classification and response, while also creating new attack surfaces and privacy risks.

AI-assisted defensive uses

Cloud security teams may use machine learning to identify unusual access, prioritise vulnerabilities, classify sensitive content, detect malicious code and summarise incidents. Generative AI can help analysts query logs or draft response procedures. These uses require human oversight because models can produce inaccurate, incomplete or fabricated results.

AI-specific threats

Important risks include:

• Prompt injection: untrusted content manipulates an AI system into ignoring its intended instructions.
• Data leakage: confidential prompts, documents or outputs are exposed to an unauthorised service or user.
• Insecure tool use: an AI agent invokes APIs with excessive privileges.
• Poisoning: training or retrieval data is manipulated.
• Model theft and inference: attackers extract sensitive model behaviour or information.
• Adversarial input: carefully designed inputs cause misclassification.
• Automation bias: staff accept an AI recommendation without sufficient verification.

A secure AI service should have data classification, purpose limitation, tenant isolation, retention controls, encryption, access logging, output filtering, abuse monitoring and a clear human-approval boundary. The principle of least privilege applies to AI agents just as it does to human identities. An agent that can read a database should not automatically be able to delete records or change access policies.

AI governance should document the model’s purpose, training or retrieval sources, evaluation method, known limitations, responsible owner, escalation route and review schedule. High-impact decisions require stronger validation and often a human decision-maker. Privacy impact assessment may be necessary when personal data is used for training, profiling or automated decision-making.

4. Security automation and orchestration

Security automation performs a defined action with limited human intervention. Security orchestration coordinates tools and processes. Security orchestration, automation and response (SOAR) combines coordination, automated playbooks and response workflows.

A useful maturity path is:

1. manual investigation;
2. centralised logging and alerting;
3. repeatable playbooks with human approval;
4. low-risk automated containment; and
5. measured, adaptive response with continuous testing.

For example, a playbook may receive an impossible-travel alert, enrich it with identity and device information, request analyst approval, revoke a session, require reauthentication and open an incident record. Automation should be reversible where possible. A mistaken automated account suspension can interrupt critical services; therefore, emergency accounts, approval thresholds and recovery procedures are essential.

Automation quality should be evaluated using operational measures such as false-positive rate, mean time to detect, mean time to respond, percentage of alerts with complete evidence, failed-playbook rate and recovery time. Speed alone is not success. An automated system that closes alerts incorrectly may reduce measured workload while increasing actual risk.

5. Sovereign cloud and data jurisdiction

Sovereign cloud is not a single technical feature. It generally refers to arrangements intended to ensure that data, operations, personnel, infrastructure or legal control remain subject to specified national or regional authority. Requirements differ considerably. A customer may require local data residency, local operational staff, national ownership, isolation from foreign administrative access, or all of these.

The following dimensions should be separated:

Sovereignty can conflict with resilience. Restricting all copies to one jurisdiction may simplify legal control but increase outage and disaster-recovery risk. A sound design records permitted locations, transfer mechanisms, encryption-key jurisdiction, support access, subcontractors, log destinations and exit procedures. “Stored locally” does not necessarily mean that metadata, support logs or backups are local.

6. Post-quantum cryptography

Large-scale quantum computers may threaten public-key algorithms based on integer factorisation or discrete logarithms, such as RSA and elliptic-curve cryptography. Symmetric cryptography is affected differently and generally requires key-length considerations rather than complete replacement. The timing of a cryptographically relevant quantum computer is uncertain, but migration takes years because certificates, devices, protocols and long-lived data must be inventoried and upgraded.

The “harvest now, decrypt later” threat is especially important: an adversary may copy encrypted traffic today and attempt decryption in the future. Sensitive information with a long confidentiality lifetime should therefore be prioritised.

Post-quantum cryptography (PQC) uses classical computation but is designed to resist known quantum attacks. Standardisation efforts have selected schemes based principally on lattice and hash constructions, with continuing evaluation and implementation guidance. Organisations should not install unapproved algorithms casually. They should follow current standards and supplier roadmaps, test interoperability and plan for hybrid modes where appropriate.

A practical migration process is:

• inventory cryptographic algorithms, certificates, libraries and protocols;
• record data confidentiality lifetimes and system replacement dates;
• identify systems that cannot be patched easily;
• require cryptographic agility in procurement;
• test performance, message size and certificate compatibility;
• implement approved post-quantum or hybrid mechanisms when supported; and
• monitor standards, vulnerabilities and supplier announcements.

PQC does not solve compromised keys, poor access control, insecure endpoints or social engineering. It addresses a particular class of cryptanalytic risk.

7. Evolving regulation and governance

Cloud regulation is layered. Privacy laws govern personal-data processing; cybersecurity laws may require risk management and incident reporting; sector rules may impose stronger controls; contracts may define audit, location and breach duties. Examples include the EU General Data Protection Regulation, the EU NIS2 Directive, the EU Digital Operational Resilience Act for relevant financial entities, the EU AI Act, the United States HIPAA framework for covered healthcare entities, and national breach-notification and critical-infrastructure laws. Applicability depends on jurisdiction, sector, organisation size, role and activity.

Common regulatory themes include:

• accountability and demonstrable governance;
• lawful, fair and transparent processing;
• data minimisation and retention limitation;
• privacy and security by design;
• processor and supplier management;
• rights of individuals;
• incident detection and notification;
• resilience, testing and continuity; and
• records that demonstrate compliance.

A cloud provider’s certification is useful but does not transfer all responsibility. The customer remains responsible for correct configuration, identity management, data classification, retention, lawful processing and appropriate use. Contracts should address breach notification, subprocessors, audit evidence, deletion and return, international transfers, vulnerability handling, service levels and exit support.

Regulations evolve, and conflicting requirements may occur. An organisation should maintain a regulatory register linking each requirement to an owner, control, evidence source, review date and exception process. Legal advice is required for jurisdiction-specific decisions; a textbook framework cannot replace it.

8. Building a basic contemporary cloud security and data-protection plan

A practical plan can be developed in eight steps.

Step 1: Establish scope and stakeholders

Identify services, environments, data owners, processors, users, administrators, regulators and critical suppliers. Define business objectives and unacceptable outcomes.

Step 2: Create an asset and data inventory

Record applications, storage, databases, keys, identities, interfaces and backups. Classify data according to sensitivity, legal status, confidentiality lifetime, integrity needs and availability requirements.

Step 3: Map data flows and jurisdictions

Show collection, processing, sharing, backup, logging and deletion. Record locations and transfer mechanisms. Include telemetry and support data, not only the main database.

Step 4: Assess threats and risk

Consider credential theft, misconfiguration, insecure interfaces, malicious insiders, supplier compromise, ransomware, outage, data leakage, AI misuse and quantum-related exposure. Score likelihood and impact consistently, then document assumptions and treatment decisions.

Step 5: Select layered controls

Use identity federation and phishing-resistant authentication where feasible; least privilege; network segmentation; encryption and managed keys; secure configuration; vulnerability management; backup isolation; endpoint protection; data-loss prevention; monitoring; incident response; and supplier assurance. Select confidential computing, sovereign deployment or PQC only when the threat and requirement justify the additional complexity.

Step 6: Define evidence and ownership

Each control should have an owner, expected result, evidence source, review frequency and escalation route. Examples include quarterly access reviews, daily backup-success records, monthly vulnerability reports, key-use logs and annual restore tests.

Step 7: Analyse cost and residual risk

Compare implementation and operating costs with risk reduction, compliance value and operational effects. Residual risk is the risk remaining after controls; it must be accepted by an authorised person or treated further. Include migration, training, licensing, performance and exit costs.

Step 8: Test and improve

Conduct tabletop exercises, restore tests, access reviews, penetration tests, supplier reviews and configuration checks. Track corrective actions to closure. Update the plan after incidents, architecture changes, regulatory developments and major technology changes.

A compact control-plan table may look as follows:

9. Illustrative case: Northstar Health Analytics

Background. Northstar Health Analytics is an illustrative regional provider that analyses hospital data in a public cloud. It needs collaboration among hospitals, but patient records are highly sensitive. A proposed AI service would identify patterns in de-identified and limited datasets.

Problem. Hospitals are concerned about administrator access, cross-border support, AI prompt leakage and the ability to prove deletion. The security team also discovers that certificates and encryption libraries are managed inconsistently.

Analysis. The data-flow review identifies patient data, model inputs, backups, logs and support tickets. The risk assessment rates unauthorised disclosure and prolonged outage as high. Sovereignty requirements demand regional storage and documented administrator access. Confidential computing could reduce exposure during collaborative analysis, but it cannot correct an inaccurate de-identification process or an overly privileged application. The AI service requires restricted tools, no provider training on customer prompts, retention limits and human review. The cryptographic inventory identifies long-lived records and vulnerable legacy devices.

Approach. Northstar adopts a regional cloud configuration, customer-controlled key policies, strong identity federation, privileged-access approval, central logging and immutable backups. It pilots confidential computing for the highest-sensitivity joint analysis. The AI service is placed behind a gateway that removes prohibited fields, records requests, limits tools and blocks production changes without approval. A PQC migration register is created, beginning with certificates and systems containing records that must remain confidential for many years. Contracts specify subprocessors, breach notification, audit evidence, deletion and exit assistance.

Outcome. The design does not claim absolute security. Instead, it reduces identified risks and creates evidence: attestation records, access reviews, key-use logs, AI evaluations, restore-test results, location reports and supplier attestations. Remaining risks—such as application compromise and model error—are formally accepted with owners and review dates.

Learning points. Technology selection followed data classification and threat analysis. Sovereignty was treated as legal, operational and supply-chain control rather than merely storage location. AI was governed as a privileged component. Evidence and residual-risk acceptance were as important as architecture.

10. Challenges, ethics and professional practice

Contemporary controls introduce trade-offs. Confidential-computing features can reduce observability. Automated response can cause harmful false positives. Sovereign deployment may reduce geographic redundancy. PQC may increase bandwidth, certificate size or device requirements. AI can improve productivity while reproducing bias or exposing personal information.

Professionals should apply proportionality, transparency and accountability. They should avoid claiming that a certification proves complete security, that encryption removes all privacy risk, or that AI recommendations are objective. Security teams should protect whistleblowers, minimise unnecessary monitoring, retain only necessary logs and distinguish legitimate investigation from surveillance. Accessibility and operational workload also matter: controls that staff cannot use reliably will be bypassed.

Best-practice checklist

• Maintain an accurate asset, data, identity and cryptographic inventory.
• Treat cloud provider controls and customer responsibilities separately.
• Use layered controls rather than relying on a single technology.
• Require evidence for important security and privacy claims.
• Apply least privilege to people, services and AI agents.
• Test backups, incident playbooks and automated response.
• Record data locations, subprocessors and international transfers.
• Plan cryptographic agility before post-quantum migration becomes urgent.
• Review regulatory applicability with qualified legal and privacy specialists.
• Document residual risk and obtain accountable acceptance.

Chapter Summary

Contemporary cloud security is an evidence-based discipline combining technical safeguards, governance, legal requirements and operational capability. Confidential computing protects data during processing but depends on trustworthy code, attestation and key policy. AI can improve detection and analysis but creates risks involving prompt injection, data leakage, excessive privileges and automation bias. Security automation improves consistency and speed only when playbooks are tested, reversible and measured.

Sovereign cloud concerns jurisdiction, operations, ownership, supply chain and assurance—not simply storage location. Post-quantum cryptography requires inventory, prioritisation and cryptographic agility because migration is lengthy and encrypted data may be collected before future decryption. Regulations increasingly require accountability, resilience, privacy by design, supplier governance and incident evidence. A practical plan begins with scope and data flows, assesses risk, selects proportionate controls, assigns owners, analyses cost and residual risk, and continuously tests evidence.

Key Terms

Confidential computing: Protection of data while it is being processed in a hardware-isolated environment.

Trusted execution environment: An isolated execution area intended to protect code and data from unauthorised access.

Remote attestation: Evidence used by a remote party to verify the state or identity of a computing environment.

Artificial intelligence: Computational systems that perform tasks involving capabilities such as prediction, classification or generation.

Prompt injection: Manipulation of an AI system through untrusted instructions or content.

Security automation: Performance of security actions with limited manual intervention.

SOAR: Security orchestration, automation and response using coordinated tools and playbooks.

Sovereign cloud: Cloud arrangements designed to satisfy specified jurisdictional, operational or ownership requirements.

Data residency: The geographic location in which data is stored.

Post-quantum cryptography: Cryptographic methods designed to resist known quantum-computing attacks.

Cryptographic agility: The capability to replace cryptographic algorithms and components efficiently.

Annualised loss expectancy: Estimated expected loss per year based on loss per event and event frequency.

Residual risk: Risk remaining after controls are implemented.

Data minimisation: Limiting personal data collection and use to what is necessary.

Data processor: An organisation processing personal data on behalf of another responsible organisation.

Attestation: A verifiable statement about the state, identity or configuration of a system.

Data-flow map: A representation of where data is collected, processed, transferred, stored and deleted.

Operational evidence: Records demonstrating that a control exists and functions as intended.

Review Questions

Short Answer Questions

1. What security gap does confidential computing address?
2. Define prompt injection and give one mitigation.
3. How does sovereign cloud differ from simple data residency?
4. Why should organisations begin post-quantum cryptography planning early?
5. What is residual risk?

Long Answer Questions

1. Explain the benefits and limitations of confidential computing in a multi-party analytics system.
2. Discuss how an organisation should govern an AI agent that can access cloud services.
3. Compare security automation with security orchestration and explain the importance of human approval.
4. Explain the technical, legal and operational dimensions of sovereign cloud.
5. Describe an eight-step process for producing a cloud security and data-protection plan.

Analytical / Application Questions

1. A healthcare provider wants to use a foreign-hosted generative-AI service for patient-support records. Analyse the risk, compliance, data-flow and operational issues, and recommend a proportionate decision process.
2. A company has regional backups but no cryptographic inventory. Develop a prioritised PQC migration approach, including evidence and supplier questions.
3. An automated playbook disables accounts whenever unusual travel is detected. Evaluate likely benefits and harms, then design safeguards and measures for deciding whether the playbook is effective.

Multiple Choice Questions with Answers

Question 1

What is the primary purpose of confidential computing?

A. To protect data while it is being processed

B. To eliminate the need for identity management

C. To guarantee that applications contain no vulnerabilities

D. To replace all network encryption

Correct Answer: A. To protect data while it is being processed

Question 2

Which example best illustrates prompt injection?

A. A user changes a password after an expiry warning

B. Untrusted text instructs an AI agent to ignore its security rules

C. A database is encrypted before backup

D. A firewall blocks an unauthorised port

Correct Answer: B. Untrusted text instructs an AI agent to ignore its security rules

Question 3

Which statement about security automation is most accurate?

A. Automation makes testing unnecessary

B. Automation always improves security regardless of false positives

C. Automation should be measured and designed with recovery safeguards

D. Automation transfers all responsibility to the cloud provider

Correct Answer: C. Automation should be measured and designed with recovery safeguards

Question 4

Which factor is part of sovereign-cloud analysis?

A. Only the colour scheme of the provider console

B. The location and legal control of administration and support

C. The number of application screens

D. The programming language used by the customer

Correct Answer: B. The location and legal control of administration and support

Question 5

Why is cryptographic agility important?

A. It permits efficient replacement of cryptographic components

B. It prevents every form of social engineering

C. It removes the need for key management

D. It guarantees unlimited storage capacity

Correct Answer: A. It permits efficient replacement of cryptographic components

Question 6

In the expression ALE = SLE × ARO, what does ARO represent?

A. Annualised recovery output

B. Approved risk objective

C. Annual rate of occurrence

D. Application response overhead

Correct Answer: C. Annual rate of occurrence

Question 7

Which item is strongest as operational evidence that backups are useful?

A. A statement that backups are important

B. A successful, documented restore test

C. An unused backup logo

D. A password policy unrelated to backups

Correct Answer: B. A successful, documented restore test

Question 8

What is a key limitation of a cloud provider’s security certification?

A. It proves that the customer has configured its service correctly

B. It removes all customer responsibilities

C. It may not cover the customer’s configuration and processing decisions

D. It prevents all future regulatory changes

Correct Answer: C. It may not cover the customer’s configuration and processing decisions

Question 9

Which control is most appropriate for an AI agent with production access?

A. Unlimited privileges for convenience

B. Least privilege and approval for high-impact actions

C. No logging to protect privacy

D. A shared administrator password

Correct Answer: B. Least privilege and approval for high-impact actions

Question 10

What is the first practical step in a post-quantum migration?

A. Delete all existing encryption immediately

B. Inventory algorithms, certificates, libraries and protocols

C. Assume quantum computers are already breaking all encryption

D. Disable backups

Correct Answer: B. Inventory algorithms, certificates, libraries and protocols