Most incident response plans are written around a reasonable-sounding but outdated assumption: that an institution has hours, not minutes, to confirm an incident before regulatory reporting obligations kick in. The Central Bank of Sri Lanka's Bank Supervision Department Circular No. 02 of 2025, issued on 7 May 2025, removes that assumption for licensed commercial and specialised banks. It requires an immediate report of IT and cybersecurity incidents within two hours of detection, followed by a detailed report within 14 days and a quarterly report within 15 days of each quarter's end. It also revoked CBSL's 2016 circular on reporting cybersecurity events.
The scope is broad. Reportable categories include intrusion, malware, ransomware, phishing, DDoS, social engineering, insider threats, APTs and supply chain attacks, along with online scams affecting customers, unplanned critical system outages or slowness, and regulatory non-compliance on IT and cybersecurity requirements.
Two hours is not enough time to run a traditional incident response process — triage, escalate, confirm, draft, review, submit — the way most existing playbooks describe it. It's enough time for exactly one thing: an automated, pre-built pipeline that does most of that work before a human is even in the loop.
Why this requires an architectural change, not a process update
A two-hour reporting window forces a specific realization: if your detection-to-confirmation process alone takes 90 minutes, your incident response team has 30 minutes left to draft and submit a regulatory report — which is not realistic for anything beyond a template with blanks to fill in. The only way to meet this consistently is to compress the detection and triage phase dramatically, which is an engineering problem, not a documentation problem.
What the two-hour engine actually requires
1. Log aggregation and parser configuration built for speed, not just completeness. Generic SIEM deployments optimize for comprehensive log capture, which is correct for forensics but too slow for two-hour triage. Custom parsers tuned to your specific critical assets — core banking systems, payment switches, customer-facing authentication — need to surface a confirmed indicator of compromise fast, not buried under noise from lower-priority systems.
2. Automated triage workflows that pre-classify severity. By the time a human analyst reviews an alert, the system should already have applied a first-pass severity classification based on asset criticality and indicator confidence — not left the analyst to manually determine, from scratch, whether this is a reportable event.
3. A pre-approved reporting template with variable fields, not a blank document. The two-hour clock does not allow time to draft regulatory language from scratch during an active incident. The template — incident description, affected systems, initial impact assessment, containment status — should exist before the incident happens, reviewed and pre-approved by Legal and Compliance, with only the specifics to fill in. CBSL's annexes set out the formats for the immediate, detailed and quarterly reports, so build your templates on them.
4. Parallel-track response, not sequential. Technical containment and regulatory reporting cannot happen one after the other within a two-hour window. They need a defined split: one workstream isolates and contains, a second — a designated compliance officer, not the incident commander — prepares the report using the pre-approved template, informed by real-time updates from the technical team rather than waiting for full resolution.
The institutions that will fail this requirement aren't the ones without a SIEM. They're the ones whose SIEM was configured for forensic completeness and never re-tuned for a two-hour operational deadline. Those are different design goals, and most deployments were built for the first one.
A practical readiness test
Run a tabletop exercise with a hard two-hour countdown clock, starting from the moment the simulated indicator first appears in your logs — not from the moment someone notices it. Most institutions that have never run this specific test discover the gap isn't in their response plan's logic. It's in how long detection alone takes before a human is even aware there's something to respond to.
What to prioritize first
- Identify your three or four most critical asset categories (core banking, payment switch, customer authentication, treasury systems) and confirm your SIEM has dedicated, tuned parsers for each — not shared generic rules.
- Draft and get Legal/Compliance sign-off on a reporting template now, before an incident forces you to write one under pressure.
- Run the two-hour tabletop test described above and measure — precisely — where the time actually goes.