The difference between real-time and post-processing redaction
Not all redaction is the same workflow. The distinction between real-time and post-processing redaction is one that gets collapsed in a lot of vendor conversations - treated as a minor technical detail when it's actually a fundamental architectural difference that shapes what a redaction system can and can't do for you.
Understanding the split properly matters if you're evaluating solutions, designing a compliance workflow, or trying to figure out why the approach you've been using doesn't fit the problem you're trying to solve.
What post-processing redaction actually is
Post-processing redaction operates on recorded footage after the fact. Video is captured, stored, and then passed through a redaction pipeline when it needs to be shared, disclosed, or published.
This is the mode most organisations encounter first - and for most redaction use cases, it's the right one. DSAR fulfillment, FOIA requests, incident disclosure, evidence sharing, and training data preparation are all post-processing jobs. The footage already exists; the question is how to handle it compliantly before it leaves the organisation.
The AI pipeline in post-processing redaction works frame by frame across the stored file:
Object detection models identify faces, licence plates, screens, and other personally identifiable information (PII) in each frame
Tracking algorithms link detections across frames so that a face blurred in frame one stays consistently blurred as the subject moves through the scene
The redacted output is rendered as a new file with the detected elements obscured - the original remains intact and unaltered
Human reviewers can verify and correct automated detections before final output is produced
Post-processing is computationally intensive but not time-critical. The footage isn't going anywhere. That gives the AI more room to operate carefully - running higher-quality detection models, applying more sophisticated tracking, and producing more accurate outputs than would be possible under hard latency constraints.
Secure Redact is built around post-processing as its core capability, achieving detection rates exceeding 99% across CCTV, body-worn, and dashcam footage precisely because the system doesn't have to make real-time speed-accuracy trade-offs.
What real-time redaction is - and what it's actually for
Real-time redaction anonymises video as it is captured or streamed, before it reaches storage or display. It operates on a live feed rather than a stored file, applying privacy protection in the moment rather than in retrospect.
The use cases are genuinely different from post-processing:
Sharing live CCTV feeds with parties who shouldn't see identifiable individuals - service staff who need situational awareness but don't need to identify people, for instance, or extended security operations centre coverage
Generating anonymised video analytics from live feeds without creating underlying data that constitutes a DSAR risk
Live body-worn camera footage in situations where identities need to be protected immediately rather than redacted before a later disclosure
Enabling broader access to live video infrastructure without creating proportionality problems under data protection law
The technical architecture is fundamentally different from post-processing. Real-time systems must process each frame and output a redacted version within the latency budget of the streaming pipeline - typically a matter of milliseconds. This imposes genuine constraints:
Lighter, faster detection models that prioritise speed over maximum accuracy
Less sophisticated tracking across frames given the reduced look-ahead window
Lower resolution outputs in some implementations to reduce processing load
Higher tolerance for missed detections in exchange for not breaking stream continuity
These aren't failings - they're deliberate engineering trade-offs for a different operational context. A live anonymisation feed that occasionally misses a face in a crowded frame is still vastly better than a live feed with no anonymisation at all.
Why the distinction matters for compliance workflows
The compliance implications of each mode differ in ways that aren't always obvious up front.
Post-processing creates a clear, auditable chain of events: original footage is retained, redacted output is produced for disclosure, and the process can be reviewed, challenged, and documented. This audit trail is exactly what regulators and courts want to see - proof that PII was handled appropriately and that the redacted output was produced from the original rather than replacing it.
Real-time anonymisation raises different questions. If live footage is anonymised before storage, the original unredacted data may never exist in stored form - which can be a privacy advantage but may also create questions about whether footage adequate for investigation or disclosure purposes has been retained. The right answer depends on the organisation's specific legal obligations and how its video retention policy is structured.
The two modes can also work together. Many organisations benefit from real-time anonymisation for live access and broader monitoring coverage, combined with post-processing redaction for stored footage when disclosure requests arrive. These aren't competing approaches; they solve different problems in the same overall video data workflow.
Choosing the right mode for your use case
The practical question is which mode your current problem actually calls for.
If the challenge is responding to DSARs, FOIRs, or incident disclosure requests - that's post-processing
If the challenge is sharing live feeds with parties who shouldn't see identifiable individuals - that's real-time
If the challenge is generating video analytics from live streams without privacy liability - that's real-time
If the challenge is producing evidence for legal proceedings or regulatory submissions - that's post-processing, with a full audit trail
If the challenge is all of the above - you likely need a platform that handles both, with appropriate workflows for each
The most common mistake is trying to solve a post-processing problem with a real-time tool (sacrificing accuracy for speed that wasn't needed) or trying to retroactively apply real-time assumptions to stored footage disclosure (missing the audit trail requirements that disclosure actually demands).
FAQs
-
Yes. In many enterprise deployments, live feeds are anonymised in real-time for broader access, while the underlying stored footage goes through post-processing redaction when it needs to be disclosed in response to a DSAR or investigation. The two workflows address different stages of the same footage lifecycle.
-
Real-time redaction is designed for live access scenarios rather than formal disclosure. For DSAR and FOIA responses, post-processing redaction is the appropriate tool - it produces higher accuracy outputs and the audit trail that formal disclosure requires.
-
No. Post-processing redaction produces a new redacted output file; the original footage is retained separately and unaltered. This is essential for legal and compliance purposes, as the original may be needed for investigation or challenge.
-
Significantly faster. Secure Redact processes a 10-minute video in approximately 10 minutes - against an estimated 8 hours for manual editing of equivalent footage using traditional video editing software. That's over 280 times faster than manual methods.
-
Post-processing handles any stored video file - CCTV recordings, body-worn camera footage, dashcam files, smartphone video, and more. Secure Redact supports all major video formats including MP4, MOV, AVI, WebM, WMV, MPEG, 3GP, and MKV.