After the Incident Closes — The Evidence Executives and Auditors Actually Ask For
Executives want trends; auditors want proof. What a post-incident report must carry: dual-timezone periods, an as-of cutoff, approvers, revisions, a checksum.
After the Incident Closes — The Evidence Executives and Auditors Actually Ask For
The case closed three weeks ago. Then an email from the auditor lands: "On the 12th, who approved disabling that user account, and what time was the approval given?"
The team that worked the case can answer, because they still remember it. But remembering and proving are two different things. Ask for the documentation and what tends to appear is a deck assembled after the fact, plus a CSV export from the ticket system that nobody can date, version, or tie to a cutoff.
Executives and auditors are asking two different questions
An executive wants to know whether the month was under control: how many cases, how long response took, whether the trend is improving. That is a management question, and a chart answers it well enough.
An auditor is after something else. They are not evaluating whether the numbers look good. They want to know why the numbers can be trusted — who produced them, who approved them, whether the approval came before or after publication, and whether pulling the same month's report again in October returns the same figures it returned in August.
That second set is the one that hurts, because most tooling is built to show current state, not to attest to past state.
The real problem is a report that keeps moving
Take a phishing case where someone actually clicked. The team did everything right — blocked the domain, reset the password, revoked active sessions, closed the case. If the response ran through an automated playbook, every one of those actions already produced a log entry. (Our phishing response playbook walkthrough covers what each of those steps does in detail.)
The logs aren't the problem. The problem shows up when logs get turned into a report.
Pull the "July" report on 3 August and you get one set of numbers. Pull it again on 20 August and you get a different set — because in between, an old case was reopened, a late-arriving alert got counted, and someone retroactively adjusted a severity. The figures aren't wrong. They just aren't stable, and something that isn't stable can't function as evidence.
Then there's time. The report says "1–31 July," which sounds unambiguous right up until someone asks whether that's Bangkok time or UTC. Most log platforms store UTC; the person reading the report is sitting in Bangkok, seven hours ahead. So a case that landed at 9 PM on 31 July may or may not belong to that month, depending entirely on who drew the line and where.
What a defensible record has to answer
| The question you'll get asked | What the report needs to carry |
|---|
| What period does this actually cover? | The window stated in both local time and UTC, side by side |
| Where do the numbers stop counting? | An as-of cutoff that says explicitly whether the boundary is included |
| Who approved it, and when? | An approver plus timestamp, recorded separately from the publisher |
| Has anyone edited it since publication? | A revision number and a status that locks further edits |
| Is the file I'm holding the original? | A checksum of the snapshot |
None of those five are luxuries. They are the difference between a report and a piece of evidence, and they're why zcrSOAR keeps evidence on its own page rather than bolting a PDF export onto the operational dashboard and hoping that covers it.
What that looks like in practice
The Monthly operations reports page in the zcrSOAR demo describes itself right in the header as "a frozen English evidence record for each closed month," with a Checksum-backed marker alongside it.
There are three states, not one button. The register in the demo can show Draft, Approved, and Published entries all at once. Even the button that starts the process isn't labelled "generate report"; it says Generate draft. You get a draft first, and it moves through the states from there, with the approval timestamp always recorded ahead of the publication timestamp. (The specific dates shown in the demo are sample data, not a real reporting cycle.)
Time is stated twice. Each record carries the period in local time (Asia/Bangkok) alongside the same period in UTC, with an explicit note on whether the boundary is inclusive. A separate as-of field is marked as an exclusive bound. Those two annotations, inclusive and exclusive, are what let a reader work out the boundary from the document itself instead of tracking down whoever pressed the button. The create panel adds the other half of it in its own words: "the server freezes the as-of to the period end" — the cutoff comes from the server, not from a number somebody typed in. (Again, the exact timestamps visible in the demo are illustrative, not a confirmed reporting window.)
Approver and publisher are separate fields. Approved by and Published by are two distinct fields, each with its own timestamp. Worth being precise here: in the demo, Approved by renders as an internal user ID rather than a person's name, and Published by simply reads "recorded." So what the screen actually establishes is that approval and publication are logged separately, each with its own timestamp — which is the raw material an auditor works from when testing segregation of duties. Whether those resolve to real names depends on how you wire it into your own identity system.
Published means published. The Publication rule box states it plainly: published runs are immutable, and a correction has to go out as a new revision with a stated reason while the original stays auditable. That's why every row in the register carries a revision number — not just the ones that have been corrected.
There's a checksum on the snapshot. The record ends with a Snapshot checksum field. Its use is blunt: if someone hands you a July report file six months from now, comparing the checksum tells you immediately whether it's the published version or something that got edited along the way.
All of this is metadata. None of it has anything to do with detection quality. But it's the layer that makes detection results usable as a reference later.
What this kind of report doesn't do — plainly
One: the record itself is in English. The page says so — a "frozen English evidence record." That fits a foreign auditor or a compliance team already working in English, but if the material is headed for a Thai board or a domestic regulator, there's still a translation and rewriting step in front of it. zcrSOAR gives you a stable, citable record; it does not give you a finished presentation.
Two: this is a closed monthly cycle, not a breach notification. When a data breach triggers a statutory notification deadline, what you file is the detail of that specific incident, not a summary of the month. A monthly record is useful as supporting evidence that a process actually ran, and ran continuously — but the two don't substitute for each other. If you're not sure what the PDPA side of this requires, work through the 8-point checklist first.
Three: it is not an investigation report. This evidence answers "what was done, who approved it, when." It does not answer "how did the attacker get in, and how far did they get." Narrating the attack path is separate work — our piece on reading an attack flow against MITRE ATT&CK covers that side. In practice a complete post-incident package usually needs both.
Signs this is about you
- Every request for a historical report means reconstructing it from tickets by hand
- You've pulled the same month twice and gotten different numbers, with no explanation for the gap
- Nobody can say who approved last month's report
- The report you send to leadership is an editable file, and you don't know which version the executive has open
- Your documents say "July" without specifying a timezone
Two or more of those, and the weak point isn't detection — it's everything after it. Adding another detection tool does nothing for this particular set of questions.
Where to start
If your response process is still mostly manual, the first move is getting each action logged automatically as it happens. (What SOAR is covers that groundwork.) The best evidence is the kind produced as a byproduct of doing the work, not typed up afterward from memory.
The reporting layer comes after that — which is the part zcrSOAR structures as a cycle with statuses and recorded approvals, draft through published, with a revision number and a snapshot checksum on every row. If you want to see which package includes it, the details are on the pricing page, or you can open the zcrSOAR demo and look through the evidence screens yourself before you decide.
Get in touch
Wondering whether the post-incident reports your team sends today would survive an auditor's questions? Talk to us — the consultation is free.
Sources
- Personal Data Protection Act B.E. 2562 (2019) (PDPA) — breach-notification requirement (this article deliberately avoids stating a specific hour-count, since the applicable window depends on the incident and the Data Protection Officer's assessment)
- NIST SP 800-92 — Guide to Computer Security Log Management — general principles for log integrity and evidence retention