What an auditor actually asks for

Most teams get ready for an audit by writing documents. They tidy the policy folder, refresh the security statement and rehearse the summary. Then the auditor arrives and asks something much smaller and much harder.

Show me this call. Who listened to it? Who changed this setting, and when? This agent left in March. When did their access end?

That is the shape of nearly every audit question. It is not about what you intend to do. It is about whether you can produce a record of what actually happened.

Policies describe. Records prove.

A policy says calls are recorded and access is limited. An auditor accepts that as a claim, then asks you to demonstrate it on a case they pick. If your answer starts with we would normally, the control has not been tested. It has been described.

So the useful preparation is not more writing. It is checking that for each claim you make, there is a record you can pull up in front of someone.

An auditor is not trying to read your policy. They are trying to find the gap between the policy and the system.

The five questions to expect

The wording changes between frameworks, but the substance repeats. If you can answer these five with evidence, most of an audit goes quietly.

1. 01Who has access to customer data, and who approved it?
2. 02Who saw this specific record, and when did they see it?
3. 03Who changed this setting, what was it before, and when did it change?
4. 04Was this call recorded, and if not, why not?
5. 05This customer asked you to stop. When did you stop, and what proves it?

Notice how specific they are. Each one names a thing and asks for a timestamp. That is why a general report is rarely enough. You need to be able to search for one record and show its history.

What has to exist in the system

Working backwards from those questions gives you a short list of things the software has to do on its own. Not things a person has to remember to do.

• A log of every change, showing who made it and when.
• A log of every access to a recording or a customer record, not just of edits.
• Roles that limit who can do what, so access is a setting rather than a habit.
• Recording rules set per campaign, so on and off are both deliberate.
• Retention that expires data automatically at the period you chose.
• Suppression that takes effect immediately, with a record of when it did.

Where teams usually fall down

Three gaps come up again and again, and none of them are exotic.

The first is access that outlives the person. Someone leaves, their account stays open, and nobody can say when it should have closed. Reviewing access on a schedule fixes this, but only if the review is recorded.

The second is masking that only exists on screen. Sensitive fields look hidden in the interface, but the underlying data sits readable in the database and in exports. An auditor will ask where the masking is applied. In the interface is the wrong answer.

The third is retention as an intention. The policy says twelve months. Nothing enforces it, so recordings from four years ago are still there. You now hold data you told a regulator you would not.

How to prepare properly

Run the audit on yourself first. Pick a call from three weeks ago at random. Try to answer all five questions about it, using only the system, with someone timing you.

You will find the gaps quickly. Either the record is there and you can produce it in a minute, or it is not, and no amount of policy writing will change that on the day.

That rehearsal is also the honest way to judge a vendor. Ask them to walk that exact exercise on their own product, live. A platform built for the audit will make it look boring. That is the point.