A caller verification policy your desk will actually follow

Nearly every IT desk has a verification policy. Far fewer have one an engineer can follow while a caller is talking to them. The usual document runs to four pages, opens with a scope statement, and gets read once during induction — which means that at the moment it matters, the actual policy is whatever the engineer remembers and how much of a hurry the caller is in.

What follows is a template built the other way round: short enough to sit on one page beside the phone, specific about what counts as proof, and explicit about what to do when the answer is no. Take it, change the names, and make it yours.

The template

1. Factors we accept

Identity is confirmed by factors registered in advance, never by information a caller supplies during the call. We accept:

• A one-time code delivered to the mobile number held on the contact record.
• A reply from the email address held on the contact record, sent to that address by us — not from an address the caller reads out.
• A passphrase agreed with the client in writing and stored on the contact record.
• Confirmation from a named approver already listed on the client account.

2. Factors we do not accept

• Caller ID, on its own or in combination. Numbers are trivially spoofed.
• Date of birth, home address, National Insurance number, employee number, or a manager's name. All of it is researchable or already in a breach dump.
• Recognition of the caller's voice, however familiar.
• An email or Teams message from an account we cannot confirm is uncompromised — the compromised account is the point of the attack.

3. How many factors

• Routine, non-sensitive request (status update, printer queue, software query): one factor.
• Sensitive request (password reset, group membership, mailbox rule, remote session on a server): two factors.
• Privileged request (MFA or token re-enrolment, admin account creation, credential release, changes to an approver list): two factors and sign-off from a named approver on the account.

4. When verification fails

If a caller cannot verify, we do not complete the request. We do the following, in order:

1. Offer a call-back to the number on the contact record. This alone defeats most impersonation.
2. Offer to route the request through a named approver at the client.
3. Record the failed attempt on the ticket, including what was tested and what did not match.
4. Notify the client's security contact if the same identity is attempted more than once in a day.

Nobody is disciplined for refusing a request that could not be verified. That sentence belongs in the policy, in writing, signed by whoever runs the desk.

5. Escalation is never a personal decision

An engineer may always escalate rather than judge. Any caller who applies pressure — invokes seniority, cites an outage, threatens to complain, or asks the engineer to make an exception — is escalated by default, and the pressure itself is noted on the ticket.

6. What we record

For every sensitive or privileged request: the factors tested and their results, the approver and their decision, the action taken, the person who took it, and the time. Records are appended, never edited.

Three things that make the difference between a policy and a document

Pre-register the factors, or none of this works

A policy that says "verify the caller" without saying what you verify against is an instruction to improvise. Factors have to exist on the contact record before the call, which means onboarding a client includes collecting mobile numbers, agreeing passphrases and naming approvers. That is the unglamorous work the whole control rests on — see caller verification for how those factors get used in practice.

Make refusing cheaper than complying

Engineers skip checks because checking is socially expensive and skipping is free. If refusal means an awkward conversation and a possible complaint, while compliance means a happy caller, the policy loses. Fix the incentive rather than the wording: publish the escalation route, make it fast, and back the engineer publicly the first time someone complains.

Put the record where the work happens

A verification recorded in a free-text note is a verification you will not find in nine months. Recording what was checked against the ticket, immutably, is what turns the policy into something you can demonstrate — to a client, an insurer or an assessor. That is the difference between having a control and being able to evidence one.

Rolling it out

1. Adapt the template — the thresholds in section 3 are the part most worth arguing about internally.
2. Collect the factors for your top ten clients by risk, not alphabetically.
3. Agree the approver list with each client and get it in writing.
4. Run one tabletop: a colleague phones the desk pretending to be a client's finance director in a hurry. What happens is your real policy.
5. Review after a month, and fix whichever clause got quietly ignored.

If you would rather the thresholds were enforced by the system than remembered by the engineer, that is the whole idea behind Certra's approval workflows — the policy becomes configuration on the account rather than a page beside the phone.