Capital One made cloud metadata a contract-control mismatch accountability test

Summary

• Capital One's 2019 breach became a contract-control mismatch case because cloud shared-responsibility language said customers controlled configuration and identity, while public records still had to show who could practically prevent, detect, and repair the specific metadata-access path.
• Capital One's SEC-filed press release and FAQ, the company incident information page, and the Canadian incident page establish company notice, affected populations, data categories, and response posture.
• DOJ records, including the case page, superseding indictment, conviction announcement, and sentencing announcement, support the criminal-case record while preserving the distinction between allegations and adjudicated outcomes.
• OCC and Federal Reserve actions, including the OCC penalty announcement, civil money penalty order, cease-and-desist order, and Federal Reserve enforcement order, show that regulator accountability focused on cloud risk management, control inventory, testing, audit, and board oversight.
• The repair question is not whether the cloud provider or the bank can quote a responsibility model. It is whether configuration, metadata access, IAM scope, monitoring, alert disposition, customer notice, and board evidence matched the real control path attackers used.

Shared responsibility is not a factual record

The AWS Shared Responsibility Model is clear in broad terms: AWS is responsible for security of the cloud, while customers are responsible for security in the cloud, including configuration and customer-controlled identity choices. That model is necessary. It helps cloud customers understand which duties cannot be outsourced. But a responsibility model is not a factual record of what happened in a particular breach.

Capital One's July 2019 SEC-filed press release and FAQ described unauthorized access by an outside individual who exploited a configuration vulnerability and obtained certain personal information relating to credit card applications and customers. The company stated that no credit card account numbers or login credentials were compromised and that over 99 percent of Social Security numbers were not compromised. The maintained Capital One incident page and the Canadian 2019 cyber incident page later provided country-specific and updated incident information.

Those company records began the public account, but they did not decide every control question. Who configured the web-application firewall? Who scoped the IAM role? Who could reach the metadata service? Which alerts fired? Which alerts were dispositioned? Which board committee tracked remediation? Which cloud-risk assumptions were tested before migration? The incident became an accountability case because each of those questions sits at the boundary between contract language and operational evidence.

Shared responsibility can sometimes become a slogan. It can be used by customers to say "the provider is secure" or by providers to say "the customer's configuration was the problem." Neither shortcut is enough. The useful question is control-specific: which party had practical ability to prevent the relevant request path, restrict metadata credential use, reduce permissions, detect abnormal behavior, and stop data copying?

Capital One's case shows why cloud risk is not automatically safer or riskier than on-premises risk. Cloud services can provide strong primitives, logging, identity tools, and rapid hardening. They can also expose misconfigurations with enormous scale if customers do not govern them. The contract-control mismatch appears when the legal allocation is clearer than the actual control evidence.

The metadata path turned infrastructure detail into customer exposure

AWS's post on defense in depth with EC2 Instance Metadata Service Version 2 explains the instance metadata service, role credentials, link-local access, session token design, PUT method, and defense-in-depth thinking behind IMDSv2. AWS also announced updates to the Amazon EC2 Instance Metadata Service in November 2019 and later described IMDSv2 by default in 2023. These provider records are post-breach control context, not admissions about Capital One.

The metadata-service issue matters because role credentials are meant to let applications access cloud resources without hard-coding long-term secrets. That design is powerful and generally useful. But if an application path lets an attacker reach the metadata endpoint and retrieve credentials, the scope of the attached role becomes decisive. AWS documentation on configuring the instance metadata service and IAM roles for Amazon EC2 explains the current control model.

In accountability terms, the metadata path is a chain, not a single failure. A web request reaches a vulnerable or misconfigured application component. The request can reach the metadata service. The metadata service returns temporary credentials for an instance role. The role has permissions. Those permissions allow data access. Detection either notices or misses the behavior. Customer notice later translates the technical path into affected data categories. Each link has a possible owner and a possible control.

AWS IAM best practices emphasize least privilege and credential discipline in current guidance. Again, current guidance is not a reconstruction of every 2019 setting. It is useful because it frames the repair question. After a metadata-path breach, organizations must ask whether role permissions were narrower than application need, whether sensitive storage required additional conditions, whether metadata access was constrained, and whether abnormal credential use would alert quickly.

The public sometimes reduces this incident to "a cloud misconfiguration." That phrase is too small. The path involved application-layer behavior, metadata service access, IAM role scope, storage permissions, detection, and governance. Calling it one misconfiguration can hide the control evidence that regulators later demanded.

Criminal adjudication and civil accountability are different records

The DOJ case page for United States v. Paige Thompson provides the public federal case index. The superseding indictment alleged scanning for misconfigured web-application firewalls, credential acquisition, bucket listing, data copying, and conduct affecting more than one entity. The later DOJ conviction announcement and sentencing announcement provide adjudicated criminal-case status.

These records matter, but they answer a different question from control accountability. Criminal conviction establishes the defendant's adjudicated criminal conduct. It does not by itself prove that every bank control was adequate or inadequate. Nor does a bank control failure excuse criminal conduct. The accountability record has to hold both facts: the attacker was responsible for the intrusion, and the institution still had duties to prevent, detect, and repair.

The same distinction applies to civil litigation. The Capital One consumer settlement site's document archive, Capital One Data Breach Settlement documents, includes court records such as the motion-to-dismiss order and the final approval order. The motion-to-dismiss order discusses pleaded theories under a procedural standard, not final trial findings. The final approval order approved a settlement, not a full allocation of fault after trial.

This layering matters because public debate often collapses court records into simple blame. An indictment is not a civil-control audit. A settlement is not a trial verdict. A consent order is not the same thing as an admission. Each document has a legal posture. Responsible analysis uses each for what it can support and does not make it do more.

For the reader, the takeaway is that accountability is not one verdict. It is a set of records: company notice, criminal prosecution, banking supervision, civil settlement, cloud-provider control documentation, and board disclosure. Together they show how a cloud incident moves through technical, legal, regulatory, and customer channels.

Regulators focused on cloud governance, not slogans

The Office of the Comptroller of the Currency announced an $80 million civil money penalty against Capital One in NR 2020-101. The signed OCC civil money penalty order contains findings on the 2015 cloud migration, risk assessment, control weaknesses, data-loss prevention, alert disposition, internal audit, board accountability, and the penalty, while preserving that Capital One neither admitted nor denied the Comptroller's findings. The OCC cease-and-desist order required corrective actions around cloud risk, control inventory, testing, reporting, audit, and board oversight.

The Federal Reserve's enforcement announcement and attached cease-and-desist order addressed holding-company oversight and compliance planning. The OCC later announced termination of its 2020 cease-and-desist order in an August 2022 enforcement release. Termination matters, but it does not erase the historical penalty or rewrite the 2020 record.

Regulators did not merely say "cloud is risky." They focused on governance evidence: risk assessment before migration, control inventory, testing, audit, reporting, and board oversight. That focus is significant because it treats cloud as a managed operating model, not a vendor magic trick. Financial institutions can use cloud services, but they must be able to prove that controls match the risk.

The FFIEC statement on risk management for cloud computing services provides the broader supervisory context. It emphasizes that financial institutions remain responsible for effective risk management when using cloud services. The statement is general and not a Capital One finding. It still captures the regulator's posture: do not assume cloud controls are effective by default; understand architecture, access, monitoring, resilience, and third-party risk.

The regulator record is the clearest answer to the contract-control mismatch. A shared-responsibility model can allocate categories, but regulators want proof. Which controls existed? Were they tested? Did alerts get handled properly? Did audit identify gaps? Did the board oversee correction? Was cloud migration risk assessed before the system went live? These are evidence questions.

Typography note

Customer notice converted architecture into personal risk

Capital One's incident notice converted cloud architecture into personal risk categories. The SEC-filed release described approximate affected U.S. individuals and Canadian credit card customers and applicants, along with categories such as names, addresses, postal codes, phone numbers, email addresses, dates of birth, self-reported income, credit scores, credit limits, balances, payment history, contact information, and transaction data. The company also described Social Security number and linked bank account number exposure for smaller subsets. The maintained incident pages provide later context.

The Office of the Privacy Commissioner of Canada announced that it had launched an investigation in a July 2019 notice, OPC launches Capital One investigation, and referenced six million affected Canadians and some Social Insurance Numbers. That regulator announcement is not a final finding, but it shows the cross-border public-interest dimension. A cloud-hosted application breach can affect people in more than one jurisdiction even if the technical path is described in one provider's service terms.

Customer notice matters because individuals do not experience "metadata service access." They experience uncertainty about credit applications, identity data, banking details, fraud, credit monitoring, and time spent responding. A technical chain becomes a personal burden only when the organization translates it into data categories and protective steps. If that translation is vague or delayed, customers carry uncertainty.

Data locality should be handled carefully. Public records establish that U.S. and Canadian residents were affected. They do not establish every storage location or cloud region for every entity. Responsible analysis should not invent locality facts. But the incident still raises data-sovereignty and control questions: which jurisdictions' data was stored, which entities controlled it, which regulators were notified, and whether cloud architecture made those answers easy to prove.

The settlement record shows the long tail of customer remediation. The final approval order approved a settlement fund and services. Settlement approval does not decide every allegation. It does show that customer response continued years after the original breach announcement. The architecture failure became a legal and consumer-remediation program.

Board evidence had to become technical enough

Capital One's 2019 Form 10-K described incident-related response costs, insurance recoveries, risk disclosures, litigation, and remediation. The company's 2020 proxy statement described board notification, committee meetings, outside experts, enhanced cyber governance, CISO reporting, and board oversight. These are company disclosures, not independent proof of control effectiveness, but they show how the incident moved into governance.

Board oversight is often described in high-level risk language. A cloud metadata breach requires more technical fluency. Directors do not need to know every packet path. They do need enough understanding to ask whether cloud roles were least-privileged, whether metadata access was constrained, whether data-loss alerts were handled, whether WAF configurations were tested, whether internal audit had cloud expertise, and whether migration risk assessments were complete.

The OCC orders make that point indirectly by focusing on risk assessment, control inventory, testing, audit, and board reporting. A board cannot oversee what management cannot measure. If the organization cannot show which cloud controls protect which sensitive data, oversight becomes generic assurance. After Capital One, generic assurance was not enough.

Board evidence should also distinguish migration risk from steady-state risk. Capital One was known for aggressive cloud adoption. Cloud adoption can improve resilience and security when governed well. But migration creates transition risk: old controls may not map cleanly, teams may assume provider controls cover customer duties, audit methods may lag architecture, and identity scope may expand faster than review. A board should see that transition risk explicitly.

The proxy disclosure of outside experts and committee activity is valuable as governance response. The deeper question is what evidence those activities produced. Did control inventories change? Were role permissions reduced? Were alerts retuned? Did internal audit test cloud-specific paths? Did management report closure metrics? Did the board receive proof that metadata-access risks were reduced? The public record cannot answer every detail, but the regulator orders explain the expected categories.

Detection is a control, not an afterthought

The breach record placed detection squarely inside accountability. The OCC civil money penalty order discusses alert disposition and control concerns. The public technical path involved data access and copying that should have been governed by monitoring and response. A cloud environment can generate extensive logs and alerts, but those are useful only if teams understand, prioritize, and act on them.

Security automation matters here. Cloud controls can detect unusual API calls, anomalous data access, suspicious credential use, and unexpected network paths. But automation can also create alert volume, false positives, and unclear ownership. If an alert is generated and not acted upon, the control has failed operationally even if it existed technically. The accountability question is not "was there a tool?" It is "did the tool produce action in time?"

Least privilege and detection reinforce each other. Narrow permissions reduce what stolen role credentials can access. Strong monitoring detects abnormal use of those credentials. Metadata restrictions make credential theft harder. WAF and application-layer controls reduce SSRF paths. Data-loss controls watch for unusual copy behavior. No single control is enough; the chain is the defense.

Cloud customers sometimes treat provider-native security features as available capacity rather than active controls. A feature must be configured, monitored, staffed, and tested. A policy must map to a business owner. An alert must have an escalation path. A board report must show whether the control worked. Otherwise cloud security becomes a catalog of possible protections rather than an operating system of actual protections.

The Capital One incident is therefore a lesson in operational control. A contract can say the customer owns configuration. Documentation can describe metadata-service defenses. Regulators can require control inventories. None of that matters unless the organization can prove that risky paths are constrained and that suspicious activity is handled before large-scale data copying occurs.

The provider also learned from the path

AWS's IMDSv2 materials show provider-side learning without deciding the Capital One case. The November 2019 security post on EC2 Instance Metadata Service Version 2 explained a session-oriented approach, request method changes, and additional defense-in-depth against open firewalls, reverse proxies, and SSRF vulnerabilities. The later IMDSv2 by default roadmap moved the default posture further.

This matters because shared responsibility does not mean provider responsibility is static. Providers can make safer defaults, stronger controls, clearer documentation, and better guardrails. Customers still configure and govern their workloads, but provider design can reduce the chance that one customer mistake becomes a major exposure path. Defaults are accountability tools.

The best cloud accountability model is not blame transfer. It is control improvement on both sides. Customers should reduce permissions, constrain metadata access, test WAF configurations, and monitor data movement. Providers should make secure defaults easier, dangerous patterns more visible, and incident evidence easier to collect. Regulators should require financial institutions to prove they are doing their part.

Capital One's case is often invoked to teach "the customer owns configuration." That is true but incomplete. A mature lesson also asks how providers can design services so common mistake patterns are harder to exploit. IMDSv2 is an example of that direction. It does not retroactively decide fault; it shows the value of defensive design after a real-world abuse path becomes public.

Customers should also avoid treating safer defaults as a reason to relax. IMDSv2 and related controls help, but they do not eliminate the need for least privilege, application security, WAF testing, logging, alert handling, and data minimization. Defense in depth means the organization does not bet the whole outcome on one boundary.

Contract versus control remains the durable lesson

The durable lesson is that a cloud contract can define responsibilities, but only evidence can prove control. In Capital One's case, the evidence record spans company notice, DOJ prosecution, OCC and Federal Reserve orders, FFIEC guidance, AWS documentation, SEC filings, board disclosures, Canadian regulator notice, and civil settlement documents. Each record answers part of the question. None alone is enough.

For a bank, the practical control proof should include a cloud control inventory tied to sensitive data, regular testing of WAF and application paths, enforced metadata protections, least-privilege role design, data-loss monitoring, alert disposition evidence, internal-audit coverage, board reporting, and customer-notice readiness. Those are not abstract security ideals. They are the control categories the incident made visible.

For cloud providers, the lesson is to keep improving defaults and documentation around common abuse paths. For regulators, the lesson is to ask for proof before and after migration. For customers, the lesson is that a well-known cloud provider does not eliminate customer duties. For affected individuals, the lesson is less comforting: their data can be exposed through architecture decisions they never saw.

The final accountability question is not whether cloud is safe. It is whether the organization using cloud can show that its contracts, controls, alerts, permissions, and board oversight match the way cloud actually works. Capital One made that mismatch public. The repair record has to make the match visible.

Remediation should be measured by reduced ambiguity

A strong post-incident repair program reduces ambiguity. Before the incident, an organization may believe that cloud controls, WAF settings, IAM roles, and monitoring are adequate. After the incident, it should be able to prove which assumptions changed. Which roles were narrowed? Which metadata settings changed? Which WAF testing improved? Which alerts gained owners? Which data stores received stronger conditions? Which audit steps became routine? Which board metrics show closure?

Capital One's regulatory orders and later order termination provide public milestones, but public readers cannot see every internal control test. That is normal. Still, the categories of repair should be visible. A bank does not have to publish sensitive architecture diagrams to show that it strengthened cloud governance. It can disclose oversight structures, control programs, audit coverage, and regulator closure where appropriate.

Ambiguity is costly after a breach. Customers wonder what was exposed. Regulators wonder whether migration controls were adequate. Investors wonder how much remediation will cost. Engineers wonder which patterns are still allowed. Auditors wonder whether evidence is complete. Reducing ambiguity is therefore part of repair.

The contract-control mismatch returns here. If a contract says the customer owns configuration, but the organization cannot tell which configurations protect sensitive data, the contract has not produced operational accountability. If a board says it oversees cyber risk, but cannot connect a cloud role to data exposure, oversight is too abstract. If a provider says it offers secure primitives, but defaults allow common mistake paths to remain easy, product accountability is incomplete.

The post-incident standard should be practical: every sensitive cloud data path should have a named owner, least-privilege policy, logging control, alert owner, test schedule, and board-visible status. That is what turns shared responsibility from a diagram into a working control system.

The case still matters because cloud use is ordinary now

Capital One's breach remains relevant because cloud use is now ordinary banking infrastructure. The exceptional part is not that a bank used cloud. The exceptional part is that the public record forced everyone to inspect the distance between cloud responsibility diagrams and real operational control. That distance still matters for every financial institution that uses cloud services, managed analytics, identity services, data lakes, container platforms, or serverless workloads.

Financial institutions often face pressure to modernize quickly. Cloud can improve speed, resilience, and security capability. It can also create new failure modes if governance lags. Regulators are not asking banks to avoid cloud. They are asking banks to understand and control cloud. The difference is crucial. Avoidance is not the goal; evidence-based operation is.

The incident also matters for non-banks. Any organization using cloud metadata credentials, IAM roles, WAFs, and object storage faces similar control questions. The data categories may differ, but the accountability chain is familiar: application path, metadata access, credentials, permissions, storage, detection, notice, repair. Capital One made that chain famous because the affected population and regulator response were large.

The final lesson is humility. Cloud architecture can be robust, but only if organizations treat configuration, identity, detection, and governance as live controls. Shared responsibility assigns duties. It does not perform them. The public record after Capital One shows what happens when the gap between assigned duty and practical control becomes visible to customers, regulators, courts, and investors.

Migration control should be tested before sensitive scale

The OCC's civil money penalty order and cease-and-desist order make cloud migration governance central to the Capital One record. That is important because migration risk is different from steady-state risk. During migration, organizations translate old control assumptions into a new operating model. Firewalls, identities, storage paths, logs, audit routines, and incident-response playbooks all change shape. If control translation is incomplete, sensitive data can reach cloud scale before the evidence program catches up.

Testing before sensitive scale should include adversarial paths, not only deployment checks. Can an application reach metadata credentials? Can those credentials list or read sensitive storage? Are permissions limited to business need? Can a web-application firewall rule be bypassed? Would data-loss tools notice unusual access? Would alerts reach an accountable team? Would internal audit understand the cloud path well enough to challenge it? These questions are practical versions of the regulator's governance language.

The FFIEC cloud risk-management statement gives a broader supervisory frame: financial institutions remain responsible for governance, architecture, access, monitoring, and resilience when using cloud. That principle should be applied before large data migrations, not only after breach response. A bank should be able to show that cloud controls were tested under realistic misuse paths before sensitive applicant or customer data accumulated behind them.

Migration evidence should also be versioned over time. A control that passed early in a program may no longer cover a changed architecture, new service, expanded role, or different data store. The Capital One case shows why board and audit teams need continuing visibility, not a one-time migration approval. Cloud adoption is a program, not a ceremony.

The goal is not to slow modernization for its own sake. The goal is to prevent modernization from outrunning proof. Cloud can give a bank better tools than a legacy environment, but only if those tools are configured, tested, monitored, and governed in the actual architecture that holds customer data.

Least privilege should show what cannot happen

Least privilege is often described by listing what a role can do. After a metadata-path breach, the more important question is what a role cannot do. Can a role tied to one application list unrelated storage? Can it read production data when it should write logs only? Can it cross account boundaries? Can it access older data stores that were kept for analytics or compliance? Can it perform actions outside business hours or from unexpected paths? Least privilege is proven by negative space.

AWS documentation on IAM roles for Amazon EC2 and IAM best practices provides the current technical background for role-based access and permission discipline. The Capital One public record does not let outside readers inspect exact 2019 role policies. It does, however, show why permission scope mattered. If temporary credentials are obtained through a metadata path, the role's allowed actions determine the blast radius.

A mature cloud program should therefore test roles from an attacker's perspective. Suppose this application role is stolen. What data can it read? What can it list? What can it copy? What logs fire? Which condition keys or network controls limit its use? Which sensitive buckets reject it? Which alert owner sees the abnormal access? How quickly can the role be disabled? These tests turn least privilege from a policy phrase into operational evidence.

Negative testing should reach the board in simplified form. Directors do not need policy documents with every permission. They need to know that high-risk roles are inventoried, sensitive data paths reject unrelated roles, exceptions expire, and automated tests catch privilege creep. Internal audit should be able to sample those claims. Regulators should be able to see that the institution is testing what cannot happen, not merely documenting what should happen.

This is where shared responsibility becomes concrete. The cloud provider offers IAM tools and metadata controls. The customer designs and tests role scope. Regulators ask for proof. If any of those layers remains abstract, the next metadata path will again expose the difference between assigned responsibility and practical control.

Settlement closure and control closure are different endpoints

The settlement documents at the Capital One data breach settlement archive, including the final approval order, show one form of public closure for consumer claims. They do not show every control repair. Legal closure and control closure serve different functions. A settlement can compensate, provide services, and resolve claims. It does not by itself prove that every cloud path has been redesigned, every alert process improved, or every board metric made durable.

The same is true of supervisory milestones. The OCC's later termination notice matters because it marks the end of a specific corrective order. It does not erase the original findings or remove the need for ongoing cloud governance. A bank's cloud environment continues to change after an order ends. New services, roles, data stores, analytics platforms, and third-party integrations can recreate old failure patterns in new forms.

For customers, closure is also different. A person whose application data was exposed may receive notice, credit monitoring, settlement benefits, or identity-theft services. That support matters, but it does not give the person visibility into whether the bank's cloud control system is stronger. The affected individual has to trust that regulators, auditors, and the institution's board are maintaining pressure after public attention fades.

Capital One's 2019 Form 10-K and 2020 proxy statement show how incident response, cost, insurance, litigation, and board oversight entered corporate disclosure. The strongest continuing accountability would connect those disclosures to durable measures: cloud-control testing cadence, audit findings, role-scope reduction, alert-response metrics, and regulator closure where applicable.

The public should resist the temptation to treat the last court order or regulator notice as the end of the story. It is an endpoint for a legal or supervisory process. The operating question remains alive: can the institution still prove that cloud responsibility is matched by cloud control?

Data minimization would have changed the impact ledger

The Capital One incident is usually discussed through configuration, metadata, and IAM. Data minimization deserves equal attention because permissions and metadata paths only become customer harm when sensitive data is reachable. Capital One's SEC-filed notice and maintained incident page described application and account-related data categories. Those categories show that the question was not only how an attacker reached storage, but why each class of data was present and reachable in the affected environment.

Financial institutions keep data for legitimate reasons: underwriting, servicing, legal duties, fraud controls, customer support, analytics, and regulatory expectations. But every retained field needs a control story. If older application data, credit attributes, contact data, or identifiers remain accessible to a role that can be reached through an application path, the retention decision has current security consequences. A least-privilege program that ignores retained data volume is incomplete.

Data minimization also changes detection. Smaller, better-classified data stores make abnormal access easier to see. If sensitive records are scattered across broad buckets or historical stores, alerting becomes noisier and investigation slower. If data is segmented by purpose, retention period, and sensitivity, a stolen role has less to reach and defenders have a clearer map.

The Canadian notice context from the Office of the Privacy Commissioner of Canada, which announced a Capital One investigation, also shows why data categories matter across jurisdictions. A bank may operate one cloud program, but affected people and regulators experience the event through specific data fields, residency, and notice duties. Minimization reduces the number of people pulled into that multi-jurisdiction record.

The cloud-control lesson is therefore not only "block metadata abuse." It is "make metadata abuse less valuable." Narrow roles, hardened metadata access, tested WAFs, and strong alerts are essential. So is reducing the sensitive data available to any one path. That is how technical controls and privacy governance meet.

Cloud governance should make ownership visible

The final operating lesson is ownership. A cloud environment can contain many correct technical parts while still leaving responsibility diffuse. One team owns an application, another owns IAM patterns, another owns data classification, another owns WAF rules, another owns logging, and another owns audit response. When an incident crosses those boundaries, "shared responsibility" can become shared ambiguity unless ownership is explicit before the event.

Capital One's record shows why ownership needs to be mapped to data paths, not only to teams. For each sensitive workload, the institution should know who owns the application entry point, who approves metadata access patterns, who reviews role permissions, who monitors storage access, who validates alerts, who accepts exceptions, and who reports unresolved risk to governance forums. If one path can reach applicant or customer data, that path should have a named control owner and a named business owner.

This is also how cloud maturity should be measured. A mature program does not merely say that policies exist. It can show recent tests, role reductions, exception expirations, alert response times, audit samples, and board-level risk decisions. It can explain why a retained data set still exists and why a given application role cannot reach it. It can show that provider-side defaults, such as stronger metadata-service protections, have been adopted rather than admired from a distance.

The accountable cloud organization therefore treats architecture diagrams as governance artifacts. They should be current enough for responders, clear enough for auditors, and specific enough for executives to understand where high-impact data can be touched. Cloud responsibility is real only when the people with authority over each part of the path are visible.