[AI DRAFT] Spillage Report: Why File Metadata, Not File Content
BLUF
The downloaded spillage report should include rich file metadata, not the file attachments themselves. This is not a compromise — it is the correct design per DoD spillage handling doctrine and the universal pattern across every major DLP platform.
Message Text: Include. File Attachments: Do Not Include.
Message text is already shown to reviewers in the DM report and is often the only way to understand the context of the spillage. It can stay in the downloaded report but we should watch out for feedback if customers find that problematic.
File attachments are different. If a file is suspected classified content that exceeded the platform's authorization boundary, copying that file into a downloadable report forwards the classified material — exactly what DoD guidance prohibits:
CDSE Data Spills Training (CSS0089): "Do not forward classified data to anyone else, including security personnel."
NIST 800-53 IR-9: Spillage response must use notification methods "not associated with the spill" — a report containing the spilled content IS associated with the spill.
DoDM 5200.01 Vol. 3: Classified content must be handled at its classification level. If spilled content is TS/SCI on a Secret platform, a report containing that content inherits that classification.
A report that embeds spilled files becomes a second spill artifact that itself requires containment.
Every Major DLP Tool Does It This Way
Microsoft Purview, Forcepoint, Trellix, Symantec, Digital Guardian, Google Workspace DLP, Proofpoint — all follow the same architecture: metadata in incident reports, actual content in separate forensic stores with tiered access controls. This is settled industry practice.
The File Metadata We Include Is Actionable
For each file attachment on the quarantined message, the report would include:
Field | Why It Matters |
|---|---|
Filename | Identifies the document |
File size | Indicates scope of exposure |
MIME type | Confirms file format (PDF, DOCX, image, etc.) |
Upload timestamp | Establishes incident timeline |
Uploader user ID | Identifies the source |
Optionally, a SHA-256 hash per file could give incident response teams a cryptographic fingerprint to locate and verify the exact file through their own forensic processes — this is the mechanism Purview, Symantec, and Google use. Worth considering if feasible.
This Also Resolves the File Size Concern
Embedding large attachments would bloat the report and risk exceeding file size limits. With metadata-only for files, the report is a lightweight document regardless of whether the spilled files were 10KB text or 500MB imagery.