ASD ISM 2126 Positively identify requestors before actioning account, banking or payment requests
What it says
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.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishStaff confirm who is really asking, using an agreed authentication method or a separate trusted channel, before changing account or banking details or making payments.
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.
Free. Save your status, tasks and notes.
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.
How to implement
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.
Keep it running
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.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the written procedures covering user account changes, banking detail changes and financial transactions.
Look at
Look for an explicit step requiring positive identification of the requestor and a description of the accepted authentication methods or independent channels.
Good evidence
Each 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.
- Check 2 of 5What an auditor asks for
Ask for
Ask for a sample of recent user account modification tickets from the help desk.
Look at
Look at what was recorded about how the requestor was identified before the change was made.
Good evidence
Every sampled ticket shows the authentication method used, and none relied solely on the requesting email or message.
- Check 3 of 5What an auditor asks for
Ask for
Ask for a sample of recent supplier or employee banking detail changes.
Look at
Look for evidence that staff contacted the requestor through an independent channel such as a callback to a number already on file.
Good evidence
Each change carries a record of the callback or pre-agreed check, with the contact details sourced from existing records rather than the request itself.
- Check 4 of 5What an auditor asks for
Ask for
Ask for a sample of financial transactions initiated from an emailed or phoned instruction.
Look at
Look for the verification record attached to the transaction and who confirmed it before release.
Good evidence
Transactions show the requestor was positively identified before the payment was actioned, and the verification is traceable to a named person.
- Check 5 of 5What an auditor asks for
Ask for
Ask how staff in help desk, HR, payroll and finance were made aware of the verification requirement.
Look at
Look at briefing or training records and any guidance on handling urgent or unusual requests.
Good evidence
Relevant staff can describe the verification steps for each request type and records show they have been briefed on them.
Mappings
Closest match in ISO/IEC 27001: A.5.17, Management of authentication information, which partially overlaps with this control.
ISO/IEC 27001: 2 mappings
This control partially overlaps A.5.17.
ISM-2126 requires a defined way to authenticate requestors (or use an independent trusted channel) before executing account, banking, or payment requests. ISO/IEC 27001:2022 Annex A 5.17 supports this by requiring controlled allocation and management of authentication information, ensuring the credentials/factors used for positive identification are governed and handled appropriately. Annex A 5.17 focuses on the management lifecycle and handling of authentication information, whereas ISM-2126 focuses on the operational verification step before processing sensitive requests.
This control partially overlaps A.5.18.
ISM-2126 requires personnel to confirm who is requesting changes before modifying user account details, banking details, or conducting financial transactions. ISO/IEC 27001:2022 Annex A 5.18 overlaps because it governs how access rights are provisioned, reviewed, modified and removed, which includes the act of modifying account details and entitlements. The overlap is on securely actioning changes to accounts/access, but Annex A 5.18 does not specifically require out-of-band or trusted-channel identity verification for banking/payment requests as ISM-2126 does.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.