A regulator data request arrives faster than most businesses expect and asks about a period long before the incident. Once a breach is reported, particularly one involving health, financial or resident data, the follow-up is rarely a question about the attacker. It is a request for your records: the risk analysis you were supposed to be maintaining, evidence of the controls you told people you had, your policies as they stood on the day, and your log of who accessed what. Every one of those describes a time before anything went wrong, which means the investigation is examining decisions made months earlier rather than your response last Tuesday.
The Six Documents That Get Asked For
These come up again and again, and every one of them is either in place already or effectively unobtainable afterward.
- Your current risk analysis. Dated, covering the whole environment, with the gaps it identified and what you did about them.
- Evidence the controls existed. Reports showing encryption, access controls and authentication as configured, not a policy saying they should be.
- The policies as they stood. Version history matters, because a policy dated after the incident answers a different question.
- Access records for the affected data. Who could reach it, who did reach it, and when access was last reviewed.
- Your incident timeline. When you detected it, what you did in what order, and when the clock on notification started.
- Training records. Who was trained, on what, and when, since the human element is almost always part of the narrative.
Our explainer on what cyber incident response involves covers the response side this sits alongside.
Why a Regulator Data Request Looks Backward
The investigation is assessing whether the harm was reasonably foreseeable and reasonably guarded against, which makes the months before the incident the relevant period rather than the incident itself. That framing explains the shape of the questions, which otherwise seems odd to a business still cleaning up. Nobody asks how sophisticated the attacker was, because sophistication is not the test. They ask whether you had assessed your risks, whether you acted on what you found, and whether the controls you claimed were actually running. A firm that was breached despite doing that work is in a fundamentally different position from one where the same documents do not exist, even though both had the same bad week.
Documents Created Afterward Read as Documents Created Afterward
Producing a risk analysis after an incident is worse than producing none, because the dates are visible and the intent is obvious to anyone who reviews these routinely. File metadata, version history, and the absence of any earlier iteration all tell the same story. Investigators see a great many of these. The correct response to not having one is to say so plainly and describe what you did instead, which at least is a truthful account of an imperfect posture. The counterargument is that a business genuinely intended to do the assessment and simply had not got to it, so a reconstruction is honest in spirit. That distinction does not survive contact with a formal process, and the reputational cost of appearing to backdate is considerably higher than the cost of a gap.
Keep the Incident Timeline From Hour One
A contemporaneous timeline is the one document you can only create during the incident, and it is the one most often assembled afterward from memory and message history. Start it the moment anything is suspected, in a shared document, with times and initials. When something was noticed, who was told, what was checked, what was changed, when an external party was engaged, when the decision to notify was taken and by whom. It does not need to be elegant. It needs to exist and to be written as events happen, because the notification clock in most regimes runs from a defined trigger and you will be asked to evidence when that trigger occurred. Our note on protecting the business during incident response covers the operational half that runs in parallel.
The Evidence Problem Nobody Anticipates
Most requests ask you to demonstrate a control was operating during a period, and a screenshot from today does not do that. This catches out businesses that are genuinely well configured. Your multifactor authentication is enforced, your encryption is on, your access reviews happen. Asked to show that all three were true in March, you can show they are true now and assert they were true then. That gap between demonstrating and asserting is where a lot of otherwise defensible positions weaken, and closing it costs almost nothing if done in advance.
Export the Reports Quarterly and Keep Them
A dated export of your key control reports, taken every quarter and stored, converts an assertion into evidence and takes under an hour. Authentication coverage, endpoint deployment against your asset list, backup verification, and access review completion are the usual four. Save them with the date in the file name somewhere that is not the system being reported on, which matters because an incident may take that system offline exactly when you need its history. This is the same discipline our note on audit trail documentation describes, applied narrowly enough that a small business will actually sustain it. The objection is that quarterly snapshots are a crude substitute for continuous logging, which is true and beside the point for a firm that currently has neither.
Check What Your Provider Retains, and For How Long
If an outsourced provider runs your systems, the evidence you will be asked for sits in their tooling, and their retention period decides whether it still exists. Ask now: how long are authentication logs kept, how long are endpoint records retained, and can you obtain an export on request without a commercial negotiation. Thirty days is common and is shorter than the dwell time of many incidents, which means the records covering the relevant period may be gone before anybody knows to ask. Get the answer in writing and treat it as a contract term rather than a technical detail, which our note on managed detection and response contract traps and our guide to MDR both cover. The reasonable pushback is that longer retention costs money, and it does. Knowing the number is free, and it lets you decide rather than discover.
Handling the Request Itself
Once a request arrives, the mechanics of responding matter nearly as much as the content, because a disorganized response invites a broader second request. Acknowledge it promptly. Read exactly what is being asked for and answer that rather than everything adjacent to it. Involve counsel before you send anything, particularly where the answer touches on what you knew and when. And preserve everything in scope from the moment you become aware, because routine deletion continuing during an investigation is a problem entirely of your own making.
Suspend Routine Deletion Immediately
Automatic retention policies will delete material in scope unless somebody pauses them, and that deletion is difficult to explain afterward regardless of how innocent it was. Mailbox retention, log rotation, backup expiry and ticket archiving all run on schedules nobody thinks about. Identify what is in scope, pause the relevant policies, and record that you did it with a date. Then remember to resume them, since an indefinite preservation hold creates its own problems with the privacy obligations you also have. The objection that a small business cannot realistically freeze every system is fair, and the answer is proportionality: freeze what relates to the affected data and the relevant period, and document the reasoning for what you did not.
Answer Precisely, and Say What You Do Not Have
A response that states plainly where a document does not exist is stronger than one that pads the gap, because the gap will be found and the padding damages everything around it. If there is no risk analysis, say there is no formal risk analysis, describe whatever assessment did occur, and say what you have since put in place. Regulators encounter imperfect small businesses constantly and the response to candour is generally more constructive than the response to evasion. What genuinely aggravates a process is discovering that an answer was shaped, at which point every other answer gets re-examined. Our note on drafting breach notifications and our primer on incident response basics both come back to the same principle, which is that precision costs less than it appears to.
Decide Who Speaks, and Make Sure Only They Do
A single named point of contact for the regulator prevents the most avoidable damage in these matters, which is two people in the same business giving inconsistent accounts weeks apart. It happens easily. A technical staff member answers a follow-up call helpfully and describes the timeline as they remember it, while the formal written response prepared with counsel says something slightly different about when detection occurred. Neither person was being careless. The inconsistency is now on the record and every subsequent answer is read against it.
Name the contact when you first report, tell your team that all correspondence routes through that person, and mean it, including for calls that sound routine. That is not about concealment, since the same information gets provided either way. It is about the information being assembled once, checked, and stated consistently. The objection worth taking seriously is that a single point of contact becomes a bottleneck and slows your responses, which can itself look unhelpful. Name a deputy for that reason, brief both, and keep the pair small. Two people who have read the same file give the same account; five people working from memory do not.
Frequently Asked Questions
How quickly does a request arrive after a breach report?
Often within days to a few weeks, depending on the regime and the data involved. The speed surprises businesses that are still mid-cleanup, which is why the documents need to pre-date the incident.
What do they actually ask about?
Mostly the period before the incident: your risk analysis, evidence your controls were operating, your policies as they stood, access records, your incident timeline and training records.
Can we write the risk analysis now?
You can write one going forward, and you should. Producing one dated after the incident and presenting it as pre-existing is visible and does considerably more harm than the gap it tries to cover.
What if our IT provider holds the evidence?
You remain responsible for producing it. Ask now how long they retain authentication and endpoint records and whether you can get an export, because thirty-day retention is common and often too short.
Should we stop our normal deletion schedules?
Yes, for anything in scope, as soon as you are aware. Then record that you did it and remember to resume once the matter closes, since indefinite holds conflict with your privacy obligations.
Who You Are Taking This Advice From
Mindcore has sat with clients through the weeks after a reportable incident, which is where you learn that the hard part is evidence rather than remediation. We set up the quarterly control exports before anything happens, start the timeline in hour one rather than reconstructing it, and get provider retention periods in writing while they are still a negotiable contract term, and the guidance above comes from responses we have helped assemble rather than from a regulatory summary. Matt Rosenthal, who leads Mindcore, keeps the firm focused on preparation that pays off in the worst week rather than the average one, which here means four exports a year and a document somebody starts on day zero. Your lawyers will handle the response. Our job is to make sure there is something to respond with.
Your Next Move Before You Need Any of This
Spend an hour on the part that cannot be done later. Export your key control reports today, with the date in the file name, and put them somewhere separate from the systems they describe, then diary the same export quarterly. Ask your IT provider in writing how long they keep authentication and endpoint records and whether you can obtain an export, and if the answer is thirty days, decide now whether that is acceptable rather than discovering it during an investigation. Write down where your incident timeline will live and who starts it, because that document only exists if somebody opens it in the first confusing hour. Check whether you have a dated risk analysis and, if you do not, start one this quarter so that next year’s version has a predecessor. None of this improves your defenses, which is why it gets postponed indefinitely. What it does is decide whether a bad week becomes a bad year, and that distinction is settled by paperwork that either existed beforehand or did not. If you want help setting up the exports and the retention questions, book a free strategy call and we will start with what your provider keeps.
