12 August 2026 · 5 min read
How to Prove What Was Exposed During a Security Incident
One of the first questions after any security incident is some version of "what was actually exposed at the time." It sounds like it should have an easy answer. In practice, most teams can't answer it with any confidence - because the only thing they can check is what's exposed right now, and by the time anyone's asking, that's often already changed.
Why "current state" stops being useful exactly when you need it most
A dashboard, by design, shows you the present. Run a scan today and you get today's answer. That's fine for day-to-day monitoring - but the moment you're investigating something that happened last Tuesday, "here's what's open now" stops being the question. The service that mattered may have already been patched, the certificate already rotated, the port already closed - all good outcomes, and all of them erasing the exact evidence you now need.
Without a real historical record, what fills that gap is memory, scattered ticket comments, and whoever happens to remember making the change. That's not evidence, it's reconstruction - and it gets less reliable the longer the trail runs cold.
What an actual record looks like
Every scan SurfaceDiff runs is kept, not just the latest one. Drift is what lets you use that history directly: pick any past scan of a domain and see it exactly as it looked at that moment - which ports were open, what certificate was live, what DNS actually resolved. Or pick two points in time - a past date and today, or any two dates against each other - and get a direct, side-by-side answer to "what's actually different," not a guess based on what you remember changing.
There's nothing to turn on in advance. It's available the moment a domain has more than one scan in its history, which for an actively monitored domain is almost always already true by the time you'd need it.
A concrete walkthrough
Say something elsewhere - a SIEM alert, a customer report, a log line that doesn't add up - points to unusual activity that appears to have started on a specific date. Instead of guessing what was public at the time, open the affected domain and pick the scan closest to that date. You get the exact snapshot: the open ports, the certificate in use, the DNS records that resolved, the web services actually running - as they really were, not as anyone remembers them.
From there, comparing that date against today (or against any other date) shows precisely what changed since - what closed, what's new, what never moved at all. That's the difference between asserting "we believe this was contained" and being able to point at exactly what was true, and when.
Why this is more than a nice-to-have
Incident reporting obligations increasingly expect organizations to characterize what was actually affected, not just confirm that something happened - see our notes on NIS2 and external attack surface monitoring for the fuller compliance picture. Even outside a formal reporting requirement, being able to hand an auditor, a customer, or an insurer a precise, timestamped answer instead of a best-effort reconstruction is worth having before you ever need it.
Curious what your own domain's history already looks like? Run a free scan to get started, or see pricing for ongoing monitoring.