---
title: "Callback Verification Policy for Vishing Attacks"
description: "Build a callback verification policy with known-number callbacks, dual control, scripts, logs, and escalation rules for payments and credential resets."
category: "Guides"
date: 2026-08-20
canonical: https://www.brside.com/blog/callback-verification-policy-vishing
source: "Brightside AI"
image: https://www.brside.com/assets/callback-verification-policy-vishing.B4h08luG.jpg
---

# Callback Verification Policy for Vishing Attacks

An employee gets a call from someone who sounds like the CFO. The caller needs a supplier paid before the bank closes. A help-desk agent gets a different call from an executive who lost a phone and needs multi-factor authentication reset before a flight. Both employees know they should "call back to verify."

That instruction is too vague to protect either action. Which number should they use? Who must answer? What must they confirm? Can the same employee verify and execute the request? What happens if the trusted contact is unavailable?

A callback verification policy answers those questions before the urgent call arrives. It stops a convincing voice, familiar face, valid email account, or spoofed caller ID from becoming authority to move money or change credentials. Some vishing calls will still reach employees, but covered actions stop when independent verification fails.

## What you'll learn

- Which payment, identity, and data requests must trigger independent verification
- What qualifies as a known number and which contact sources are prohibited
- How to separate the requester, verifier, approver, and executor
- What staff must record when verification succeeds or fails
- How to roll out, audit, and rehearse the policy

## Why "call back to verify" is not a policy

An inbound call cannot verify itself. Caller ID is easy to spoof, and the [joint CISA phishing guidance](https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one) specifically warns that attackers use internet calling services to exploit trust in phone numbers. A number in an email signature, attachment, chat message, or support ticket can also belong to the attacker. Calling it creates a second conversation, but not an independent check.

The number must come from a record that existed before the request. For an employee, that may be a controlled HR or identity record. For a supplier, it may be the vendor master, contract record, or an approved procurement contact. For an executive, it may be the company directory. The requester must not be able to change the trusted record and use it for verification in the same workflow.

The callback must also confirm authority. Reaching the real supplier does not prove that the person who answers can change its bank account. Reaching the real employee does not prove that the employee may request a privileged role or a bulk data export. Verify who the person is, whether the request is genuine, and whether that person has authority to make it.

There is one more limit. A phone callback is a useful business control, but it is not phishing-resistant digital authentication. [NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) classifies authentication over the public telephone network as restricted and says ordinary out-of-band authentication is not phishing-resistant. A callback can support an account-recovery decision. It should not replace a trusted authenticator, identity proofing, or an independent approval for a high-risk reset.

## Use this callback decision matrix

Start with the action, not the size of the request or the confidence of the employee. A small beneficiary test payment can prepare a larger theft. A password reset for an ordinary account can become a route into email, payroll, or cloud applications.

Customize the matrix to match your systems and authority model. The minimum verification column is a floor, not permission to ignore stronger controls already in place.

| Request type | Trusted source | Minimum verification | Independent control | Hold, restriction, or failure path |
|---|---|---|---|---|
| New supplier or beneficiary | Approved procurement record, signed contract, or vendor master | Outbound call to an established authorized contact; confirm the relationship and complete payment details | Separate approval of the new record | Hold creation and payment if no trusted contact exists |
| Supplier bank-detail change | Existing vendor-master contact that predates the request | Outbound call; read back the old and new details, reason, and effective date | Second person reviews the callback record and approves the change | Apply [Hold period] before the first payment where required |
| Wire, urgent payment, or gift cards | Approved executive directory, ERP, or banking mandate | Confirm the request and business purpose through an independent channel | Separate preparation and release | Stop and escalate if secrecy or urgency is used to bypass the process |
| Payroll or direct-deposit change | Authenticated HR system and pre-registered employee contact | Employee self-service with strong authentication, or callback plus approved proof | HR or payroll approval where policy requires it | Notify the old contact channel and hold suspicious changes |
| Trusted contact change | Existing contact record, relationship owner, or signed amendment | Verify through the old contact and a separate record owner | Approver cannot be the person making the change | New contact cannot verify another protected action in the same session |
| Password reset | Identity system and pre-registered employee channel | Existing authenticator or approved identity-proofing process | Follow risk-based help-desk approval rules | Escalate when all authenticators are unavailable |
| MFA reset or new authenticator | Identity system, enrolled device, and manager record | Strong identity proof plus established-channel confirmation | Manager or security approval for high-risk accounts | Restrict access and monitor new enrollment |
| Privileged-account recovery | Privileged access system and security-owned identity record | High-assurance proofing through a separate recovery path | Security approval outside the help desk | Temporary limited access, session revocation, and [Cooling period] |
| Remote access or software installation | Official support portal and vendor account record | Confirm ticket and technician through official support contacts | Local IT or security approval | End the call and open a fresh ticket if the request was unsolicited |
| Sensitive-data release | Data-owner record and approved request system | Confirm identity, request, purpose, and authority | Data owner, privacy, legal, or security approval as required | Do not send data to a new personal address or unapproved channel |

## Copy-ready callback verification policy

The policy below is an operational template, not legal advice. Replace every bracketed field. Ask finance, identity, HR, procurement, privacy, legal, and compliance owners to review the parts that affect their work. Keep the final policy short enough for staff to use during a live request.

### Purpose

[Organization] requires independent verification before staff complete a protected action requested through phone, email, text, collaboration software, video, or another communication channel.

The policy prevents a communication channel from acting as authorization. A familiar voice, recognizable face, valid account, internal display name, caller ID, or urgent business explanation must not replace the approved verification and authorization process.

### Scope

This policy applies to:

- Employees, contractors, temporary staff, and service providers who receive or process protected requests
- Finance, accounts payable, treasury, payroll, HR, procurement, executive support, IT, help desk, security, privacy, and data-owning teams
- Requests received through corporate or personal phone numbers, email, messaging applications, video meetings, support portals, or in person when identity or authority is uncertain

[Policy owner] must maintain the list of covered teams, systems, and protected actions.

### Definitions

**Protected action.** An action that can move money, change payment routing, modify a trusted contact, reset or weaken authentication, add access, install software, enable remote control, or release sensitive information.

**Request channel.** The phone call, message, email thread, meeting, ticket, or other path used to submit the request.

**Trusted system of record.** An approved source that [Organization] controlled or validated before the current request, such as the vendor master, HR system, identity directory, banking mandate, signed contract, or official support portal.

**Independent verification.** A check initiated through a trusted system of record that does not rely on contact details, links, accounts, or evidence supplied in the request.

**Dual control.** Review by a second authorized person who examines the independent verification evidence before approving or executing the action. Two employees relying on the same request channel do not satisfy dual control.

### Protected actions

Staff must apply this policy to the protected actions listed in [Protected action register]. At minimum, [Organization] must decide whether the register covers:

- New suppliers, beneficiaries, or payment destinations
- Changes to supplier, customer, or employee bank details
- Wire transfers, urgent payments, gift cards, refunds, and payment releases
- Payroll, direct-deposit, tax, benefits, or employee-record changes
- Changes to a trusted phone number, email address, relationship owner, or recovery channel
- Password resets, MFA resets, authenticator removal, new-device enrollment, and account recovery
- Privileged access, role changes, administrative elevation, and break-glass access
- Unsolicited remote support, screen sharing, software installation, and remote-management tools
- Release of credentials, one-time codes, recovery links, customer data, employee data, legal records, or other sensitive information

The trigger must follow the action. Seniority, urgency, confidentiality, travel, familiarity, and transaction value must not remove a protected action from the policy.

### Trusted systems of record

[Policy owner] must publish the approved system of record for each protected action. Each system must have a named owner, access controls, change history, and a review schedule.

Staff may use contact information from:

- [Approved vendor master]
- [Approved HR or identity system]
- [Approved executive directory]
- [Approved contract or procurement record]
- [Approved banking or customer relationship record]
- [Approved support portal or vendor account record]

Staff must not use:

- Caller ID or the phone's callback function
- A number, address, account, QR code, or link provided by the requester
- An email signature, attachment, invoice, or document included with the request
- Contact information in the same email thread, chat, ticket, or meeting
- A new website or search result reached through the request
- A contact record created or changed as part of the same request

When no trusted contact exists, staff must place the action on hold. [Relationship owner] must establish and verify a trusted contact through a separate onboarding or recovery process before the protected action resumes.

### Standard verification procedure

The employee handling a protected request must:

1. **Capture the request.** Create or update the required case in [Ticket, ERP, HR, or case-management system]. Preserve the original communication and record the requested action.
2. **Classify the action.** Select the request type and risk class from [Protected action register]. Apply the required approval, hold, and recovery rules.
3. **Pause the request channel.** End or pause the inbound call, meeting, message, or email exchange. Do not disclose extra information while arranging verification.
4. **Find the trusted contact independently.** Retrieve the number or approved channel from the named system of record. Record the system and record used.
5. **Initiate the contact.** The verifier must place the outbound call or start the approved independent session. An inbound return call does not satisfy this step.
6. **Confirm identity and authority.** Verify that the person reached is the expected contact and has authority over the requested action. Do not use public or easily discovered information as primary proof.
7. **Confirm the action in detail.** Read back the request, affected account or record, amount or access change, new destination, effective date, reason, and other material details. Avoid a single yes-or-no question.
8. **Record the result.** Document who was reached, what was confirmed, any inconsistencies, and the final verification result.
9. **Obtain required approval.** Send the request and verification record to the independent approver. The approver must review the evidence before approval.
10. **Execute and notify.** The authorized executor completes the action only after all required controls pass. Send notifications through the approved old and new channels where the action type requires them.

If any step fails, the employee must not proceed to a weaker check simply to complete the request.

### Independent dual control

[Organization] must define which protected actions require a second approver. New beneficiaries, bank-detail changes, high-risk payments, privileged-account recovery, authenticator replacement for sensitive users, and bulk sensitive-data release should receive explicit consideration.

The independent approver must:

- Have authority for the action
- Review the source of the trusted contact
- Review the identity and authority checks
- Review the material details confirmed during the callback
- Check required holds, restrictions, alerts, and exceptions
- Record approval or rejection with a timestamp and named account

The requester, verifier, approver, executor, and reconciler should be separate people where the risk and staffing model support it. If a small team must combine roles, it must preserve an independent approver for the protected actions named in [Dual-control register].

Shared accounts, forwarded approval emails, verbal summaries, or two approvals based on the same unverified request do not satisfy this requirement.

### Documentation

Every protected request must have a verification record in [System]. The record must include:

- Request type, requester, source channel, and date
- Requested action and affected account, supplier, employee, system, or dataset
- Risk class and required controls
- Trusted system of record and the record identifier used
- Contact number or channel used for verification
- Verifier and person reached
- Identity and authority checks completed
- Material details read back and confirmed
- Anomalies, failed attempts, or pressure to bypass policy
- Approver, executor, decision, and timestamps
- Hold, restriction, notification, escalation, and exception details

[Record owner] must retain records for [Retention period] under the organization's legal, privacy, audit, and contractual requirements.

### Failed verification and escalation

Verification fails when:

- The trusted contact cannot be reached within the permitted time
- The number is wrong, disconnected, newly changed, or disputed
- The person reached denies the request or lacks authority
- Answers conflict with the request, the system of record, or known business context
- The requester resists the callback, supplies replacement contact details, or demands an exception
- The request combines urgency, secrecy, unusual timing, a new channel, or an unexpected destination
- A payment or identity change follows a recent contact-record change, password reset, mailbox incident, or device enrollment

The employee must place the action on hold, preserve evidence, and notify [Escalation contact]. Security, finance, identity, privacy, legal, HR, or another owner must join the review according to [Escalation matrix].

Staff must not accuse the requester of fraud. They should state that the verification process could not be completed and that the request has moved to review.

### Exceptions and non-waivable controls

Urgency, confidentiality, executive seniority, travel, customer pressure, revenue impact, and after-hours timing do not create an exception by themselves.

[Organization] must document:

- Which controls can never be waived
- Who may approve an exception
- Which compensating controls are required
- How long an exception remains valid
- Which evidence and business reason the requester must provide
- Who reviews the exception after the event

An exception approver must not approve their own request. Exceptions must be recorded in [Exception register] and linked to the verification record.

If no approved exception path can meet the required assurance, the action must remain on hold.

### Ownership, review, testing, and enforcement

[Policy owner] owns this policy. Finance owns payment and vendor controls. Identity and security own credential recovery and privileged access controls. HR owns employee-record and payroll verification inputs. Procurement owns supplier onboarding records. Data owners, privacy, and legal own approval paths for sensitive-data release.

System owners must build required fields, approvals, holds, alerts, and logs into the relevant tools where feasible. Managers must train staff on the procedure and give them permission to delay a request without retaliation.

[Policy owner] must review the policy every [Review interval] and after a material incident, control failure, system change, or new protected action. Testing must include record sampling, failed-verification scenarios, exception review, and exercises that apply realistic urgency.

Violations must follow [Enforcement policy]. The review should distinguish deliberate bypass from a process or system design that made compliance impractical.

## Apply the policy to money and payment changes

Within a broader [BEC prevention framework](/blog/how-to-prevent-business-email-compromise), payment verification fails when the message that requests the change also supplies the evidence used to approve it. That remains true when the request comes from a real supplier mailbox. An attacker who controls the mailbox may edit the signature, send a replacement remittance document, reply to questions, and arrange for an accomplice to answer a new phone number.

The [U.S. Secret Service](https://www.secretservice.gov/investigations/bec) recommends strong verification policies and a call to a known number before payment. The operational detail matters. Get the number from the vendor master, signed contract, or relationship record that existed before the request. Call the authorized contact responsible for payment instructions.

Do a meaningful read-back. Confirm the existing relationship, the old and new bank details, the reason for the change, the effective date, the affected invoices, and whether the named person has authority. "Did you request this change?" is weak because the employee may reach the wrong person or omit the part the attacker altered.

Treat a contact change as a protected action of its own. If a supplier asks to change its phone number and bank account at once, verify the phone-number change through the old contact or a separately validated relationship owner. Do not let the new number verify the bank change in the same session.

Dual control should separate evidence from execution. The second approver reviews the source record, callback notes, material details, and any hold before approving the master-data change or payment. A second click based only on the first employee's summary is not independent approval.

Thresholds can reduce workload, but they also teach attackers where the line sits. Apply the policy to new beneficiaries and bank-detail changes regardless of the first payment amount. Monitor split payments and small test transactions. Where the business can support it, place the first payment after a change on a risk-based hold and notify the old trusted contact.

Payroll changes need the same care. Prefer authenticated self-service with strong authentication and change alerts. If staff process a manual direct-deposit request, verify it through the pre-existing employee record, notify the old contact path, and review changes submitted near payroll cutoff or shortly after account recovery.

## Apply the policy to password, MFA, and access changes

Strong login authentication can be undone by weak recovery. An attacker who cannot phish a security key may call the help desk, claim every device is lost, and ask an empathetic agent to register a new authenticator.

[Federal banking regulators](https://www.federalreserve.gov/frrs/guidance/authentication-and-access-to-financial-institution-services-and-systems-interagency-guidance.htm) identify call centers and IT help desks as recurring social-engineering targets. [New York DFS](https://www.dfs.ny.gov/industry-guidance/industry-letters/il20240927-cyber-alert-social-engineering) has warned regulated entities about attackers using voice alteration and public information to obtain password resets and redirect MFA to new devices.

Do not use caller ID, date of birth, employee number, manager name, office address, job title, or the last digits of a government identifier as primary proof. Attackers can collect those details from company pages, social media, data brokers, prior breaches, or a compromised mailbox.

For an ordinary password reset, use an existing authenticator or an approved identity-proofing workflow. For MFA removal, new-device enrollment, privileged recovery, or a sensitive user's account, add a separate manager or security approval. [Google Threat Intelligence Group's UNC6040 hardening guidance](https://cloud.google.com/blog/topics/threat-intelligence/unc6040-proactive-hardening-recommendations) recommends a multilayered identity-verification process and an extra out-of-band check for high-risk changes.

When a user has lost every authenticator, move to a designed recovery path. Do not improvise a weaker check on the phone. The fallback may include higher-assurance identity proofing, manager confirmation through a verified corporate channel, in-person support, or a pre-approved recovery process. Pick the combination that matches the account's authority and your privacy obligations.

Limit the recovered account until risk drops. A temporary access pass or replacement credential should not immediately permit privileged administration, payment changes, mailbox delegation, new OAuth grants, or another authenticator change. Apply [Cooling period] where approved, revoke existing sessions and refresh tokens, review registered devices, and alert the user and manager through established channels.

Unsolicited support calls require the reverse check. If someone claims to be a software vendor, bank, managed service provider, or internal IT technician, end the interaction. Open the official support portal or call the account manager from the vendor record. Confirm the ticket before permitting screen sharing, installing software, running commands, or disclosing system information.

## Give staff scripts and a verification record

Good scripts remove the social burden from the employee. They let the employee explain the process and follow it without accusing anyone of lying.

### Pause an inbound request

> "I can't approve this from an inbound call. I'll open the request and call the number in our directory. We can continue after that verification."

### Refuse a supplied number

> "I can't use contact details included with the request. Our policy requires me to use the existing record. If that record is out of date, we need to update it through a separate process first."

### Handle [executive urgency](/blog/stop-voice-phishing-scams)

> "I understand the deadline. The verification and second approval still apply to urgent and confidential requests. I'll start them now and update you through the approved channel."

### Handle a lost-device recovery

> "Because the request changes your authentication, a phone call alone isn't enough. I'll move this to our account-recovery process and contact your approver through the directory."

### Handle no answer

> "We couldn't reach the trusted contact, so the request is on hold. The relationship owner or escalation team will use the documented fallback. We can't switch to the number in the request."

### Report a failed check

> "The request did not pass callback verification. I preserved the message and callback record and sent the case to [Escalation contact]. No payment, reset, or access change was completed."

The [Canadian Centre for Cyber Security](https://www.cyber.gc.ca/en/what-voice-phishing-vishing-itsap00102) advises people to hang up and call a known, trusted number rather than using the callback function or a number supplied by the caller. The scripts put that advice into normal workplace language.

The case record should let another person reconstruct the decision without asking the verifier to remember the call.

| Record field | What to capture |
|---|---|
| Request | Type, source channel, requester, time, and exact action |
| Affected item | Supplier, beneficiary, employee, account, device, payment, role, or dataset |
| Risk class | Required verification, approval, hold, restriction, and notification |
| Trusted source | System name, record identifier, owner, and last relevant change |
| Callback | Number or approved channel used, time, verifier, and answer status |
| Person reached | Name, role, relationship, and confirmed authority |
| Read-back | Material details confirmed, denied, or corrected |
| Anomalies | Urgency, secrecy, conflicting data, new channel, resistance, or recent changes |
| Approval | Approver, evidence reviewed, decision, and timestamp |
| Execution | Executor, completed action, time, notifications, and restrictions |
| Failure or exception | Hold, escalation, exception authority, compensating controls, and review date |

A complete record protects more than the audit. It lets security connect a suspicious callback to a recent mailbox takeover, MFA reset, vendor-master change, or unusual payment before the events are investigated in isolation.

## Find the callback failures before an attacker does

Most callback failures are procedural. Staff did something called a callback, but the attacker still controlled the evidence.

Audit for these patterns:

1. **Inbound confirmation.** The requester calls again and staff treat the second inbound call as verification.
2. **Caller-ID trust.** The displayed number matches the directory, so the agent skips the outbound call.
3. **Request-supplied contact.** Staff use a number from the email, invoice, attachment, ticket, or chat.
4. **Same-session contact change.** A new number is added and immediately used to verify a payment or credential change.
5. **Shallow read-back.** The verifier asks only whether the request is genuine and never confirms the details that determine the risk.
6. **Personal trivia.** A private question, safe word, manager name, or personal fact becomes the sole proof.
7. **Dependent dual approval.** Two employees approve the request, but both rely on the same email thread or verbal summary.
8. **Amount-only triggers.** Controls apply above one threshold, while new beneficiaries and bank details below it proceed unchecked.
9. **Executive bypass.** Staff waive the process because the requester appears senior, angry, confidential, or pressed for time.
10. **Invisible exceptions.** A workaround occurs in chat or by phone and never reaches the case record.

Sample completed cases alongside failures. Confirm that the verifier used the correct source record, reached an authorized person, recorded a meaningful read-back, and obtained independent approval. Review changes to trusted contact records as closely as the actions those contacts authorize.

Use tabletop exercises to test the awkward cases. The executive is traveling. The supplier contact left the company. The employee lost every device. The payment cutoff is in 20 minutes. The vendor says a bank change is confidential. A good policy gives staff a safe next step for each case. If the only workable answer is to bypass the policy, the recovery design is incomplete.

Measure the process without creating a shame list. Useful measures include:

- Percentage of protected requests with a complete verification record
- Percentage using an approved source of contact data
- Failed or abandoned verification by request type
- Exception volume, owner, reason, duration, and overdue review
- Trusted-contact changes followed by protected actions
- Time from failed verification to escalation
- Repeated missing fields or system steps that make compliance hard

An employee who places a request on hold has used the control correctly. Do not count that as lost productivity without also counting the loss the hold may have prevented.

## Roll out the policy without creating a bypass

Start with the people who own the actions. Security can write a policy, but finance controls payments, identity teams control recovery, procurement controls supplier records, HR controls employee data, and data owners control releases. Assign each owner in the protected-action register.

Then make the process executable:

1. Inventory every protected action and the systems where staff complete it.
2. Name the trusted system of record, verifier, approver, executor, escalation owner, and exception authority for each action.
3. Lock down trusted-contact changes and retain their history.
4. Add required verification fields, approval states, holds, and notifications to the ticketing, ERP, HR, identity, and case-management tools.
5. Ask executives to endorse the no-waiver rule in plain language.
6. Pilot the procedure with finance and the help desk, where money and credential authority concentrate.
7. Run tabletop tests and simulated calls as part of [training employees against AI voice scams](/blog/how-to-train-employees-against-ai-voice-scams-%28vishing%29-the-complete-guide), then repair steps that staff cannot follow under time pressure.

Set a review interval that fits your audit, regulatory, and business needs. Recheck the policy after an incident, failed test, system migration, merger, new payment rail, identity-platform change, or new class of protected action. Recertify trusted contacts often enough that staff do not face a directory full of dead numbers during a real request.

## Test callback behavior under pressure with Brightside

A policy can look clean on paper and still fail when a caller sounds calm, informed, and senior. Brightside's [Vishing Simulator](/vishing) lets teams rehearse that moment with live Voice exercises or Voice + BEC scenarios that pair a call with a trackable phishing email.

Admins can define the attack goal, caller persona, target context, social-engineering tactics, tone, and voice. They can take the call themselves in a test launch before launch. An authorized one-to-two-minute recording can create a self-service audio voice clone for an executive-impersonation exercise.

Build scenarios around the policy behavior you need to observe. Did the employee end the inbound interaction? Did they refuse the supplied number? Did they use the approved callback path, involve the second approver, and report the attempt? The dashboard tracks measures such as answer rate, failed rate, median call duration, total simulations, and failure trends.

Brightside provides rehearsal and measurement. Caller authentication, ERP and identity enforcement, call blocking, real-time deepfake detection, and incident response remain the responsibility of the systems and procedures described above.

## Callback verification policy FAQs

### What is a callback verification policy?

A callback verification policy tells staff when they must stop an inbound request and contact the claimed person through a trusted route established before the request. It defines protected actions, approved systems of record, prohibited contact sources, identity and authority checks, dual control, evidence, escalation, and exceptions.

The policy applies across channels. A request that begins in email and moves to a phone call still needs independent verification if it asks for a covered payment, credential, access, contact, or data action.

### What counts as a known number for a verification callback?

A known number comes from an approved system of record that existed before the current request. Examples include a controlled employee directory, vendor master, signed contract, banking mandate, or verified customer record.

Caller ID, a phone's callback function, an email signature, a number in an invoice, or a contact supplied during the request does not qualify. If staff cannot find a trusted number, they should hold the action and use the documented process for establishing or recovering the contact.

### Is a callback enough for a password or MFA reset?

Usually not for a high-risk reset. A phone callback can add evidence, but NIST does not treat ordinary telephone out-of-band authentication as phishing-resistant. A password or MFA reset should use an existing authenticator or an approved identity-proofing process. Sensitive users, new authenticators, and privileged accounts should also require independent manager or security approval.

If the user has lost every authenticator, move to the formal recovery path. Do not downgrade to public-information questions because the caller is in a hurry.

### Which requests need dual control even when the caller sounds familiar?

The organization should define its own list based on authority and impact. Strong candidates include new beneficiaries, bank-detail changes, payment releases, payroll changes, privileged recovery, MFA replacement for sensitive users, remote-access approval, and bulk sensitive-data release.

The second person must review independent verification evidence. Familiarity with the voice, face, writing style, or business story does not satisfy dual control.

### What should an employee do when the trusted contact cannot be reached?

Hold the protected action and record the failed attempt. Notify the owner named in the escalation matrix. That owner may use a separately approved fallback, such as the relationship owner, an alternate trusted contact, higher-assurance identity proofing, or in-person verification.

Do not use the new number supplied by the requester, waive the check because of a deadline, or keep trying weaker questions until one works. If the documented fallback cannot establish enough confidence, the request remains on hold.