Audio Redaction and Chain of Custody: Changing Only the Bytes That Carry the PII

When a redacted call recording is challenged, whoever defends it is usually asked to show two things at once. The sensitive words must be gone, and nothing else in the file may have changed along the way. The second is harder than it sounds, because a redacted copy produced by re-encoding the whole recording cannot be compared with its source byte for byte.

File integrity is one of the failure points that our guide to call recording redaction traces from ingest to export, and it decides whether a redacted call can be defended later. Everything turns on what the redaction tool does to the parts of the file it was never asked to change.

What re-encoding does to a recording

Most audio tools redact by decoding the recording to raw samples, editing those samples and encoding a new file, and each of those steps has consequences. Lossy formats discard information by design, and the Library of Congress describes MP3's perceptual coding as letting the codec discard or reduce the precision of components that are less audible to human hearing. Each further encoding adds losses, and the EBU's report on cascaded audio codecs says that cascading different codecs generally results in a significant overall degradation of audio quality.

Even a lossless re-encode, which keeps the sound intact, writes a new file from the header down. Showing that the rest of the recording is untouched then means decoding and comparing audio instead of simply comparing files. SWGDE's guidance on digital audio authentication states that transcoded or re-encoded versions of an original recording are not original recordings.

Changing only the bytes inside the redacted spans

For uncompressed audio there is another way, since nothing in the file has to be decoded before it can be edited. The Library of Congress describes linear PCM as capturing and encoding audio without lossy compression. A WAV file holding it is a RIFF container built from chunks, with the format header in one chunk and the audio data in another.

Byte-level redaction works within that structure, turning each redacted time span into a range of bytes in the audio data and merging any spans that overlap. Every byte outside those ranges, the header included, is copied to the redacted file unchanged, and only the bytes inside them are overwritten with silence or a tone. The redacted file keeps its format, channel count, sample rate and duration, because none of the bytes that describe them has changed. The masking covers every channel of a stereo file, and our article on stereo call recordings sets out why that matters on a two-sided call.

We built this for a contact center whose redacted recordings went on to an outside analytics provider, and which required each redacted file to be identical to its source except at the redacted points. A decode, edit and encode tool would have rewritten every sample and could have changed the format the provider's system expected. It would also have left no way to show that the rest of each call was untouched. Changing only the bytes that carry the PII answered both concerns at once, and it is how Redactor treats uncompressed call audio.

How to verify any tool's output

A redacted file's integrity can be checked without taking the vendor's word for it, and most of the checks need nothing beyond the original, the redacted copy and a list of the redactions.

The list of redacted segments is a record in its own right, and SWGDE's video and audio redaction guidelines ask practitioners to document the starting and ending timecode of each redacted audio segment. The same guidelines ask for every step in the redaction process to be documented, and for the redacted recording to be exported with the original source properties. A tool that cannot produce the list, or that changes the source properties without saying so, leaves those gaps for the organization to fill.

Where byte-level editing stops

Some major contact center platforms record uncompressed PCM WAV, so a good deal of call audio arrives in the one format this approach needs. Amazon Connect is one, and its recording ingestion configuration page describes the Connect recording format as Linear16 PCM WAV at 8 kHz, stereo and 16-bit. The approach depends on the samples being stored as they are, though, which is why it applies to uncompressed PCM and to nothing else.

An MP3 or AAC recording has to be decoded before its audio can be edited, so any redacted copy of it is a new encoding, whatever tool produces it. The same holds for telephony audio such as G.711 or GSM stored inside a WAV container, which looks like a WAV file but holds encoded audio rather than linear PCM. For any of these, the questions to put to a vendor are what format the redacted copy comes back in, whether the next system in the chain accepts it, and how its size compares with the source.

The original and the custody record

What happens to the original recording when a redacted copy is made should be a configured policy, and there are three reasonable options. The original can be kept with the redacted copy added beside it, which is the usual default, the copy can be added and the original recycled, or the original can be redacted in place. Keeping it is the posture that public-records and evidence work needs, since an appeal against a withholding is decided against the unredacted record, and an audit or a later re-redaction needs it as well.

Payment calls turn that reasoning around, because an unredacted original still holds every card detail that was spoken. Under the PCI DSS position set out in our guide to call recording redaction, an original that caught a security code after authorization should survive only where a documented legal or evidential obligation requires it to. For every other payment call, overwriting the original or recycling it with a short retention period is usually the right setting. Whatever is chosen belongs in the written retention policy rather than being inherited from a default. Keeping every original also carries a storage cost at contact center volume, which our article on bulk call recording redaction weighs.

Integrity over time comes from a hash recorded when the recording arrives, which can be recomputed on demand and compared. A redacted copy never matches its original's hash, which is why the record around it carries so much weight: who redacted what, when, and from which original. A custody record that logs every action on an item, with the user, the time and the event, is what connects the verified original to the released copy.

A status that means what it says

A redacted copy is only trustworthy if its label is, and the label fails quietly when a job finds nothing to redact. If no PII is detected, or every detection falls below the confidence threshold, publishing the untouched file as the redacted copy, badge and all, tells the next person it is safe to release. A file that nothing was removed from should never come back labeled redacted, so the right outcome is no redacted copy, no badge, and a recorded reason why the job was skipped.

Failures need the same discipline, because a masking step that fails but reports success passes its error downstream. The error then surfaces at a later step and sends people looking in the wrong place. A failed masking step should fail the job, publish nothing, and name the step that failed, so the investigation starts where the problem is.

What you can check on Redactor's output

VIDIZMO Redactor redacts uncompressed PCM WAV recordings for detected spoken PII without re-encoding them, overwriting only the bytes inside each flagged interval with silence or a beep. Every other byte, header and any metadata chunks included, is copied unchanged. That keeps the recording verifiable, but a metadata chunk can hold identifiers of its own, such as a caller's number or an agent's name written into a comment field by the recording system. Those travel into the redacted copy as they are, so check what the chunks hold before release and clear them in a separate step where they carry PII. Other audio formats are re-encoded and written out as WAV, with OGG kept as OGG, so an MP3 or AAC call comes back as a WAV file that is larger than its compressed source. Plan storage for redacted copies on that basis, and where the recording platform can store calls as PCM WAV, keeping them in that form avoids both the growth and the re-encoding.

A job that finds nothing to mask is skipped with its reason and leaves no redacted copy or badge, and a failed audio masking step fails the job. The original is kept, recycled or overwritten as the output policy says. When two configured policies disagree, the one that keeps the most wins, so a contact center that overwrites payment-call originals should make sure no other enabled redaction setting asks to keep them. A SHA-384 hash is recorded at ingest and re-verified on demand wherever tamper detection is switched on. Every action on an item is recorded with the user, email address, IP address, local date and time, and the event.

For redacted calls released with their originals handled by policy, see how Redactor handles recorded calls.