Cloud Operations, Legal, Risk & Contracts (Vendor-Neutral)

#Building and Operating Cloud Infrastructure

#What is this?

The operational practices that keep cloud hosts, guests, networks and management tools secure and available, whether you run a private cloud or manage IaaS workloads.

#Why it matters

Most cloud incidents come from operations: an unhardened image, a management port left open, a patch never applied, a backup never tested.

#How it works

#Operational processes (ITIL and ISO/IEC 20000-1)

CCSP expects you to recognise the service-management processes and how security plugs into each: change management, configuration management, release and deployment management, incident management (restore service fast), problem management (find and fix the root cause of repeated incidents), service level management, availability and capacity management, continuity management, information security management, and continual service improvement.

#Security operations

A SOC (security operations centre) monitors security controls, collects and correlates logs in a SIEM, handles incidents and runs vulnerability management. In the cloud, add cloud-native detections (control-plane API logs, posture findings) to the usual endpoint and network sources. See detection engineering and incident response.

In practice"No internet-exposed admin ports" looks like this in an SSH config — admins hop through one hardened, logged bastion instead of reaching servers directly:

# ~/.ssh/config
Host bastion
    HostName bastion.ops.example.com
    User alice
    IdentityFile ~/.ssh/id_ed25519_sk        ← hardware-backed key (FIDO2)

Host 10.20.*
    ProxyJump bastion                         ← every admin session passes the bastion

In a cloud, the stronger version removes SSH entirely: aws ssm start-session --target i-0abc123 opens a shell through the provider's agent, with no inbound port and every keystroke logged.

📰

Real incident — Code Spaces (2014). An attacker got into the code-hosting company's AWS console, demanded a ransom, and when staff tried to regain control, deleted machines, storage and the backups, which lived in the same account. The company shut down within days. Lesson: management-plane access is everything, and backups that the same credentials can delete are not backups.

🎯

On the job. In an operations review, ask: who can reach the management plane and from where, is MFA enforced on it, are admin sessions recorded, and could one compromised admin account delete both production and its backups?

#Security angle

Incident management restores service; problem management prevents recurrence. Security teams that only do the first keep fighting the same fire.

#Digital Forensics in the Cloud

#What is this?

Collecting and analysing evidence when the systems are virtual, shared and owned by someone else.

#Why it matters

You can't seize a provider's servers, data may span countries, and volatile evidence disappears when an instance is terminated or auto-scaled away.

#How it works

• What you can collect depends on the service model: IaaS gives you disk snapshots, memory captures and network logs; PaaS and SaaS give you mostly logs and whatever the provider exposes through APIs.
• Collection methodology — capture memory before isolation, snapshot disks, copy logs to a forensics account, hash everything, document chain of custody. See digital forensics and AWS IR.
• Provider cooperation — the contract should cover what the provider will supply in an investigation and how fast.
• Standards
  ISO/IEC 27037

  identifying, collecting, acquiring and preserving digital evidence.

  ISO/IEC 27041

  assuring investigative methods are fit for purpose.

  ISO/IEC 27042

  analysing and interpreting digital evidence.

  ISO/IEC 27043

  incident investigation principles and processes.

  ISO/IEC 27050

  electronic discovery (eDiscovery).

• eDiscovery — finding and producing electronically stored information for legal proceedings; cloud tools and legal holds help, but multi-tenant storage and jurisdiction complicate it.

In practiceCloud evidence collection is API calls, run from a separate forensics account, tagged and hashed:

$ aws ec2 create-snapshot --volume-id vol-0a1b2c3d \
    --description "IR-2026-031 web01 root volume" \
    --tag-specifications 'ResourceType=snapshot,Tags=[{Key=case,Value=IR-2026-031}]'
$ aws ec2 modify-snapshot-attribute --snapshot-id snap-0f9e8d \
    --attribute createVolumePermission --operation-type add --user-ids 222233334444   ← share to forensics account
$ sha256sum web01-memory.lime > web01-memory.lime.sha256                            ← hash before anyone analyses it

📰

Real incident — Capital One (2019). An attacker abused a misconfigured web application firewall to make the server fetch its own instance-metadata credentials (SSRF), then used that role to copy over 100 million customer records from S3. The investigation rebuilt the timeline almost entirely from CloudTrail API logs and S3 access logs: in the cloud, logs are the crime scene.

🎯

On the job. Pre-build the forensics account, the IAM roles that can snapshot and share volumes, and the memory-capture tooling before you need them. During the incident, capture memory before isolating or terminating, and record every API call you make, because your own actions appear in the same CloudTrail as the attacker's.

#Security angle

Prepare in advance: forensic roles and accounts, automated evidence capture, and contractual rights. During an incident is too late to negotiate access.

#Communication With Relevant Parties

#What is this?

Who must be told what, and when, during normal operations and incidents: vendors, customers, partners, regulators and internal stakeholders.

#Why it matters

Regulations set hard deadlines for breach notification, and contracts set them for customers. Poor communication turns a security incident into a trust and legal incident.

#How it works

See writing reports and postmortems for per-audience writing.

In practiceA first external notification is short, factual and avoids speculation:

Subject: Security incident notification — [Company] — [date]

On [date/time UTC] we detected unauthorised access to [system]. We contained it at [time].
What we know: [scope confirmed so far]. What we don't know yet: [open questions].
What you should do: [specific actions, e.g. rotate API keys issued before X].
Next update: [time]. Contact: [named person, channel].

🎯

On the job. Keep pre-approved templates and a contact matrix (regulator, customers, cloud provider support, cyber insurer, law enforcement) in the incident plan. The cyber insurer often must be told before you hire responders, or the cost isn't covered.

#Legal Requirements and Jurisdiction

Last verified2026-10 — international data-transfer rules are actively litigated; check current status before relying on a mechanism.

#What is this?

The laws that apply to cloud data, which depend on where data is stored, where the provider is headquartered, and where the people in the data live, and which can conflict with each other.

#Why it matters

Cloud makes it easy to store data in many countries without noticing. Each location brings its own laws, including government access rights.

#How it works

📰

Real incident — the Microsoft Ireland case (2013–2018). US prosecutors demanded emails a US customer had stored in Microsoft's Dublin data centre. Microsoft refused, arguing a US warrant couldn't reach data abroad, and won on appeal. While the case sat at the Supreme Court, Congress passed the CLOUD Act (2018), which explicitly gives US authorities that reach, and the case was dropped. That one dispute is why "which region?" no longer fully answers "whose law?"

📰

Real incident — Meta's €1.2 billion fine (2023). Ireland's data protection authority fined Meta for transferring EU users' personal data to the US under standard contractual clauses that didn't, after Schrems II, adequately protect it from US surveillance. It remains the largest GDPR fine and the clearest signal that transfer mechanisms are enforced.

🎯

On the job. For any new cloud service handling personal data, record: where data is stored and processed (including support access and sub-processors), which transfer mechanism applies, and whether keys are held outside the provider's control.

#Security angle

Encryption with keys held outside the provider's jurisdiction (HYOK) is the strongest technical answer to foreign government access, at the cost of availability and complexity.

#Privacy

#What is this?

Protecting personal data and the rights of the people it describes, as distinct from protecting company secrets.

#Why it matters

Privacy law carries the largest fines (GDPR up to 4% of global annual turnover) and applies regardless of where the cloud provider is.

#How it works

In practiceA DPIA (data protection impact assessment) boils down to a table like this per processing activity:

🎯

On the job. Security engineers are usually asked to fill in the "controls" column. Bring specifics — redaction, encryption, retention periods, access logging — not "industry-standard security."

#Security angle

Security incidents involving personal data are also privacy incidents with their own notification clock. Bring legal and the privacy office in early.

#Audit in the Cloud

#What is this?

How organisations get assurance about cloud environments they don't fully control, and what changes compared with auditing an on-prem data centre.

#Why it matters

You can't walk into a hyperscaler's data centre with a checklist. Assurance comes from reports, contracts and your own monitoring.

#How it works

• Audit reports
  • SOC 1 — controls relevant to financial reporting (for auditors of the customer's financial statements).
  • SOC 2 — security, availability, processing integrity, confidentiality and privacy; restricted distribution, under NDA. Type I = design at a point in time; Type II = operating effectiveness over a period (usually 6–12 months).
  • SOC 3 — a public summary of SOC 2, without details.
  • These follow SSAE 18 (US) and ISAE 3402 (international) attestation standards.
• Scope statements — check what is excluded: services, regions, sub-processors, time period. A report on one service says nothing about another.
• Assurance challenges — virtualisation and multi-tenancy mean auditors can't isolate "your" hardware; continuous change means point-in-time evidence goes stale fast.
• Gap analysis — compare current controls against a framework or regulation and list the gaps; usually the first step before an audit.
• Audit planning — define objectives, scope, criteria, evidence sources and stakeholders.
• Internal ISMS (information security management system) and internal control system — the organisation's own policies and controls, audited by internal audit.
• Highly regulated industries — healthcare (HIPAA, HITECH), payments (PCI DSS), electricity (NERC CIP), and essential and important entities under NIS2 add specific requirements.
• Distributed IT — data across many locations and jurisdictions complicates evidence collection and legal requirements.

In practiceThe parts of a SOC 2 Type II report that actually matter, which most readers skip:

Section 4 — Testing of controls
  CC6.1  Logical access is restricted ...
         Test: inspected 25 of 340 terminations     Result: 2 accounts not removed within 24 h   ← EXCEPTION
Complementary User Entity Controls (CUECs)
  • Customers are responsible for enabling MFA for their users                                  ← YOUR job, not theirs
Subservice organisations: Amazon Web Services (carved out)                                      ← AWS controls NOT tested here
Period: 1 Jan 2026 – 30 Jun 2026                                                                ← ask for a bridge letter after this

🎯

On the job. When reviewing a vendor's SOC 2, read the exceptions, the complementary user entity controls (your obligations) and the carved-out sub-service organisations first. A clean opinion with three exceptions in access control tells you where to push in the security questionnaire.

#Security angle

Collect evidence continuously from your cloud environment (configuration snapshots, access reviews, logs) so audits are a report run, not a project.

#Enterprise Risk Management for Cloud

#What is this?

Fitting cloud risk into the organisation's overall risk management: assessing providers' risk programmes, choosing treatments and tracking metrics.

#Why it matters

Moving to the cloud transfers some risks to the provider, adds new ones (concentration, lock-in, jurisdiction) and changes others. The board still owns all of it.

#How it works

📰

Real incident — CrowdStrike content update (July 2024). A faulty configuration update to CrowdStrike's Falcon sensor crashed about 8.5 million Windows machines worldwide, grounding flights and disrupting hospitals and banks. Nothing was hacked; one trusted vendor's change propagated everywhere at once. It made concentration risk — many critical systems depending on one provider — a board-level topic.

🎯

On the job. In a cloud risk register, include availability and concentration risks next to breach risks: single region, single identity provider, single security agent with kernel access. For each, record the dependency, the blast radius and the fallback.

#Outsourcing and Cloud Contract Design

#What is this?

The contracts and vendor management that turn security requirements into enforceable obligations on the provider.

#Why it matters

Once signed, the contract is the only lever you have. If it doesn't grant audit rights, log access or an exit path, you don't have them.

#How it works

• Agreements
  MSA (master service agreement)

  the overall legal terms.

  SOW (statement of work)

  the specific services and deliverables.

  SLA (service level agreement)

  measurable commitments (availability, response times, support) and the credits or penalties if missed.

• Key contract clauses — right to audit (or accepted third-party reports instead), security and compliance obligations, breach notification time, data location, sub-processor approval, access to logs and forensic support, data return and deletion at exit (reversibility), termination rights, liability and indemnity, litigation and jurisdiction, definitions, metrics, and cyber insurance.
• Vendor management — due diligence before signing, ongoing assessments, lock-in risk (proprietary services and data formats), vendor viability (could they go out of business?), and escrow (source code or data held by a third party, released if the vendor fails).
• Supply-chain management — ISO/IEC 27036 covers information security in supplier relationships, including the provider's own suppliers.

📰

Real incident — Snowflake customer breaches (2024). Attackers used passwords stolen by infostealer malware to log into around 165 Snowflake customer accounts that didn't enforce MFA, stealing data from companies including AT&T, Ticketmaster and Santander. Snowflake's platform wasn't breached; the gap was on the customer side of shared responsibility. Snowflake later made MFA the default.

🎯

On the job. Turn the contract into checks: can we export our logs, is MFA enforceable for all our users, how fast must they notify us, can we get our data out in a usable format, and what happens to it after termination. Then verify the technical ones in the product, not just on paper.

#Security angle

Plan the exit on day one: how you would get every byte of data back, in a usable format, within what time, and how deletion would be proven.