Call Recording Compliance and Storage: What Your Recording System Needs

A recording system earns its keep when it can answer a specific question later: which call, which line, which time, who was on it, and what happened to the file since. Compliance follows from that capability plus a retention process that someone actually runs. Buying a recording server does not, on its own, produce either one.

Definition: Call recording compliance is the set of controls that make recorded calls attributable, retrievable and deletable according to the rules that apply where your business operates. It covers capture, storage, access, retention and the audit trail that connects a particular recording to a particular call.

What a Recording System Must Be Able to Prove

When a regulator, a customer or an internal reviewer asks for a particular recording, the answer has to come out of a system. It cannot come out of someone's inbox, a shared drive of exported files, or the memory of whoever configured the switch. That requirement is where compliance work actually begins.

Equipment determines how many channels you can record at once and how much you can keep on hand. It does not determine whether a recording can be tied back to a call, whether the metadata describing that call survived, or whether the file is still there on the day it is needed. Those answers come from configuration and from the process wrapped around it.

A recording setup passes a review when it can demonstrate four things: the audio belongs to a named call, the metadata describing that call is intact, access is limited to authorised people, and the file is removed on the date the retention schedule says it should be. Miss one of the four and you have a machine holding recordings, which is a different and less useful thing.

The five questions behind every compliance request

• Which call is this? A person needs to move from a name and a date to one specific file without guessing.
• Who was on it? Extension, trunk, queue and account identity should be attached to the file at capture time, not reconstructed afterwards.
• When was it captured, and on which system? Timestamps have to be trustworthy and the source of the recording has to be identifiable.
• Where does the file live and who can reach it? Storage location and the list of accounts with read access are both part of the answer.
• When is it deleted, and on whose instruction? An indefinite archive accumulates exposure, and a deletion with no record of it leaves a gap.

If your recording arrangement cannot answer those five questions without a manual export and a spreadsheet, the setup is incomplete no matter which model of equipment sits underneath it.

Recording Formats and Where They Are Stored

Format matters less than most people assume, and storage location matters considerably more. Two artefacts show up around the New Rock product line, and they do different jobs.

Audio captured from an OM system is written by the Recording Agent, which runs on Windows and stores what it collects as MP3. Separately, the CDR Software runs on Windows, collects OM call detail records as .txt files, places them on an external server and manages retrieval of those records. The second one is not audio at all. It is the index that makes audio usable, because it is what links a file to a call, a direction, a duration and a party.

For a single small site, the OM20G carries built-in recording storage alongside its built-in analog gateway module, which keeps recording local to the appliance. That is a reasonable starting position, and it becomes a gap the moment a second site or a second reviewer needs access.

Format choices decide what you can do later

• MP3 as written by the Recording Agent: compressed, plays on anything, but lossy. Usually fine for quality monitoring and internal review.
• Original encoding from the PBX or gateway: keeps the source stream intact, which matters when a dispute requires the untouched recording rather than a convenience copy.
• Call detail records as .txt: not audio, but the durable link between a file and the call it contains.
• None of these substitutes for the others. The audio and the index are separate artefacts, and the join between them has to belong to somebody.

Deciding up front which of these is your record of reference prevents a later scramble to reverse-engineer it from file names.

Centralised Recording Management

The operational question changes shape as soon as there is more than one site. "Is recording switched on" becomes "can I find the file, and can I prove how long it has been kept". Distributed stores are workable at a single location and become expensive to audit at several.

One search surface beats scattered folders

• The RMS recording management system collects, stores and lets you query, replay and manage recording files, and it centralises recordings produced by OM series IP-PBX and MX series gateways.
• The Recording Agent is the site-level collector: it runs on Windows, gathers what OM produces and keeps it as MP3.
• The CDR Software is the site-level index: it gathers OM call detail records as .txt, writes them to an external server and manages retrieval of them.
• Local storage on an OM20G keeps the first deployment simple, and needs a deliberate path into the central store once a second location appears.

Centralisation changes where the evidence sits, not who is accountable for it. Someone still has to define the schedule, approve exceptions and confirm that deletion actually happened. Those tasks get harder when they sit across several systems, so they are worth naming explicitly during setup rather than discovering them during a request.

Retention Policy as a Configuration Task

A retention policy is a schedule plus a set of rules about access. The recording platform only executes it. That makes policy design a configuration exercise with several distinct parameters, and it makes the difference between a policy that exists and a policy that is applied.

What has to be configured

• A retention window for audio. How long a recording stays before it is removed automatically.
• A separate window for call detail records. They are far smaller and often need to outlive the audio, which is worth deciding deliberately rather than by accident.
• Deletion behaviour, including backups. Removing the file from the live store only satisfies the schedule if the copies held in backup are covered too.
• Per-role access rules. A supervisor reviewing their own team's calls should not require the same key as someone auditing the whole system.
• An exception path. An individual recording that must be kept past the schedule needs a named owner and a recorded reason.

Retention periods and disclosure rules differ between jurisdictions and between categories of call, so the windows themselves should come from your own legal or compliance contact. What the platform owes you is consistent application: the same rule across every site, applied on schedule, with an audit trail showing it ran.

1. Write the schedule as explicit periods per record type before configuring anything.
2. Identify every location where a copy of a recording can persist, including backup media and exported folders.
3. Set the deletion action for each location so the schedule applies to all of them.
4. Define the exception process, including who may approve a hold on a specific recording and how the hold expires.
5. Test the schedule end to end. Confirm that a record past its period is gone from the live store and from backup, and that a record under an exception stays put.

Building an Evidence-Ready Recording Process

The recording system is one component. The habits around it decide whether a recording survives contact with a request. A modest routine, run on a fixed cycle, catches most of the failure modes before anyone asks for evidence.

A monthly check that takes less than an hour

1. Pull a recording at random, chosen by extension and date rather than by file name, and confirm you can reach it and play it back.
2. Check the attached metadata against the call: date, time, extension, trunk, direction and duration.
3. Compare the clock on each recorder and each PBX against a reference. Skew shows up as records that fall on the wrong side of a retention boundary.
4. Review free space and the health of the store. A full volume becomes an availability problem well before it becomes a compliance one.
5. Compare the accounts able to retrieve recordings against the current staff list, and remove access for anyone who has left.
6. Confirm that one scheduled deletion actually took effect, including in any backup copy that held the file.

Run the same list once before any handover to a new team or an external reviewer. The point of the routine is not documentation for its own sake; it is that every item is a question you would otherwise be asked under pressure.

Who Owns the Recording Process

Recording controls fail for a predictable reason: nobody is named as responsible for them. The platform executes whatever rule is configured, and a rule that nobody reviews eventually stops matching what the business actually does.

Assign the ownership in writing and split it by activity rather than by department.

• Configuration ownership. Who changes what gets recorded, who changes a retention window, and who approves either change.
• Verification ownership. Who runs the periodic checks and who signs them off.
• Exception ownership. Who authorises keeping one recording past its schedule, and who confirms the hold is later released.
• Escalation ownership. Who to contact when a legitimate request arrives, and who decides what may be disclosed.

Keep this ownership note in the same document as the retention schedule. Held apart, the two drift apart, and a gap in one is usually a gap in the other as well.

Call Recording Compliance and Storage FAQ

How long should recordings be kept?

That answer comes from your own jurisdiction and your own business context, so it should come from your legal or compliance contact rather than from a vendor default or a general article. The point for a platform buyer is narrower: the system has to be able to hold recordings for whatever period is decided, apply that period consistently, and remove what falls outside it. Test the deletion path before you need it, because retention that has never been verified is an assumption.

Do we need a separate recording server?

Sometimes yes, and the deciding question is where recordings need to be reachable from. A single small deployment can rely on the storage built into an OM20G. As soon as recordings have to be found across several locations, reviewed by a central team or produced on request, a central collection layer such as RMS with a Recording Agent per site is the straightforward answer. That is a topology decision about who needs access, and it drives most of the cost.

Are MP3 recordings acceptable to keep?

MP3 is lossy, so it is not identical to the original stream. For quality monitoring, training review and internal assurance it is normally adequate, and it is what the Recording Agent produces on Windows. Where a specific recording may be contested, keep the original encoding for the calls that matter and treat the MP3 as the working copy. Deciding that by category of call is easier than deciding it one dispute at a time.

Who should be able to retrieve a recording?

Fewer people than usually have access today. Give retrieval rights to roles that need them, review them when people change roles or leave, and keep an access list you can produce on request. The list of accounts with read access to recordings is itself part of what you are expected to be able to explain, alongside the list of who gets called on when a legitimate request arrives.

What happens when recordings are deleted?

The deletion has to be complete, not cosmetic. That means covering the live store, any replica, any backup set and any folder where someone exported files for convenience. A deletion that removes the working copy while a backup copy sits on tape or disk has not discharged the schedule. Include backup media in the retention design, and test that a delete in the store is followed by expiry in the backup.

Conclusion

Compliance is delivered by configuration and process, with equipment supplying the capacity to make it possible. The practical next step is to sit down with the person who owns your regulatory obligations and write down four numbers: how long audio is kept, how long call detail records are kept, where copies live, and who may retrieve a file. Then check that the recording arrangement already enforces all four, and that someone tests the deletion path on a schedule. Where gaps show up, the fix is usually a missing rule or an unnamed owner rather than a larger box.