The Audit That Goes Wrong: A Cautionary Walk Backwards

The cleanest way to teach a security guideline is to walk backward through an incident. The events below are a composite from real engagements; identifying details are removed. Read it in reverse — the regulator’s letter on top, the privileged-access decision at the bottom — and you have the BB ICT Guideline in operational form. Every line in this story maps to a control domain in the Guideline; every gap maps to a finding the institution was not ready for. The sequence in which they happen is the sequence in which they tend to happen everywhere.

The cascade, in reverse

What each control should have caught

The privileged account should have been just-in-time, not permanent. The asset inventory should have caught the new account in its nightly diff. The change-management process should not have a quarter-end suppression mode for SIEM alerts, ever. The third-party risk register should have re-audited the vendor before any new privileged scope was granted. None of these are exotic; all are in the BB ICT Guideline; none was operating. The institution had paper compliance — a policy document, signed by senior management, citing each of these controls — and operational non-compliance, where the actual systems did not enforce what the policy said. The regulator’s letter was specifically about the gap between the two.

What the regulator’s letter actually focused on

The letter did not lead with the breach. It led with process. The regulator wanted to understand whether the institution had been operating its controls or had merely documented them. The forensic findings were a consequence; the institutional posture was the cause. Three questions dominated the response correspondence: how the privileged account was allowed to exist beyond its authorised window, why the SIEM had a suppression mode in the first place, and what the institution intended to do about the third-party risk register. None of those questions were about the breach itself. The breach was the symptom.

The seven controls that would have stopped it

Phishing-resistant MFA on privileged paths. Just-in-time access with session recording, ticket-bound and time-bound. Asset inventory in one CMDB, refreshed nightly. SWIFT and other regulated environments in their own trust zones. A SIEM that does not have a suppress during change- freeze mode. Quarterly DR exercises that test the on-call rotation, not just the runbook. Annual third-party assessments stored alongside the contract. Each is dull. Each, in this story, is the difference. The institutions that operate all seven do not get the regulator’s letter. The institutions that operate four out of seven get it once a year.

Why this story repeats

The single most common cause of breaches we see in Bangladeshi BFSI is not novel attacker tradecraft. It is the slow accumulation of expedient exceptions — emergency-change accounts, suppression rules, deferred rotations, untracked vendor logins. Each individual exception was defensible at the time it was created. The cumulative effect is a control surface that no longer enforces what the policy says. The work of the security function is, in large part, the work of saying no to the next exception that would otherwise be filed routinely.

The cultural posture that prevents this

The institutions that recover quickly from incidents share three cultural traits. First, the security team is empowered to halt production changes when a control is missing — and uses that authority sparingly enough that nobody questions it when it does. Second, the audit function and the security function meet weekly, share the same control-mapping spreadsheet, and treat each other as allies rather than adversaries. Third, the board’s risk committee has, on its agenda, explicit reviews of the top five controls — not the top five risks. The distinction is consequential.