Media Data Handling for Deepfake Detection: What to Keep, Protect and Delete

What data does a deepfake detection request create?

Teams usually think about the uploaded selfie or video and forget the rest. A typical request produces the original file, normalised copies, face crops, frames or audio segments, possibly embeddings, per-signal scores and a decision, plus telemetry, reviewer notes and sometimes an exported report. Each copy can contain a face or voice. Each has its own storage location, access path and lifetime.

The table is a starting inventory. Build yours by tracing one real request through every system it touches, including support tools and analytics, and add any artifact that appears.

How should teams limit what they collect?

Collect what the decision needs and nothing more. If a still image answers the question, do not request a video. If the detector works on a face crop, consider whether the full background must leave the device. Article 5 of the GDPR sets out data minimisation and storage limitation as principles for all personal data, and they map directly onto these choices.

Be precise about legal categories. Under Article 9 of the GDPR, biometric data processed for the purpose of uniquely identifying a person is special-category data with stricter conditions. Face matching against an ID document clearly does that. A deepfake check on the same image may or may not, depending on design and context, so record your analysis in the data protection impact assessment rather than assuming either answer. Similar distinctions exist in other privacy laws, and counsel should confirm them per jurisdiction.

How should media and results be protected?

Protect each artifact according to what it reveals. Original media and derived views deserve the strongest controls: encryption at rest and in transit, access limited to the service and named reviewer roles, and logged access. Scores and hashes need integrity protection more than secrecy, because their value is as an unaltered record.

Map controls to an established catalogue so auditors can follow them. NIST SP 800-53 Revision 5 provides access control, audit, media protection and system integrity families that fit this design, and the NIST Privacy Framework helps tie those controls to privacy outcomes. Review screens should blur or hide media by default for content such as intimate imagery, with explicit action needed to view it.

When should retention be decided?

At the moment an artifact is created. If retention is a later clean-up job, it will be missed for the artifacts nobody remembered. Tag each object with its category, owning case and deletion date when it is written, and have storage enforce the date.

Expect the decision record to outlive the media. Regulated firms often need to show why a customer was approved or declined years later. A score, per-signal evidence, model version, policy version, media hash and reviewer decision can support that explanation without keeping the face itself, as long as the hash proves which file was analysed.

Where do media handling plans usually fail?

Most leaks and over-retention happen on paths that were not in the design. Check these explicitly.

• Failed and timed-out requests whose uploads stay in a temporary bucket with no expiry.
• Debug logging switched on during an incident that captures media or base64 payloads.
• Support tickets with attached screenshots or files sent by email.
• Analytics exports and test datasets copied from production without consent review.
• Backups that keep deleted media long after the primary copy is gone.

How can teams prove the data handling plan works?

Test it the way an auditor would. Keep an artifact ledger: for a sample of real requests, list every object created, where it is stored, who accessed it and when it was deleted. Then compare the ledger against the policy.

Run a deletion drill each quarter. Pick closed cases, trigger deletion, and confirm that originals, derived views, exported reports and log entries are gone, and that backups expire on the documented schedule. Record the results. A drill that finds a forgotten copy is a success, because it found the copy before a regulator or attacker did.

• Sample requests across channels, including failed and timed-out ones.
• Search logs and support tools for media payloads and face crops.
• Check that access logs show only the expected service and reviewer roles.

How Neural Defend fits a strict data handling plan

The strongest control is keeping media where you already govern it. Neural Defend can be deployed as a managed cloud API, in a private cloud or VPC, as a secure container, on-premises or air-gapped, with the deployment scoped during evaluation. In the self-hosted options, originals, derived views and telemetry stay inside your infrastructure and under your retention rules. Neural Defend holds ISO/IEC 27001, ISO/IEC 27701 for privacy information management, ISO/IEC 42001 for AI management and SOC 2 Type II certifications.

NeuroVerify returns a unified risk score with signal-level evidence for each request, which is the compact decision record described above. NeuroDetect, the forensic workspace, keeps model and version context with each analysis in a case and produces a downloadable report, so investigators can export a defined document rather than copying raw media between systems. See Neural Defend's product data handling page for current details of how each product processes data.