Phishing Attempt and an Unauthorised IMPS Debit on the Same Morning

1. Contain the workstation - do not "fix" it. Disconnect the accountant's machine from the LAN and disable Wi-Fi, but do not power it off, format it or delete the email. Volatile evidence such as running processes and network sessions disappears on shutdown, and a reimage destroys the only record of what the attachment or link did. Keep it isolated and labelled.

2. Preserve the phishing email. Save the full message with headers, capture the sender address, the lookalike domain, the shortened URL and the attachment hash, and photograph the screen. This becomes the basis of the incident report and of any blocking rule pushed to other branches.

3. Escalate immediately, in parallel. Inform the branch head and the bank's information-security/IT function the same hour; the incident must travel through the bank's incident-response and reporting channel, and specified categories of cyber incident must also be reported to CERT-In within the short statutory window (six hours) and to the regulator as prescribed. The branch does not investigate alone.

4. Kill the credentials, not just the password. The three failed logins at 21:35–21:42 suggest someone was trying the manager's ID. Reset the password from a clean device, revoke active sessions, disable the ID if the pattern continues, and check for newly created users, altered payee/beneficiary records, changed limits and mail-forwarding rules.

5. Handle the customer immediately. Block the digital channel, obtain a written complaint and give her a dated acknowledgement - that timestamp drives the liability decision - register it in the grievance system, request a chargeback/reversal through the IMPS/UPI dispute mechanism, and place the account under watch to stop further debits.

6. Log it all. Times, names, actions. The branch's contemporaneous record is what regulators and auditors will rely on.

Assess the cause first; liability follows from the cause, not from the amount.

• If the debit resulted from a third-party breach or a bank-side failure - credentials compromised, a spoofed interface, the failed-login pattern at 21:35 that coincides with the 21:40 debit - the customer's liability is zero, provided she reports within three working days of the bank's communication. She reported the very next morning, so she is well inside that window.
• If the loss arose from her own negligence - she shared an OTP, PIN or password, or approved a collect request - liability is determined under the bank's board-approved policy, and the branch must be able to show what evidence supports that finding. Do not assume negligence because she is elderly; the login report points the other way.
• Reporting-window ladder: zero liability if reported within three working days; a limited liability (capped in the low tens of thousands) if reported in the fourth to seventh working day; beyond that, per the bank's policy. She is in the first bucket.
• Timeline for the bank: the shadow reversal/credit for such complaints is expected within about ten working days; do not leave the matter open indefinitely.

What to tell her today: that the complaint is registered with a time stamp, that her account and channel are secured, that investigation is under way, and that she need not visit again unless asked. Do not tell her she must have done something wrong, and do not promise a refund amount before the cause is established. Also caution her, in writing, against sharing OTPs even with someone claiming to be from the bank - the standard disclaimer protects both sides.

Refuse it. Reformatting is the digital equivalent of mopping the floor before the fire brigade arrives.

What is lost in a reformat:

• The entry vector. Whether the executable was run, what it dropped, and whether it reached the CBS server can only be established from the machine's process list, registry changes, prefetch, scheduled tasks and logs.
• The timeline. The three failed login attempts at 21:35–21:42 and the 21:40 IMPS debit are now a linked sequence. If the link between the phishing mail and the suspicious logins is not established from the logs, the bank cannot decide the customer's liability and cannot defend that decision to the regulator.
• Attribution. The message headers and the lookalike domain are evidence that a targeted campaign is running against the bank; other branches need to be warned within hours.
• Audit trail. Preserving and handing over logs is a stated expectation in the cyber-security framework; destroying them, even "to restore service", is itself a reportable failure.

What to preserve: the original email with headers and attachment, the shortened URL, the machine's disk image and event logs, CBS application and login logs for the relevant period, firewall/proxy logs showing outbound traffic, and the branch's own incident register. Maintain chain of custody - who took the copy, when, on what medium, stored where - because a certificate under the evidence law is expected if the matter is prosecuted.

The correct commercial answer: the machine stays isolated, the accountant works from a spare terminal on a separate login, and the branch tells customers nothing beyond the standard line while IT handles the investigation. Restoring one clerk's convenience is not worth destroying the bank's defence.