The Breach You Heard About Today Happened More Than Four Years Ago

Here is the number that changed how I think about breach notification, from our own catalog:

The median gap between a breach happening and that data surfacing publicly is 1,591 days. More than four years.

Not the tail. Not the worst case. The middle of the distribution, across 776 breaches. Half of everything in our index took longer than that to surface. This post is the analysis behind that number, what it does and does not mean, and why it quietly breaks the way most people do breach hygiene.

The method

Every entry in our catalog has two dates: when the breach happened (breach date) and when the data became publicly searchable in our index (added date). Subtract, take the median across all 776 entries. That is the whole method, and you can reproduce it below.

The distribution, roughly: the fastest entries were indexed 3 days after the breach. The slowest took 5,974 days, over sixteen years; our oldest breach (gPotato, 2007, 2.1 million records) took well over a decade to surface in usable form. The median sits at 1,591 days.

The middle is one number; the shape around it is the argument. Only 14 percent of these breaches surfaced inside 90 days, while 78 percent took over a year and 36 percent took over six. Slow is not the tail of this distribution. Slow is the distribution.

And the median refuses to move. We computed it at 763 entries: 1,591 days. Thirteen breaches later, at 776: still 1,591 days. I would love to report the number drifting down as disclosure gets better. It is not drifting anywhere.

The tallest bar is the first year, 167 breaches, and that is the good news. Everything to the right of the median line, more than half of the chart, is a breach whose victims had at least four years of not knowing.

What the number means

Between the breach and the surfacing, the data was not sitting idle. Stolen data moves through private trading first: sold, traded, merged into combolists, used quietly. Public surfacing is often the last stop, the point where the data has been squeezed and gets dumped or leaked onward.

Which produces the uncomfortable inversion: by the time you can find out, attackers have usually had years. Your defensive window does not open when the breach happens; it opens when the data surfaces. The only variable you control is how fast you act once it does.

What the number does not mean (the caveats)

• It is not “companies take 4 years to disclose.” Disclosure and surfacing are different events. Many companies disclose promptly; the data often circulates privately long after, and some breaches surface that were never disclosed at all. Our measurement is when data became publicly searchable with us, which is the date that matters to the person exposed, but it is an index property, not a disclosure-speed metric.
• Recent years look faster than they are. A breach from 2025 can only show a lag of at most a year so far. Old breaches have had time to surface slowly; new ones have not. The median will drift as today’s silent breaches surface in 2028.
• Some entries are compilations (combolists), whose “breach date” is fuzzier by nature; how to read the different types.

A number with its limits stated is worth ten without.

What this breaks

The one-time checkup. “I checked a breach site once and I was clean” has a shelf life of exactly one day. Clean means nothing surfaced yet; four-plus years of median lag means your 2024 breach may become findable in 2028.

The news-driven response. Acting only when a breach makes headlines means acting at the end of the pipeline, years after the attackers started.

What replaces both is boring and effective: standing monitoring. Subscribe once, get told the day your address surfaces in anything new, act inside the only window you get. That takes a minute and costs nothing, and it is the entire reason the alert feature exists. If you look after a company domain rather than one inbox, the same standing watch exists for domains, also free.

Mid-read check, if you have never looked: xposedornot.com, ten seconds, no signup. If something comes back, here is what to actually do.

Reproduce it yourself

curl -s "https://api.xposedornot.com/v1/breaches" > breaches.json

python3 - <<'EOF'
import json, statistics
from datetime import datetime
d = json.load(open('breaches.json'))['exposedBreaches']
gaps = []
for x in d:
    b = datetime.fromisoformat(x['breachedDate'])
    a = datetime.fromisoformat(x['addedDate'])
    days = (a - b).days
    if days >= 0:
        gaps.append(days)
print("entries:", len(gaps))
print("median days:", statistics.median(gaps))
print("min:", min(gaps), "max:", max(gaps))
EOF

Numbers in this post are as of August 19, 2026; the catalog grows weekly and the median will move. Run it fresh; that is the point of a public API.

Next in this series: which industries actually get breached most (the answer flips depending on how you count). The RSS feed or a free alert will bring it to you.

And if receipts-included analysis is your kind of security content, drop us a star on GitHub. It helps others find the project, and honestly, it makes our day.

Appendix: Sources and references

• All figures: api.xposedornot.com/v1/breaches, script above, computed 2026-08-19. 776 entries; median 1,591; min 3; max 5,974. Distribution: 109 under 90d (14.0%, stated 14), 609 over 365d (78.4%, stated 78), 283 over 6yr (36.4%, stated 36). All rounded DOWN per house rule.
• gPotato entry: api.xposedornot.com/v1/breaches?breach_id=gPotato

—