The redacted documents
Download delivers a single ZIP. This page lists every file in it and what each is for, so the pack can be handed to a DPO, a records officer, or the requester’s side with nothing unexplained.
Each source document appears in redacted form, named to match its original. Emails are delivered as redacted EML files with a paired PDF rendering; documents and spreadsheets are rendered to redacted PDF. Redaction is applied to the text itself, and the preservation rules from DSAR mode are honoured: third-party data is removed, the data subject’s own information remains visible.
Files that could not be processed do not silently disappear: they are listed in the failure manifest instead, so the pack plus the manifest always accounts for the full input set.
The reports
Detection report (CSV). One row per detection across the case: file, file type, the detected text, PII category, confidence, source, and status. This is the working inventory of everything the pipeline found, in a form that can be filtered in a spreadsheet.
Audit trail (CSV). One row per file: detection count, average and minimum confidence, count of low-confidence detections, processing status, whether it was reviewed, when, and by what route. This is the file-level accountability record: it shows coverage, and it is the quickest way to demonstrate that every document was examined.
Review decision log. The per-decision history: each detection’s final state and how it got there, including entity-level cascade decisions and manually added detections. Where the audit trail shows that review happened, the decision log shows what the review decided.
Subject preservation summary. A DSAR-specific report listing what was preserved as the data subject’s own information, grouped by identifier. Its purpose is to make the preserve side of the review as inspectable as the redact side: a disclosure that accidentally redacted the requester’s own data is defective, and this report is how you check that it didn’t.
Failure manifest. Files that failed processing, with the reason. Unsupported file types inside the upload are also noted in the pack’s coverage information. Reconcile this against Purview’s own Items report for the export: Purview’s report covers what left Microsoft 365, the manifest covers what happened here, and together they close the loop on completeness.
Attestation record. The sign-off: who attested, when, and to what case state. This is the document that says a person, not a pipeline, approved the disclosure.
Reading the pack as a completeness argument
A defensible DSAR response has to answer one question: was everything in scope examined, and is every removal accounted for? The pack is structured so the answer is mechanical.
- Purview’s Items report says N items were exported.
- The audit trail plus the failure manifest account for all N: processed and reviewed, or failed with a stated reason.
- The detection report and decision log account for every redaction.
- The preservation summary accounts for what was deliberately kept.
- The attestation record puts a name on the judgment.
If a regulator, the requester, or your own DPO asks how the disclosure was produced, the pack is the answer, without reconstructing anything from memory.
After download
Payment is taken at download, and the case is complete at that point. The documents themselves were processed in your browser and are not retained by SafeRedact; keep the pack in your own records system in line with your retention policy, since it is the evidentiary record of the response.