CCSP Enterprise Risk Management in the Cloud: Data Roles, Risk Treatment and Frameworks

Moving to the cloud changes who operates the controls, not who owns the risk. The customer's board, risk owners and data owners stay accountable for the business outcomes a cloud service supports; the provider becomes one more source of risk, and one more party whose controls the customer relies on. Enterprise risk management (ERM) therefore has to reach outside the organisation: into the provider's own risk program, into the contract, and into the evidence the provider is willing to share.

Three consequences shape this whole topic:

• Visibility drops. The customer can no longer inspect every control directly, so it assesses the provider's risk management program and relies on attested evidence instead of its own audits.
• Roles split. Data that one organisation owns is held, processed and operated by others, so the data roles (owner, custodian, steward, controller, processor) have to be named precisely. Each role carries different duties, and moving data to a provider changes the custodian, not the owner.
• Transparency duties stay with the customer. Breach notification under the GDPR and financial-control reporting under Sarbanes-Oxley remain the customer's obligations, even when the incident or the control sits at the provider.

The rest of ERM is familiar: set appetite and tolerance, assess the environment, choose a treatment, measure, and monitor. What changes is that every step must account for a party the customer does not control. The basics of risk identification and qualitative versus quantitative analysis for cloud infrastructure are covered in the Domain 3 lesson on risk assessment; this lesson covers how those ideas work at the enterprise level once a provider is involved.

You assess a provider's risk management program by examining five elements and asking, for each, what it tells you about the risk you would inherit: its controls, its methodology, its policies, its risk profile and its risk appetite.

Keep the five apart: a question about how risks are found and scored is about methodology; a question about what risks exist now is about the profile; a question about how much risk leadership will take is about appetite. The risk register, the working list of identified risks with their ratings, owners and treatments, is an output of the methodology; appetite is set separately by leadership.

Gathering evidence when you cannot audit

Large multi-tenant providers rarely allow individual customer audits, so the customer relies on third-party assurance and maps it to its own requirements:

• CSA STAR Level 1 is the provider's own self-assessment against the Cloud Controls Matrix (CCM), usually submitted as a completed CAIQ (Consensus Assessments Initiative Questionnaire). It is a set of claims, useful for scoping but not independent.
• CSA STAR Level 2 adds independent third-party certification or attestation against the CCM.
• SOC 2 Type II reports an independent auditor's tests of the operating effectiveness of security-relevant controls over a period.
• ISO/IEC 27001 certifies an information security management system within a defined scope. A certificate covers only the services, locations and processes named in its scope, so it says something about a service only when that service falls inside the scope. The statement of applicability then shows which controls were selected within it.

Assurance review is a gap analysis: compare what the available evidence covers with your own control and risk requirements, and the uncovered requirements become the questions you take to the provider. Weigh each piece of evidence by its independence. A self-assessment records what the provider says it does; an attestation records what an independent auditor found. The more sensitive the data, the more its key controls need independent evidence. How audits and the SOC report types work in detail is covered in sub-domain 6.3.

When the provider's risk appetite differs from yours

When a provider's appetite is wider than yours, the gap is your risk to treat, because the provider sets its appetite and service commitments once for its whole customer base and does not adapt them to one customer. Its backup retention, maintenance windows or failover design are decisions made for the platform; their consequences for your service fall on you.

Record the gap and close it with one or more of:

• Your own controls: multi-region or multi-provider design, a faster regression-test harness, client-side encryption.
• Contract terms: longer notice periods, stronger SLAs, exit rights (designing these terms is sub-domain 6.5).
• A different service or tier: a premium or isolated tier for the workloads that need it.

Scope the treatment to the gap: the workloads whose requirements exceed what the provider offers get the extra measure, and the rest of the estate does not need it. A measure closes a gap only when it acts on the specific risk that created it; assurance that the provider's controls operate says nothing about whether its appetite matches yours.

Risk appetite is the broad amount and type of risk an organisation is willing to pursue or retain; risk tolerance is the acceptable variation, a measurable threshold, for one specific objective. Appetite is usually set by the board in general terms ("a low appetite for risks to customer data"); tolerances implement it in numbers ("no more than four hours to restore the payroll service after an outage").

Appetite and tolerance work at different levels, and a risk must satisfy both. A risk can sit within the broad appetite and still breach the tolerance set for its own objective, and that breach needs treatment or escalation to its risk owner. Tolerances are governance decisions, changed by the authority that set them for a business reason, not adjusted as part of treating one risk.

Data roles separate who is accountable for data from who looks after it and who processes it. Owner, custodian and steward are governance roles inside or across organisations; controller and processor are legal roles defined by privacy law such as the GDPR.

The most common confusion is between owner and custodian. Approving access is the owner's decision; the custodian only carries it out. A contract can allocate custodial duties, such as encryption and backups, to a provider; it cannot reassign the owner's accountability. When a university's research lead approves a visiting team's access to a dataset and the platform enforces that approval, the consequences of the access decision rest with the owner who made it, not with whoever configured or used it. Holding the data never makes a party its owner or controller.

Controller and processor rules that matter in cloud

• Possession is not control. A provider that stores a logistics firm's customer records purely to run the firm's CRM is a processor, however much data it holds.
• A processor that decides its own purposes becomes a controller for that processing. Under GDPR Article 28(10), a processor that determines the purposes and means of processing, for example by analysing client records to build its own benchmarking service, is treated as a controller for that processing, while remaining a processor for the contracted service.
• Joint control (Article 26) arises when parties determine purposes and means together, by a common decision or through converging decisions; it does not require equal involvement.
• Sub-processors need the controller's authorisation (Article 28(2)). Under specific written authorisation, each sub-processor needs the controller's approval. Under general written authorisation, the processor must inform the controller of any intended addition or replacement, so that the controller can object before the change takes effect.

How privacy law applies across jurisdictions, and privacy impact assessments, are covered in sub-domain 6.2.

The GDPR splits breach notification between processor and controller. The processor (often the cloud provider) must notify the controller without undue delay after becoming aware of a personal data breach (Article 33(2)). The controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals' rights and freedoms (Article 33(1)).

Two timing points come from the Article 29 Working Party guidelines on breach notification, endorsed by the EDPB:

• Prompt, phased notice. The processor informs the controller promptly and supplies further detail in phases as it learns more (Article 33(4) allows phased information for the controller too), because the controller's own deadline depends on that notice.
• The controller's 72 hours run from its own awareness, meaning a reasonable degree of certainty that a breach has occurred; a controller is in principle aware once its processor has informed it.

Encryption changes the outcome. Strong encryption with a secure key generally makes a confidentiality breach unlikely to result in risk to individuals, which removes the duty to notify the authority, and unintelligible data removes the duty to tell data subjects. Documentation under Article 33(5) is still required. A compromised key, or the loss of the only copy of the data, changes the analysis.

Other regimes impose their own transparency duties: national and US state breach-notification laws, and sector rules such as the HIPAA Breach Notification Rule for protected health information. The pattern is the same: the regulated organisation keeps the duty to notify, and its contract must require the provider to tell it quickly enough to meet that duty.

The Sarbanes-Oxley Act (SOX) makes the management of a US public company responsible for internal control over financial reporting (ICFR), and outsourcing a financial system to a cloud provider does not move that responsibility. Section 302 requires the chief executive and chief financial officers to certify periodic reports, and Section 404(a) requires management to assess and report each year on the effectiveness of ICFR; for larger filers, Section 404(b) adds the external auditor's attestation on that assessment. The assessment itself is management's; the audit committee oversees the financial reporting process and the external auditor.

When a general ledger or billing system runs on SaaS, management uses the provider's SOC 1 report, which covers controls relevant to customers' financial reporting, as evidence for its own assessment. A Type 2 report tests operating effectiveness over a period, so it is the one that supports reliance. SOC 2 reports against the trust services criteria (security, availability, processing integrity, confidentiality, privacy) and serves security assurance rather than ICFR reliance.

A clean SOC 1 Type 2 is not the whole answer. The report lists complementary user entity controls (CUECs): controls the customer must operate for the provider's control objectives to be met, such as reviewing who has access to the application, or reconciling data loaded into it. For SOX, management must implement and test those customer-side controls as well as evaluate the report. By definition they sit on the customer's side, because they depend on the customer's own users and processes. Details of report types, bridge letters and audit planning belong to sub-domain 6.3.

The five risk treatment options are avoid, mitigate, transfer, share and accept. You choose among them by comparing the risk with appetite and tolerance, weighing the cost of treatment against the loss it prevents, and asking whether the business must keep the activity.

NIST SP 800-39 draws the line between sharing and transfer by degree: sharing shifts part of the responsibility or liability, transfer shifts all of it. Neither changes how likely the harm is, and neither moves accountability. The organisation accountable for the data answers to regulators and customers, whoever pays for the damage.

How to choose:

• Within appetite, and further control costs more than it saves: accept, documented by the risk owner with a review date.
• Outside appetite, driven by the activity itself, and the activity is optional: avoid. A treatment has to act on the source of the risk; financial cover offsets money, not regulatory or reputational harm.
• Outside appetite, activity must continue: mitigate, and if residual impact is still above appetite, layer treatments: controls lower likelihood or impact, and transfer or sharing covers the financial residual.

Contractual remedies such as SLA service credits are usually capped refunds of a fraction of the fees, so they recover little of the lost revenue or regulatory cost of an incident. Treatment definitions and analysis methods are introduced in the Domain 3 risk assessment lesson; this domain applies them at enterprise level.

Different risk frameworks serve different purposes, so you choose one by what you need it to do: run enterprise-wide risk management, support an ISMS, authorise a system, or conduct an assessment.

Frameworks are often paired. An organisation with an ISO/IEC 27001-certified ISMS moving to cloud would use ISO/IEC 27005 as its risk process and seed its risk list from ENISA's cloud-specific risks, then pick controls from the CCM or ISO/IEC 27017. A US federal agency would take a new cloud system through NIST SP 800-37, using SP 800-30 for the assessment step and SP 800-53 for controls. The common mistake is to confuse a control catalogue with a risk process, or a generic ERM guideline with an ISMS-aligned one.

Risk metrics work when they measure the risk itself, can be measured repeatably, have an owner, and are compared with a threshold that triggers a decision. The central tool is the key risk indicator (KRI): a forward-looking measure tied to a specific risk and to thresholds derived from appetite and tolerance, so that rising exposure triggers escalation before a loss.

The distinction is exposure versus effort: activity counts describe work done or scale, while a KRI states how much risk is present relative to an agreed limit, which is what a board needs to judge whether it is inside its appetite.

Read KRIs as trends, not only against the limit. Good practice defines escalation points, sometimes called amber zones, below the tolerance threshold. A sustained rise toward the threshold is the early warning a KRI exists to give; amber zones turn that rise into escalation to the risk owner while there is still time to choose a treatment. Leading indicators warn; lagging ones such as incident counts confirm after the fact.

You assess the cloud risk environment from four angles: the service being bought, the vendor offering it, the infrastructure it runs on, and the business that will depend on it. The first three look outward at the provider; the business view looks inward, and without it you cannot judge whether the provider-side findings are acceptable.

The areas depend on different things, so work can be reused selectively. Because each area rests on different facts, earlier findings carry over only where those facts are unchanged: vendor findings follow the company, infrastructure findings follow the regions and data centres, and service and business findings belong to one offering and one way of depending on it.

Vendor viability, lock-in and escrow as contract and vendor-management matters are covered in sub-domain 6.5.