Capital One’s cloud penalty was a verdict on sequencing

The week

Capital One had been, for years, one of the loudest voices in banking for moving to the public cloud. In the first week of August 2020, regulators sent it a message about how it had made that move.

On August 6, 2020, the Office of the Comptroller of the Currency assessed an $80 million civil money penalty against Capital One’s two national bank subsidiaries. The OCC is the federal agency that charters and supervises national banks. It also entered a cease-and-desist order, a formal instruction that tells a bank to stop an unsafe practice and fix it under the regulator’s watch. The same day, the Federal Reserve issued a parallel cease-and-desist order against Capital One Financial Corporation, the holding company that owns the banks.

The OCC’s complaint was specific. It said the bank had failed to establish effective risk assessment processes before migrating significant information technology operations to the public cloud. The “public cloud” means computing power and storage rented from a large outside provider and reached over the internet, rather than run in the bank’s own data centers. The OCC also said Capital One had failed to correct deficiencies in a timely way.

The legal hook was a familiar one. The OCC found that these failures were unsafe or unsound practices. It also found noncompliance with the Interagency Guidelines Establishing Information Security Standards, the appendix to the OCC’s rules that implements the safeguarding duties of the Gramm-Leach-Bliley Act for national banks. Those guidelines had been in place for roughly two decades. Nothing about the cloud required a new rule; the old one was enough.

The two OCC documents did different jobs. The penalty order settled the money, payable to the U.S. Treasury. The cease-and-desist order set the work. According to published summaries, the order required a compliance committee of directors and a comprehensive action plan. It also called for a stronger risk assessment process, a specific risk assessment for cloud operations, and better internal audit and audit reporting to the board. The OCC’s findings, as summarized by law firms at the time, faulted internal audit for missing control weaknesses and the board for not acting effectively on what it was told. The Federal Reserve’s order asked the holding company to strengthen board oversight, risk management and internal audit.

The trigger for all of this was a breach Capital One had disclosed a year earlier, in July 2019. According to the bank, the intrusion took place on March 22 and 23, 2019. An outsider exploited a misconfigured web application firewall to obtain credentials and copy data from cloud storage. A web application firewall is a filter placed in front of a website or app that screens incoming traffic for attacks. “Misconfigured” means one of its settings was wrong, so the filter could be tricked into fetching things it should never have touched. Through that gap, the intruder got hold of credentials, the digital keys that let software prove it is allowed to open a door, and used them to copy files.

The bank said the incident affected about 100 million people in the United States and about 6 million in Canada. Most of the data came from credit card applications submitted between 2005 and early 2019. Capital One said about 140,000 U.S. Social Security numbers, about 80,000 linked bank account numbers of secured card customers and about 1 million Canadian Social Insurance Numbers were exposed. It said no card account numbers or login credentials were taken.

Perhaps the most uncomfortable detail for any board: Capital One did not discover the intrusion itself. An outside party reported the configuration weakness through the bank’s responsible disclosure program on July 17, 2019, almost four months after the data was copied. The bank confirmed the intrusion two days later. The person responsible, a former employee of the cloud provider, was arrested at the end of that month.

The timing of the orders mattered too. Only three months earlier, on April 30, 2020, the Federal Financial Institutions Examination Council had issued a joint statement on security in a cloud computing environment. That statement introduced no new expectations. It reminded institutions that cloud security is shared between provider and customer, and that management should not assume controls exist because a system runs in the cloud. By August, many banks were also moving faster than planned, because the pandemic had pushed staff and customers online.

The August 2020 actions were therefore about much more than one wrong setting. The question was whether the bank’s risk management had kept pace with one of the most ambitious technology programs in the industry, and the regulators concluded that it had not.

Capital One was one of the most public advocates of moving a large bank to the public cloud. That made the August 2020 orders easy to read as a judgment on the cloud itself. Plenty of executives at other institutions read them exactly that way, and some used them as a reason to slow down.

The text says something narrower and more useful. The bank changed its operating model faster than its risk management could keep up, and it let known weaknesses age. That is a story about sequencing, about doing things in the right order, and it applies to any large change program, cloud or otherwise.

The argument runs in seven steps. First, what actually changes when a bank rents its computers. Second, what the regulators objected to, and on what legal basis. Third, why a technical error is best read as a governance failure. Fourth, the costs that land outside IT. Fifth, what a defensible migration gate contains. Sixth, where programs slip and which report keeps them honest. Seventh, the handful of questions that show a board whether a migration is under control. The first three explain the failure, the fourth prices it, and the last three describe the remedy.

What changes when a bank rents its computers

For most of banking history, a bank’s computers lived in buildings the bank owned or leased. The bank bought the machines, hired the people to run them, and controlled who could walk in the door. If you wanted more capacity for a busy season, you ordered more hardware months in advance.

The public cloud changes that arrangement. A handful of very large providers, often called hyperscalers, run enormous data centers around the world and rent out computing power, storage and ready-made software services by the hour or by the gigabyte. A bank can start a new server in minutes, store data almost without limit, and switch things off when it no longer needs them.

The appeal is real. Teams can build and test new products faster. Capacity can grow for a busy weekend and shrink afterward. The provider handles a great deal of the physical security and hardware maintenance that used to fall on the bank’s own books.

But one thing does not move to the provider: responsibility for how the bank sets up and uses those rented services. The industry calls this the shared responsibility model. The provider secures the underlying infrastructure, meaning the buildings, the hardware and the core software that runs it all. The customer secures what it configures, meaning who is allowed to access what, which data is stored where, and how each service is set up.

Using the cloud is like renting space in a very well-guarded office tower. The landlord runs the lobby security, the cameras and the fire systems. But if you leave your own office door propped open and the filing cabinets unlocked, the landlord’s guards will not save you. That division of duties is at the heart of what went wrong.

Three terms worth knowing

• Configuration is the collection of settings that decides how a service behaves: who can reach it, what it can see, what it logs. In the cloud, there can be thousands of such settings across a large estate, and each one is changed by a person or a script.
• Identity and roles are how the cloud knows who, or what, is asking for something. People have identities, and so do pieces of software. A “role” is a bundle of permissions that a piece of software can take on, such as “read files from this storage area.”
• Credentials are the proof that goes with an identity, like a password or a digital key. Whoever holds the credential can do whatever the role permits.

With those three ideas in hand, the Capital One story becomes easy to follow. A filter in front of an application had a wrong setting. An outsider used that wrong setting to get hold of the credentials for a role. That role had permission to read stored data. The outsider used it to copy that data. Each step is mundane. Together they produced one of the largest bank data breaches of its time.

How the chain worked, step by step

Public analyses of the criminal complaint describe the mechanism in more detail. Each virtual server in the provider’s cloud can ask a local metadata service for facts about itself. One of those facts is a set of temporary credentials for the role the server runs under. The design is convenient, because software on the server never needs a stored password.

The firewall could be induced to forward a request on the attacker’s behalf. Security researchers usually describe this as server-side request forgery. The forwarded request went to the metadata service, which handed back the role’s temporary credentials. From outside, the attacker then used those credentials to list storage areas and copy their contents. The complaint referred to more than 700 folders or buckets of data.

Three separate conditions had to hold at once. The firewall had to accept and forward the crafted request. The metadata service had to answer it without any extra proof. And the role had to be able to read customer data that a firewall had no business touching. Remove any one of the three and the chain breaks. For that reason a single “root cause” is the wrong frame. Layered controls exist so that one error does not become a breach.

What moves, and what does not, depends on the service model

The share of responsibility a bank keeps depends on what it rents. With infrastructure services, the bank configures servers, networks, storage and identities itself. With platform services, the provider runs more of the stack, but the bank still decides who can reach the data. With software delivered as a service, the bank mostly configures users, permissions and data sharing.

Capital One had chosen the most demanding model, building much of its own software on rented infrastructure. That choice gives the most flexibility and the largest configuration surface. A community bank or credit union whose core system is hosted by a core processor sits in a different position. Its exposure runs mainly through that vendor and through the settings it controls in software it subscribes to. The principle is the same, but the work lands in contract oversight more than in engineering.

One further change is easy to miss. In a data center, many controls were physical or slow to alter: a firewall appliance, a change ticket, a cable. In the cloud, almost everything is an instruction sent to an interface. Changes that once took weeks now take seconds, and they can be made by more people. That speed is the benefit. It is also the reason a bank’s control design has to move from periodic review to continuous enforcement.

What the regulators objected to

The OCC named two failures. The first was the absence of an effective risk assessment before significant operations moved. The second was slow remediation of deficiencies, including concerns that internal audit had raised. Neither finding mentions a provider, a service or a technology choice.

That last point deserves a pause. The regulator did not say “the cloud is dangerous” or “this provider is unreliable.” Its point was narrower. The bank had not done its homework before moving, and had not acted fast enough when problems were identified. Those are management failures that could happen in any large program, whether it involves cloud computing, a new payments platform or an acquisition.

The rule behind the finding

The finding rested on information security guidelines that the banking agencies adopted under the Gramm-Leach-Bliley Act around the turn of the century. For national banks and federal savings associations, they appear as an appendix to the OCC’s safety and soundness rules. The Federal Reserve and the FDIC have parallel versions for the institutions they supervise. Credit unions have their own counterpart in the National Credit Union Administration’s rules on safeguarding member information.

The guidelines are short and principle-based. They ask a bank to have a written information security program, approved by the board. They require the bank to assess reasonably foreseeable risks, design controls in response, test them, oversee service providers and adjust the program when circumstances change. A major change in where systems run is exactly the kind of change the guidelines expect to trigger a fresh assessment.

For other kinds of firm, the same idea arrives through different rules. Broker-dealers and registered investment advisers answer to the SEC’s Regulation S-P, which requires written policies to safeguard customer records. Broker-dealers also face separate SEC record-keeping rules about how certain records must be preserved. Organizations should check with counsel on which of these apply to them and how. The structure of the duty is similar everywhere: assess before you change, then prove the controls work.

Why pace became the issue

That framing matters for how a bank plans. Supervisors accept that large programs carry open issues. Nobody expects a multi-year technology transformation to be flawless. They are much less tolerant of a program whose pace is set by business deadlines while risk assessment runs as a parallel workstream that may or may not finish first. In that arrangement, the bank has chosen to accept unassessed risk, whether or not anyone wrote that decision down.

Consider how this tends to play out. A program has a target: a certain number of applications moved by year-end, a data center lease that expires, a savings figure promised to the board. The risk team is asked to assess each move, but it is understaffed and the program will not wait. Applications move with assessments “in progress.” Auditors flag issues; the issues go onto a tracker; the tracker grows. Nobody decides to accept the risk. It simply accumulates.

What a consent order demands in return

The order also put the board on the hook for oversight of remediation. That moved cloud risk from the CIO’s portfolio to the governance agenda. Orders of this kind usually follow a pattern. A committee of directors monitors compliance. Management writes an action plan with dates. The regulator reviews the plan and can send it back. Progress reports go to the regulator on a fixed schedule, and the order stays open until the regulator is satisfied that the fixes are sustained.

Each of those steps consumes senior time. Directors attend extra meetings. Internal audit validates each remediation item before it can be reported as closed. Outside reviewers are often engaged to test the work. New initiatives compete for the same people who are fixing what the regulator flagged. The penalty drew the headlines, but the order, with its years of remediation, was the heavier cost.

Banks reading the order from outside could draw a precise conclusion. Examiners now had a public template for cloud findings. They would ask whether an assessment existed before a move, who approved it, whether audit had looked at the new environment, and what happened to the issues it raised. Any bank in the middle of a migration could expect those questions at its next examination.

Why the technical failure was a governance failure

The root cause was a misconfigured component that let an attacker reach a credential with more access than its function needed. Errors like that are routine in any large cloud estate. Thousands of engineers make thousands of changes. If a control depends on each of them getting each setting right, it will fail on a schedule nobody chooses.

At that scale, human error is a certainty, and well-run organizations build checks into the process rather than relying on memory. The question for leadership is whether the organization is designed to catch mistakes quickly and limit the damage when they slip through.

Three governance decisions lie underneath the technical one:

• Who owns the baseline. Someone has to define what a correctly configured service looks like, encode it, and answer for drift. “Drift” is the slow wandering of real settings away from the approved standard as people make changes. In many banks this fell between a cloud platform team, security architecture and application owners, with no single name attached. When everyone owns something, nobody does.
• How service identities are scoped. The stolen credential belonged to a role, not a person. Roles accumulate permissions because broad access is faster to grant than narrow access is to design. A developer under deadline asks for access to “all storage” rather than working out which three folders the application really needs. Every unused permission is latent blast radius, meaning the extra damage an intruder can do once they get in.
• How quickly unusual access is noticed. Capital One learned of the breach from an outside tip, months after the data was taken. Bulk reads from storage by an identity that does not normally perform them are detectable. A piece of software that usually reads a handful of files suddenly copying a huge volume of data is exactly the kind of pattern monitoring tools can flag. Detection has to be specified, tuned and owned like any other control.

Why each decision tends to go unmade

Each of these decisions has a structural reason for being skipped. Baseline ownership crosses team lines, so it needs an executive to assign it. Nobody volunteers for a job whose main output is telling other teams they are out of compliance.

Identity scoping is slow, unglamorous work. Designing a narrow role means knowing exactly what an application does with data. That knowledge often lives with a vendor or a contractor who has moved on. Broad roles let a release ship on time, and the cost shows up only after an intrusion.

Detection suffers from a different problem. Alerts on bulk reads produce false positives at first, because legitimate batch jobs also read a lot of data. Tuning them takes weeks of analyst time. If no one owns that tuning, the alerts get muted or never written. The organization then has logging without monitoring, which is evidence for investigators afterward and little use beforehand.

The evidence a supervisor would look for

Each decision leaves a trail an examiner can test. For the baseline, it is a written standard, the code that enforces it, and a report of current exceptions with their age. For identities, it is a record of permission reviews and of permissions removed. For detection, it is the written use cases, the alerts they produced over a period, and how each one was resolved.

Where those artifacts do not exist, an examiner will conclude that the control does not exist either. A verbal assurance from an engineer is not evidence. That gap between doing something and being able to show it is often where findings begin.

The strongest objection, and why it does not hold

Some argued at the time that the intruder had unusual skill and inside knowledge of how the provider’s services worked. On that view, the breach was bad luck, and the bank was the victim of a rare adversary. The provider itself said its underlying services had not been compromised.

The objection fails on its own terms. The techniques were publicly documented, and prosecutors said the same person had also reached data at other organizations. Controls are supposed to work against capable attackers as well as careless ones. And the governance findings concerned assessment and remediation, which do not depend on who the attacker was.

Under the shared responsibility model, the provider secures the underlying infrastructure and the customer secures what it configures. The orders showed that supervisors will hold the bank to its half in full, regardless of how capable the provider is.

The bills that land outside IT

Capital One’s breach ended in a penalty, a remediation program and more than 100 million customers with less reason to trust their bank. Follow the consequences through the parts of the business a CEO or board actually answers for.

Money. The direct penalty was $80 million. But the larger costs of a breach and an enforcement order are spread out: the remediation program, independent reviews, consultants, legal work, and the slower delivery of everything else while senior people are tied up. Litigation adds another line. Capital One later agreed to a consumer class action settlement of $190 million, which it reached without admitting liability.

Customers. About 100 million people in the United States and about 6 million in Canada were affected. Every one of them is a relationship that now carries a little less trust. Customers rarely distinguish between a cloud provider’s error and their bank’s. To them, the bank lost their data. Notification, credit monitoring and call center volume follow directly, and each has a cost that rarely appears in the migration business case.

Regulators. An enforcement order changes the tone of the supervisory relationship. Requests become more frequent, examinations more pointed, and new initiatives may need more explaining before they go ahead. A bank under an open order also tends to find that its own appetite for risk shrinks. Management avoids anything that might create a new finding while the old ones are open.

Strategy. Perhaps the least visible cost is the opportunity cost. A bank that wanted to be known for technology leadership found its technology agenda partly set by a remediation plan. That is the opposite of what a cloud strategy is supposed to buy.

Reputation. The detail that the bank learned of the breach from an outside tip is the kind of fact that sticks. It invites the question every stakeholder asks after an incident: if you did not know, what else do you not know?

Who pays depends on the institution

The same failure would land differently elsewhere. A large public bank can absorb an $80 million penalty, though not the distraction. For a community bank or credit union, a comparable remediation program could consume most of its technology budget for years. The fixed costs of independent reviews and board reporting do not shrink in proportion to the balance sheet.

A broker-dealer would face a different mix. Its regulators include the SEC and FINRA, and customer data failures can lead to enforcement under Regulation S-P. A wealth manager would feel the client trust effect more sharply, because relationships are concentrated and personal. For a fintech that relies on a partner bank, the partner bank’s regulator may press the bank to tighten oversight of the fintech, with commercial consequences for the partnership.

How the business case should change

Migration business cases usually count data center savings, faster delivery and resilience gains. They rarely include the expected cost of a control failure, because it is hard to estimate. The Capital One orders gave finance teams a reason to add a line anyway: the cost of building the controls up front, set against the cost of remediation later.

That line does not need a precise probability. It needs an honest budget for the platform team, the identity work and the detection engineering. If the program cannot fund those, the timeline is wrong, and the business case should say so.

What a defensible migration gate looks like

A gate is a decision point that a workload cannot pass until defined evidence exists. A “workload” is a system or application together with its data, such as the mobile banking app, the loan origination system or the fraud models. Banks, credit unions and broker-dealers still moving workloads, or cleaning up what they moved in a hurry, can test their programs against five elements.

1. An assessment per workload class. Each class of workload, sorted by data sensitivity and criticality, passes a defined risk assessment before it moves. Second-line risk, the independent risk function separate from the business, signs off. For material systems, the board’s technology or risk committee sees the result.
2. Configuration enforced in code. Standards are applied automatically at deployment and checked continuously afterward. Rather than asking engineers to remember the rules, the platform refuses to create a storage area that is open to the internet. Exceptions carry an owner and an expiry date. The metric that matters is the count of resources out of baseline and how long they stay there.
3. Identity reviewed as rigorously as network design. Service roles get least-privilege reviews before go-live and on a schedule afterward. “Least privilege” means each identity gets only the permissions its job requires, and nothing more. Unused permissions are removed automatically after a set period.
4. Findings with clocks. Audit and risk findings tied to the migration carry dates, owners and escalation rules. A finding that passes its date without closure goes to the committee that approved the program, not back to the team that missed it.
5. Exit and recovery planning. Supervisory guidance on third-party risk expects institutions to understand concentration and plan for disruption. That applies to a hyperscaler as much as to a core processor, the outside company that runs many banks’ basic account systems.

What each element needs to run

Each element has an owner and a mechanism. The workload assessment is owned by the first-line technology risk team and approved by second-line risk. It works best as a short standard template, so the risk team is reviewing differences rather than reading essays.

Configuration enforcement is owned by the cloud platform team. It usually takes the form of policy rules that run when infrastructure is created and again on a schedule. The rules are versioned like software, and changes to them go through review. Security architecture writes the standard, the platform team encodes it, and internal audit tests that the code matches the standard.

Identity reviews are owned jointly by application owners and the identity team. Tooling can show which permissions a role has actually used over a period. The review then becomes a decision about the unused ones, which is much faster than reasoning from first principles.

The findings clock is owned by the program office and enforced by the risk committee. The rule that overdue items escalate upward, not sideways, is what gives it force. Exit planning is owned by the third-party risk function, with input from the business continuity team on which services must keep running if a provider fails.

One migration, done two ways

Suppose a regional bank is planning to move its customer data platform to the cloud by the end of the year. Under a gated approach, the program first classifies the platform as high sensitivity. Second-line risk reviews the design, finds that a reporting tool would have read access to all customer records, and asks for that access to be narrowed to the four tables the tool actually uses. The platform team’s automated checks catch two storage areas created without encryption and block them. Detection rules are written for unusual bulk reads before go-live, not after. The move slips by six weeks. The board risk committee is told why, and what was fixed.

Now take the same bank skipping those steps to hit the date. Everything works on day one. The broad reporting permission and the missing alert lie unnoticed until someone finds them, and the bank has no control over whether that someone is its own team or an outsider.

How the gate differs by institution

A large bank building its own applications on rented infrastructure needs all five elements in full, with engineering staff behind each. A community bank or credit union that mostly subscribes to software will run a lighter version. Its assessment focuses on the vendor’s controls and on the settings the institution itself manages, such as user access and data sharing. Its exit plan focuses on data portability and contract terms.

Broker-dealers have an extra check. Where records must be preserved under SEC rules, the gate should confirm how the cloud setup meets those requirements before the system moves. A wealth manager or adviser should confirm that client data shared with cloud tools stays within its written safeguarding policies. Fintechs working through partner banks should expect the bank to ask for this evidence as part of its own oversight.

The trade-offs are real

Each element creates a trade-off. Gates slow migrations, which delays the savings that justified them. Enforced configuration blocks some deployments, which frustrates engineering teams. Narrow identities create more access requests. A bank that wants speed and control has to fund the platform team that makes the controlled path the fast path. Without that funding, teams route around the gate, and the bank is back where Capital One was.

The case against gates, taken seriously

Critics of gating make a fair point. Heavy approval processes can push engineers toward shadow IT, where teams buy services on a credit card to avoid the queue. They can also lengthen the period in which a bank runs two environments at once, which carries its own risk and cost.

The answer is to make gates cheap rather than to remove them. A gate that takes a day because evidence is generated automatically is a different thing from one that takes a quarter because it relies on meetings. The orders did not object to speed. They objected to moving before the risk was understood.

Where programs slip, and the report that keeps them honest

Several patterns show up again and again in organizations that struggle with this.

• Treating the provider’s certifications as the bank’s controls. A provider’s security reports describe its half of the shared model. They say nothing about how the bank set up its own services.
• Reporting progress in applications moved, not risk retired. A dashboard that celebrates migration counts while open findings grow tells the board only half the story.
• Letting audit findings negotiate their own deadlines. When due dates slide by agreement between the team and the auditor, the board never sees the backlog.
• Building monitoring after the move. Detection added later tends to be added never. It belongs in the definition of “done.”
• Underfunding the platform team. Guardrails that are slow or clumsy invite workarounds. Good controls are fast enough that engineers prefer them.

Why each slip feels reasonable at the time

No single slip here starts as a bad decision. Relying on a provider’s certification feels efficient, because the reports are detailed and independently audited. The flaw is that they cover a different set of controls.

Counting applications moved feels like accountability, because it is a hard number. Extending an audit due date feels collaborative, because the team has a plausible reason. Deferring monitoring feels sensible, because the system is not yet carrying production traffic. Trimming the platform budget feels prudent in a cost review. Each choice is defensible alone. Together they produce the pattern the OCC described.

The report, line by line

A healthy program reports differently. The board receives a short, regular report. It shows how many workloads moved this quarter and how many passed their gate cleanly. It shows how many cloud resources are out of baseline, and for how long. It shows how many service roles had unused permissions removed, and which findings are past due. Each number has a named owner. The CIO and the chief risk officer present it together.

The definitions matter as much as the numbers. “Passed cleanly” should mean no exceptions granted at the gate. “Out of baseline” should count every resource, not a sample. Age should be measured from when drift was detected, not from when a ticket was opened. Past-due findings should show their original date, so that extensions are visible.

Internal audit should test the report itself once a year. If the numbers come from the same team whose work they measure, someone independent needs to confirm that they are complete. That test is cheap, and it is exactly what was missing when audit failed to surface weaknesses to the board.

Trend lines matter more than snapshots

A single quarter’s report says little. The useful signal is direction. Out-of-baseline counts should fall as enforcement matures. The oldest exception should get younger. Past-due findings should shrink to a short list. If migration volume rises while these measures worsen, the program is outrunning its controls again, and the committee should slow it.

The committee needs the authority to do that, written into its charter. A risk committee that can only note concerns will watch the trend lines worsen. One that can pause further moves until the oldest exceptions close changes behavior quickly, because the program team then owns the delay. That authority is rarely used. Its existence is what gives the report weight, since everyone knows the numbers can stop the program.

Second-line risk should also see the raw data behind the summary, not a curated slide. A short sample of individual exceptions, with their owners and stated reasons, shows whether the counts reflect real engineering problems or paperwork.

Sign-offs, a baseline owner and overdue findings show whether a migration is under control

A senior executive does not need to understand every cloud setting to hold a program to account. These plain questions tend to reveal whether sequencing is under control.

• Before a system moves, who signs off that its risks have been assessed, and can I see one of those sign-offs?
• Who, by name, owns the definition of a correctly configured cloud service, how many of our resources are out of that baseline today, and what is the oldest one?
• If a piece of software suddenly copied far more data than usual, would anyone notice before the copying finished, and who would be told?
• Which audit findings on this program are past due, and who decided to let them slip?
• Are we funding the platform team enough that following the rules is the fastest way for engineers to ship?

What a good and a bad answer sound like

Good answers are specific and come with documents. A sign-off is shown, with a date before the move. A named person owns the baseline and knows the oldest exception. The head of security operations can describe the bulk-read alert, when it last fired and what happened. Overdue findings are few, and each extension was approved by the committee, not by the team.

Weak answers share a texture. They describe intentions instead of evidence. They name teams instead of people. They answer the detection question with a description of logging. They treat overdue findings as a scheduling issue. Any one of them falls short of proof of a problem, but each is a reason to ask for the underlying material.

How often to ask

These questions are most useful at three points. Ask them when a program is approved, so the answers become commitments. Ask them each quarter while the migration runs. And ask them after any significant incident or audit finding, when the honest answers are most likely to have changed.

The comparison a CIO should put to the board is concrete. One option is a slower migration with gates. The other is a fast migration followed by a multi-year remediation program under a regulator’s supervision. In August 2020 the OCC put a price on the second option, and the price did not include the years of constrained strategy that followed.

With hindsight

Supervisors did not discourage cloud adoption after 2020. They raised the bar for evidence of control. Capital One itself kept going: by late 2020 it had closed its last owned data centers and run its applications mainly in the public cloud. The orders changed how it moved, not where.

The breach had a long tail. In December 2021 Capital One agreed to a $190 million settlement of the consumer class action, without admitting liability, and the court granted final approval in 2022. The person who carried out the intrusion was convicted by a federal jury in June 2022 on wire fraud and computer intrusion counts, and acquitted of some other charges. The sentence was time served and five years of probation, well below the prison term prosecutors had sought.

The regulatory orders ran longer. The OCC terminated its cease-and-desist order at the end of August 2022, about two years after entering it, ending the bank’s quarterly reporting on risk management and audit. The Federal Reserve ended its parallel action against the holding company in July 2023. From intrusion to the last order being lifted, the arc ran roughly four years. That is the real time cost of getting sequencing wrong, and it is longer than many technology strategies are meant to last.

Policy moved in the same direction. In February 2023 the Treasury Department published a report on the financial sector’s use of cloud services. It flagged limited transparency for due diligence, concentration among a few providers, a shortage of skilled staff, and particular strain on smaller institutions that struggle to get information about incidents affecting them. It imposed no new requirements, but it gave supervisors a shared vocabulary for the risks.

The federal banking agencies’ interagency guidance on third-party relationships, issued in June 2023, made lifecycle risk management of technology providers an explicit expectation for banks of all sizes. “Lifecycle” is the key word: regulators want to see diligence before a contract is signed, oversight while the relationship runs, and a plan for how it ends. A cloud provider is treated as a critical supplier, not as a utility that needs no thought.

Incident reporting tightened as well. The banking agencies’ computer-security incident notification rule took effect in 2022. It requires banks to notify their primary regulator within 36 hours of determining that a significant incident has occurred. It also requires bank service providers to tell their bank customers about significant disruptions. For public companies, the SEC adopted rules in 2023 that require prompt disclosure of material cybersecurity incidents. A bank that learns of an intrusion from an outsider now has less time to work out what happened before regulators and investors hear about it.

Providers changed their defaults too. Amazon Web Services introduced a hardened version of its instance metadata service, which requires a session token before it hands out credentials. In 2024 it made that version the only option for newly released instance types and let customers make it the default across their accounts. That closed off one link in the chain used against Capital One, for organizations that adopted it. It did nothing for older setups left on the earlier version.

Cloud misconfiguration and over-permissioned identities have remained among the most common causes of data exposure across industries. In 2024, a widely reported campaign against customers of the data platform Snowflake used stolen credentials to log into accounts that lacked multifactor authentication. The provider’s platform was not breached; customer settings were the gap. The basic mechanics have not changed: a wrong setting, a key with too much access, and nobody watching closely enough.

Configuration enforcement and identity analytics tools have matured, which means the excuse that such checks are hard to build has largely gone. What remains hard is the organizational part: deciding who owns the baseline, funding the platform team and giving findings real deadlines.

Some things in the original reading did not hold. The fear that the orders would chill cloud adoption across banking proved wrong. Banks large and small kept moving, and supervisors spent their energy on how they moved. The idea that the provider’s scale would make customers safer by default also proved only partly right. Providers did harden defaults, but each improvement still required customers to turn it on and keep it on.

The pattern the OCC described, where program velocity outruns assessment, has not gone away. By 2026 it recurs with AI services and data platforms in the place that infrastructure held in 2019. The pressure is familiar: business teams want new tools quickly, providers make them easy to switch on, and risk assessment struggles to keep up.

That history carries a reassurance as well as a warning. Banks that built gates for cloud have had a ready template to reuse. The same questions apply to any new platform: has it been assessed before it goes live, who owns its settings, who would notice if something went wrong, and what happens to findings that miss their dates.