Testing the service desk: vishing as a process control test

A vishing test against the service desk answers one question: does the identity-verification procedure hold when a caller supplies the conditions it was never written for? The answer is a statement about the procedure, not about the agent who took the call.

That distinction decides the design of the exercise. "An agent was fooled" is a personnel observation, and a control owner can do nothing with it. "The identity-verification step reduces to a single knowledge factor when the caller asserts a deadline and names a senior manager" is a control finding, and it has a remedy. Everything about how the test is authorised, run and reported exists to produce the second sentence rather than the first.

Why the service desk is the process worth testing

The service desk exists to help people who are locked out, under time pressure, and unable to authenticate the normal way. Those are exactly the conditions a social engineer manufactures. Everywhere else an unauthenticated person asking for access is an anomaly; at the desk it is the job, and the procedure is the only thing between a plausible caller and a working credential.

Two procedures carry most of that risk. Credential reset ends with the caller holding a working password. MFA re-enrolment ends with the caller holding a working second factor, and it is the more consequential of the two: a factor bound to an attacker's device survives the password change that follows the incident.

Both are also written down: an employee identifier, a callback to the number on record, a ticket raised by someone other than the caller. A documented procedure is a testable control, and that is what makes this a process test rather than an awareness one. The unit of measurement is the step, not what the agent retained from a training session.

The clause this work is scoped under

CERT-In's Comprehensive Cyber Security Audit Policy Guidelines, CISG-2025-02, Version 1.0, 25 July 2025, set out engagement types at §6, pp. 14–17, "including, but not limited to" the twenty-five listed. A vishing test against a documented desk procedure is scoped under item (x) Process Security Testing. The guidelines make the link themselves: §15.2.2(iii) governs "Social engineering and process testing" as one subject, which is the pair this exercise combines.

§13.2.7(ii), p. 50, sets the precondition:

"Specific written permissions must be obtained from the auditee organization before conducting tests that involve survivability failures, denial-of-service (DoS), process testing, or social engineering."

Two of those limbs are engaged at once, and the word carrying the weight is specific. The permission must name what is being tested.

What the authorisation settles before a call is placed

Which procedures are in scope, and where the call stops. List them by procedure and account tier, then set the stop point. The test establishes that the verification steps were satisfied and the agent moved to execute; the execution itself need not happen.

Which identities may be impersonated. §15.2.2(iii) is explicit that these tests "must only target group of employees explicitly included within the agreed audit scope" and "must not involve external entities such as customers, business partners, vendors, or other third parties, unless specific written consent is obtained from the target organization". A pretext borrowing the identity of a named vendor engineer or a real customer contact engages that sentence directly. So does the account impersonated: an executive the caller claims to be belongs in the authorised population.

The escalation and stop route. A named contact, reachable for the whole calling window, who can stand a call down. An agreed answer to what happens when the desk does the right thing and raises a genuine incident. And the rule that the exercise yields to a real one.

The live-call problem. A call reaches a named individual in real time, and a desk roster is small. That makes §15.2.2(iii)'s requirement of "anonymized or statistical techniques—ensuring no individual is personally identified or penalized" harder to honour than it is across an email campaign of thousands, and more important to design for. The clause states the purpose it serves: "to evaluate overall awareness and the effectiveness of security processes, not to single out individuals". A service desk test is the second half of that sentence exactly.

Four structural choices make the finding attach to the procedure:

• Volume and spread. Calls placed across the roster, shifts and hours, in enough number that no single call is the finding. The unit of analysis is the verification step, not the conversation.
• A deliberately varied condition. What changes between calls is a property of the pretext: the pressure applied, the authority claimed, the account facts offered. The result then reads as "the step held under these conditions and not under those", a procedural statement.
• What is recorded. The sequence of verification steps attempted and the outcome of each. Agent identity is an artefact of running the test, not an output of it. DPDP s.8(5) governs the safeguards over that record, and s.8(7)(a) requires erasure "as soon as it is reasonable to assume that the specified purpose is no longer being served". Once the finding is written against the step, that purpose is served.
• Who receives it. The debrief is held with the owner of the procedure, and the desk hears the outcome as a change to the procedure.

The mechanisms that work, and what each one exposes

Four mechanisms recur, and it is the mechanism rather than the script that a control owner can act on.

• Urgency with plausible authority. A deadline the agent can picture, attached to a name senior enough that obstructing it feels expensive. It exploits a procedure that permits discretion without recording it. The remedy is a procedure with no unrecorded discretionary path: exercising an exception requires a second, logged approval.
• A partially known account detail. Verification sets are often built from semi-public facts: identifier formats, reporting lines, office locations, start dates. The weakness is not that the fact is discoverable. It is that possession of a fact about a person is treated as evidence of being that person. The remedy is verification that turns on something the organisation issued and can invalidate.
• The callback that never happens. The procedure requires a return call to the number on record; the caller offers a reason that number cannot be used. The property exploited is a control the party it authenticates is allowed to waive. The remedy is that the callback is not the caller's to waive: if the number on record is unusable, the request leaves the phone channel.
• The second voice. An escalation to a "manager" who is part of the same operation, so corroboration arrives from inside the same conversation. The property exploited is an approval asserted rather than established. The remedy is approval resolved from the directory, through a channel the caller does not touch.

What the output looks like

The report is a set of statements about steps. Each names the procedure, the step, the condition under which it held or was skipped, the point in the call it happened, and what the procedure should require instead.

The right-hand column can be assigned an owner, a date and a retest. The left-hand column can only be handed to somebody's line manager, which produces a defensive desk, a lower reporting rate and no change to the control.

Hold three artefacts: the specific written permission §13.2.7(ii) requires, naming the procedures and the stop route; the finding set written against steps; and the amended procedure text, dated. A fourth arrives later and turns the exercise into evidence: the retest, on the same clock as the rest of the awareness programme, showing the amended step holds. A dated procedure, a dated test against it and a dated retest is what an "up-to-date repository of the training and awareness status of all users" looks like for a control rather than a course.

The question a service desk test answers is not whether a caller got in. It is whether the procedure requires what it should, and whether the organisation can show that it does.