A useful exception audit export has one row per decision, with a stable ID, the finding, the asset, reason, approver, request and expiry dates, current status and links to evidence. It should be machine readable, include closed and expired items, and be reproducible for any past date.
Why the export matters more than the screen
Auditors rarely log in to your tool. They ask for a file, sample from it, then ask for proof on the sampled rows. If the export is thin, every sample turns into a scavenger hunt through chat and tickets.
Design the export for the sampler: every row should be answerable without a follow-up question.
Fields to include
| Field | Why an auditor wants it |
|---|---|
| Exception ID | Stable reference that never changes |
| Finding ID and advisory ID | Ties the decision to the specific issue |
| Asset or scope | Shows what the exception covers and nothing more |
| Severity at approval | Records what the approver saw at the time |
| Reason category | Not reachable, no fix, compensating control, and so on |
| Justification text | The human explanation |
| Requester and approver | Shows separation of duties |
| Requested, approved, expires, closed dates | Shows timeliness and duration |
| Status | Active, expired, revoked, fixed |
| Evidence links | Where to verify the claim |
| Renewal count | Reveals exceptions that never end |
The related post on what fields belong in a risk acceptance record covers the record itself. This post is about the file you hand over.
Format choices
CSV is easiest for sampling in a spreadsheet. JSON suits automated checks and keeps nested evidence lists intact. Offer both if you can. Use ISO 8601 dates with a timezone so nobody argues about whether a day ended in London or New York.
If you publish exploitability statements as well, OpenVEX gives a structured place for them. Its specification requires a justification label or an impact statement whenever a statement says a product is not affected, which is a good model for the evidence column.
Make it reproducible
Auditors test a period, not today. Your export should accept a date range and an "as of" date, and return what was true then. If someone edits an exception after the fact, keep the history rather than overwriting it.
Include the export's own metadata: when it was generated, by whom, from which system, and the filter used. An export without provenance is just a spreadsheet.
Common gaps
- Only active exceptions appear, so expired ones vanish
- Approver shown as a team name, not a person or role
- Evidence column holds "see ticket" with no link
- Severity is today's value, not the value at approval
Sampling check before the audit
Pick ten rows at random and try to answer, from the export alone: who approved, on what basis, until when, and what proof exists. Any row you cannot answer is a gap to fix before an auditor finds it. See also exception audit trail: what an auditor can replay.
Safeguard's compliance and evidence automation is built to gather records like these, and its policies and gates keep the decisions enforceable.
Try it yourself
Click through it at your own pace, or open it full screen.
See how evidence maps to framework controls, which is the shape an auditor's request takes.
Quick check
Should the export include rejected requests?
Yes. Rejections show the control actually says no sometimes.
Is a PDF export enough?
Rarely. Auditors sample and filter, so a structured file is more useful than a formatted document.
Sources
Last reviewed: 19 October 2026.
