The UK regulatory environment around live events changed materially with Martyn's Law (the Terrorism (Protection of Premises) Act 2025) and the broader operational Code of Practice that surrounds it. Most venues and promoters know the headline obligations — risk assessments, training, public reporting. Fewer are clear on what the documentation actually has to look like after an event, especially when nothing went wrong.
This post is for UK event safety officers and consultants. It walks through what an after-action package should contain to be defensible, what we see operators getting wrong, and how to structure the documentation so a regulator, an insurer, and an internal stakeholder all read it the same way.
Why documentation matters more than the response
The honest part of this category is that the operational response on the day usually goes fine. Security teams at UK venues are, by international comparison, very good. The failure mode is rarely "we didn't handle the incident." The failure mode is "we handled the incident, but six months later when the insurer or the regulator asks what we knew and when we knew it, we can't show our work."
Documentation isn't a compliance burden. It's the defensible record of a calibrated operational call. And it's the thing that determines whether your next renewal cycle includes a premium hike or doesn't.
The five components of a defensible after-action package
A package that withstands scrutiny — from a regulator, an insurer, a coroner, or your own board — has five components. We've structured the SignalGuard PDF export to populate four of them automatically, which we'll come back to.
1. The pre-event threat assessment. This is what you knew before doors opened. Source list, severity assessment per source, who reviewed it, who signed off, and the time stamps. The Code of Practice expects this to be dated and attributable.
2. The during-event signal log. Every signal that crossed your monitoring threshold, when it crossed, what pillar it was in (chatter / environment / movement / context), how the severity changed, and what the operational response was. If you used a threat-intel platform, this should be exportable from that platform. If you didn't, it's somebody's notebook — which won't survive scrutiny.
3. The decision record. The actual calls made on the day, who made them, what signal they were made on, and when. This is the document that protects the operator personally if the call gets questioned later.
4. The post-event review. What you'd do differently. This is required and should be honest. A post-event review that says "everything was perfect" reads as a red flag to any insurer or regulator who's reviewed more than three of these.
5. The retention policy. How long this package is kept, who has access, what the deletion timeline is. Under UK GDPR and the Code of Practice both, this needs to be specified up front. Don't leave it implicit.
What we see operators getting wrong
Three common patterns.
Pattern one: the threat assessment is from a template, dated the day before, signed but not reviewed. This passes a perfunctory audit. It does not survive a coroner. The fix is straightforward — your threat assessment should reference specific, dated signals (today's NWS forecast, today's Ticketmaster nearby events, today's regional chatter) and the reviewer should be a different person from the author.
Pattern two: the signal log is in Slack. Slack is not a record-keeping system. Slack messages are mutable, the export format is unstable, and your retention settings probably don't match what the Code requires. The signal log should live in a system designed to be an audit trail. SignalGuard's /audit page is one option; a properly configured incident-management platform is another. A Slack channel is not.
Pattern three: the decision record is reconstructed. Operators routinely reconstruct the decision record after the event, working from memory and chat logs. This is human and understandable and a regulatory problem. A decision record reconstructed three days later will not match the timestamps in your signal log. When the two don't match, the entire package becomes questionable.
The fix is to capture decisions at decision time, not afterward. Even a one-line entry — "16:24 LR called weather hold based on lightning + saturated egress, sig refs 14:32 / 15:01 / 15:52 / 16:07" — is enough. The point is contemporaneity.
What an automatable package looks like
Here's the structure we've built into the SignalGuard PDF export, with the manual-completion fields called out.
| Section | Auto-populated | Manual |
|---|---|---|
| Pre-event threat assessment (signal snapshot at scan time) | Yes | Reviewer name and sign-off time |
| Pillar-by-pillar severity scores with reasoning | Yes | — |
| Signal log with timestamps and pillar attribution | Yes | — |
| Severity transitions (Medium → High, etc.) with trigger signals | Yes | — |
| Decision record | No | Required: operator captures decisions inline |
| Post-event review | No | Required: completed within 72 hours |
| Retention metadata | Yes | — |
The point isn't that the SignalGuard export replaces your after-action process. It populates four of the five components automatically, so the operator's manual work is the one thing that requires human judgment: capturing the decisions. That's the part that should never be automated.
A note on the Code's "reasonably practicable" standard
The standard the Code of Practice applies is "reasonably practicable" — not "perfect," not "comprehensive," but "what a competent operator would have done given the resources and information available." The reason documentation matters is that the standard is judged retrospectively. Six months after an event, the question won't be "did you have access to every possible signal." It'll be "what signals did you have, what did you do with them, and can you show your work."
Documentation is how you show your work.
If you're a UK consultancy or in-house safety officer evaluating SignalGuard against the Code, the audit-log surface and the PDF export structure are designed for exactly this use case. The longer-form documentation review lives in our docs and the export is generated automatically with every scan on /scan.