ASD ISM 2126Positively Identify Requestors Before Actioning Account, Banking or Payment Requests
Staff confirm who is really asking, using an agreed authentication method or a separate trusted channel, before changing account or banking details or making payments.
Plain language
This control covers three specific types of request that attackers love to fake: changing a user's account details, changing banking details (for example a supplier's or employee's payment account), and carrying out financial transactions. Before personnel action any of these, they must positively identify the person making the request. The statement allows two ways to do that. The first is a pre-established authentication method, meaning something agreed and set up in advance, such as a shared verification question, a one-time code sent to a registered contact, or an in-person check. The second is an independent trusted communication channel, meaning staff go back to the requestor using contact details the organisation already holds (for example calling a known phone number) rather than replying to the email or message that carried the request. Why it matters: business email compromise and impersonation fraud work precisely because a convincing email, text or call is taken at face value. A criminal who can get a help desk to reset an account, or an accounts payable clerk to "update" a supplier's bank account, does not need to break any technical control. Independent verification breaks that chain because the attacker usually does not control the registered phone number or the agreed authentication method.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
05 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for personnel securityTopic
Synthetic impersonation
Official control statement
Personnel positively identify requestors using a pre-established authentication method or independent trusted communication channel before actioning requests to modify user account details, modify banking details or conduct financial transactions.
Why it matters
Without positive identification, a forged email, spoofed phone call or hijacked mailbox can be enough to have an account handed to an attacker, a supplier's or employee's banking details redirected to a criminal's account, or a fraudulent payment released. The result is direct financial loss that is often unrecoverable, account takeover leading to further compromise, and disruption while payments are traced and accounts restored.
Operational notes
In daily operation this control lives with the help desk, HR, payroll and accounts payable teams. Each of those teams needs a clear rule: a request to modify user account details, modify banking details or conduct a financial transaction is not actioned until the requestor has been positively identified. The person actioning the request records how the identity was confirmed, for example "called back on the phone number held in the vendor master file" or "one-time code sent to registered mobile and read back". Staff should treat urgency, pressure and requests to use a new phone number or email as reasons to slow down rather than speed up. Callback numbers and verification methods must come from records the organisation already holds, never from the request itself. Keep verification records with the change or payment so they can be reviewed later.
Implementation tips
- Have the security or finance lead define, in the relevant procedures, which requests are in scope (modifying user account details, modifying banking details, conducting financial transactions) and which authentication methods or independent channels are acceptable for each.
- Have the IT help desk set up a pre-established authentication method for user account changes, such as a one-time code sent to the user's registered contact or verification via an existing MFA prompt, and configure ticketing so the request cannot be closed without recording the method used.
- Have accounts payable and payroll maintain verified contact details for suppliers and employees in the master file, and require staff to call back on those held numbers (not numbers in the request) before any banking detail change is saved.
- Have finance apply the same callback or pre-agreed authentication step to instructions to make payments or other financial transactions, and configure payment systems so a second person confirms that verification was completed before release.
- Have team leads brief help desk, HR, payroll and finance staff on the procedure, including how to handle pressure or urgency in a request, and rehearse it with example impersonation requests so the verification step becomes routine.
Audit / evidence tips
- AskAsk for the written procedures covering user account changes, banking detail changes and financial transactions.Look atLook for an explicit step requiring positive identification of the requestor and a description of the accepted authentication methods or independent channels.GoodEach of the three request types has a documented verification step, and the methods listed are set up in advance or use contact details the organisation already holds.
- AskAsk for a sample of recent user account modification tickets from the help desk.Look atLook at what was recorded about how the requestor was identified before the change was made.GoodEvery sampled ticket shows the authentication method used, and none relied solely on the requesting email or message.
- AskAsk for a sample of recent supplier or employee banking detail changes.Look atLook for evidence that staff contacted the requestor through an independent channel such as a callback to a number already on file.GoodEach change carries a record of the callback or pre-agreed check, with the contact details sourced from existing records rather than the request itself.
- AskAsk for a sample of financial transactions initiated from an emailed or phoned instruction.Look atLook for the verification record attached to the transaction and who confirmed it before release.GoodTransactions show the requestor was positively identified before the payment was actioned, and the verification is traceable to a named person.
- AskAsk how staff in help desk, HR, payroll and finance were made aware of the verification requirement.Look atLook at briefing or training records and any guidance on handling urgent or unusual requests.GoodRelevant staff can describe the verification steps for each request type and records show they have been briefed on them.
Cross-framework mappings
How ISM-2126 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(1)expand_less | ||
| Annex A 5.18 | ISM-2126 requires personnel to confirm who is requesting changes before modifying user account details, banking details, or conducting fi... | |
handshakeSupports(3)expand_less | ||
| Annex A 5.15 | ISM-2126 requires a procedural control where staff verify a requestor's identity through a pre-established method or trusted channel prio... | |
| Annex A 5.17 | ISM-2126 requires a defined way to authenticate requestors (or use an independent trusted channel) before executing account, banking, or ... | |
| Annex A 8.5 | ISM-2126 requires personnel to positively identify requestors via a pre-established authentication method or an independent trusted chann... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in Personnel security
See all Guidelines for personnel security controls, or browse the full ASD ISM library.