Digitising KYC Forms After a Data Loss
Six staff at a branch share one desktop for scanning account-opening forms and KYC documents. Files are saved as scan001.pdf, scan002.pdf and so on in a shared folder protected by one password, 'branch123', known to all six and unchanged for two years. The desktop holds the only copy, there is no backup, and antivirus definitions have not updated since the branch's USB drive was infected last month.
Two incidents have just occurred. First, the desktop failed to boot and about 120 scanned forms covering three days could not be recovered. Second, a customer disputes a signature on a form; when the PDF is opened it shows an error, and the branch cannot show whether the page was altered after it was scanned. The regional IT team can spare one visit this month. The branch must also email scanned forms, wet signatures included, to the regional office, and file KYC records with the Central KYC Registry.
1. Identify the three most serious weaknesses and name the single highest-priority fix. Explain the priority, and why 'take a backup' is an incomplete answer.
Read the worked answer
Weakness 1 - single point of failure. One desktop, one copy. The risk has already crystallised: 120 forms lost. This is the only failure here that is irreversible.
Weakness 2 - no accountability. A shared password known to six people means no access log can distinguish one user from another. Anyone could have deleted, replaced or altered a file, and the branch cannot prove otherwise - which is exactly the problem in the signature dispute.
Weakness 3 - no malware control on the only copy. Stale antivirus plus a previous USB infection plus shared removable media is the classic route to ransomware encrypting that entire folder.
Highest priority: restore a second copy, off the machine, with a tested restore. Priority goes to the failure that is irreversible and has already happened; a corrupted or altered file can sometimes be reconstructed from the physical form, a deleted week cannot.
Why 'take a backup' is incomplete: a backup taken from an infected machine propagates the malware and may overwrite clean data with encrypted versions. And a backup restores availability only - it does nothing for integrity or accountability, which are the issues in the signature dispute. The correct sequence is: clean and patch, then unique named accounts with least privilege, then versioned backups.
2. The customer's form opens with an error and the signature is disputed. How should the branch have been able to prove the file was not altered, and what should it do now?
Read the worked answer
What was missing. At the moment of scanning, the branch should have computed a cryptographic hash (SHA-256) of each file and recorded it in a register kept separately from the files - ideally printed and signed, or in a system the scanning clerk cannot edit. Re-computing the hash later and comparing it proves alteration or its absence; the file and the record of the file are stored apart so that tampering with one is detectable through the other.
Alongside that: a storage location with logging of who opened or modified a file and when; read-only archival copies in PDF/A for long-term retrieval; a naming convention carrying date, customer identifier and version rather than a running number; and a digital signature using the branch's DSC where authenticity must be provable.
What 'corrupt file' does and does not mean. A read error is an availability defect, not evidence of tampering. Without a hash and an access log, the branch can neither prove nor disprove alteration - it can only assert, which is worthless in a dispute.
Now: produce the original physical form, which is the primary record; do not overwrite or 'repair' the corrupt file - preserve it as evidence; have IT extract and record its hash; and give the customer a written reply based on the physical record and the branch's register.
3. A clerk receives an email appearing to be from NPCI, from the domain npci-kyc[.]in, urging the branch to open an attached KYC-update utility (.zip containing an .exe) before the registry deadline. What is the correct judgement, including what to do if the attachment has already been opened?
Read the worked answer
Do not open it, and do not forward it. Four signals settle it: no bank process installs software on a branch PC on the strength of an email; the domain is not NPCI's official domain and uses a misleading construction; a KYC-update utility delivered as a zip-wrapped executable is a delivery mechanism, not a utility - genuine software arrives through the bank's patch or package channel; and the manufactured deadline pressures the reader to skip verification.
Verify out of band. Confirm through the bank's own circular, the intranet, or the official number already on record - never through contact details in the email.
Report and preserve. Forward to IT security with full headers, do not delete the original, and let IT block the sender and the URL at the gateway. Incidents of this kind are also reportable to CERT-In under the bank's incident-reporting process.
If it has been opened: disconnect the machine from the network immediately - unplug the cable, do not shut down, since volatile evidence may be needed; do not copy files to a USB drive, which spreads the payload; do not run antivirus blindly if the bank's incident procedure says preserve the host; then call the security team and inform the branch head, because the machine holds KYC data and any exfiltration is a reportable data breach.