Capital One reported unauthorized access on 22 and 23 March 2019, caused by a configuration vulnerability, and learned of it on 19 July 2019 after an outside researcher reported it. A useful way to learn from it is to ask whether your own controls would have caught a similar gap sooner.
What do we know for sure?
We rely on Capital One's own incident page. It says an outside individual gained unauthorized access on March 22 and 23, 2019 through a configuration vulnerability. An external security researcher reported it through the company's Responsible Disclosure Program on July 17, 2019, and Capital One determined the incident on July 19. About 100 million individuals in the U.S. and about 6 million in Canada were affected. The company says credit card account numbers and login credentials were not compromised (Capital One).
Regulators later acted. The OCC announced an $80 million civil money penalty on 6 August 2020, saying the banks did not establish effective risk assessment processes before moving significant information technology operations to the public cloud, and did not correct deficiencies in a timely manner (OCC).
We did not retrieve the criminal complaint ourselves, so we leave out technical details beyond those two sources. Reports describe a misconfigured firewall, but we have not confirmed the mechanism from a primary document.
Why this is a checklist and not a blame story
Cloud misconfiguration is routine, and any large organization with many accounts and changes will have some. The question is not whether a gap can appear. It is how long it stays and how much an attacker can do with it. The gap between March and July here is the number to think about.
The checklist
Answer yes, no or unsure for each. Every "unsure" is a finding.
Configuration
- Do you scan cloud configuration continuously, not only at deployment?
- Is every internet-facing component on an inventory with an owner?
- Do changes to firewall and gateway rules require review?
Access
- Are roles attached to workloads limited to the data that workload needs?
- Can a compromised web-facing workload list or read broad storage?
- Do you review role permissions on a schedule, and do you remove unused ones?
Detection
- Do you log API calls and storage access, and does someone read unusual patterns?
- Would an alert fire if one identity read a very large volume of objects?
- Is there an alert for access from unusual locations or anonymizing services?
Data
- Do you know where sensitive records sit, and for how long you keep them?
- Is sensitive data tokenised or encrypted in a way that limits what a read-only intruder gets?
Intake
- Is there a published way for researchers to report problems, and does it reach a person fast?
- Do you track time from report to triage to fix?
What does the intake step teach?
The external report is how this one surfaced. A disclosure channel that is monitored is a detection control. We cover what a policy should say in a separate post on vulnerability disclosure.
What to do
- Run the checklist with your cloud, security and application leads in one room.
- Turn every "unsure" into a ticket with an owner and a date.
- Add continuous configuration monitoring for internet-facing components.
- Reduce workload role permissions to the minimum and test the result.
- Alert on large or unusual reads of sensitive storage.
- Publish a disclosure channel and measure how fast it gets triaged.
- Reduce retained sensitive data you no longer need.
Quick check
What caused the Capital One incident?
Capital One's own page attributes it to a configuration vulnerability that an outside individual exploited. We did not confirm further technical detail from primary sources.
Is a dependency scanner the right control for this type of incident?
Not by itself. This was a cloud configuration issue. Configuration monitoring, least privilege and detection matter more here.
Sources
Last reviewed: 18 October 2026.
