'Immediately' Means Immediately: Incident Reporting Under NRB's Cyber Resilience Guidelines

An incident response plan that gives the team 24 hours before contacting Nepal Rastra Bank is built on a number the Cyber Resilience Guidelines 2023 do not contain. A 24-hour window appears in secondary commentary about Nepal's rules. The CRG says something stricter. Para 127: "Any cyber incident that could be material or systemic should be immediately reported to relevant oversight and regulatory authorities." Build the plan around "immediately" and "could be," not around a clock and a confirmed root cause.

What the text actually requires

The CRG, issued in August 2023, applies to institutions licensed by NRB's Payment Systems Department: A to D class BFIs, payment system operators and payment service providers. Its incident response paragraphs are short and precise.

• Para 126: the incident response plan should identify internal and external stakeholders who must be notified, decision-making responsibilities and authorities, information that must be shared and reported, and when this should take place.
• Para 127: incidents that could be material or systemic should be reported immediately. The institution should follow the requirements of NRB's related directive or guideline when reporting to NRB.
• Para 128: where there are indications of criminal intent, such as fraud or extortion, procedures should escalate investigations to law enforcement.
• Para 131: forensic readiness, including logging policies covering audit log content, time synchronization and log retention.

Two older and parallel duties sit alongside these. NRB's IT Guidelines 2012, Section 10, item 1, require banks to "identify and document all electronic attacks and suspected electronic attacks in their system and report to Nepal Rastra Bank monthly." And CRG paras 95 to 98 set a recovery objective: safe resumption of critical operations within two hours of a disruption, in line with key consideration 17.6 of the PFMI, with contingency plans for when that cannot be achieved.

So there are three tracks: immediate reporting of potentially material incidents, monthly reporting of all attacks and suspected attacks, and a two-hour recovery objective. A plan that handles only one of them is incomplete.

The trigger in para 127 is "could be material," not "has been confirmed as material."

The failure mode: waiting for certainty

One predictable way to miss "immediately" is waiting for certainty. The team detects something serious, then holds the report until forensics confirm scope, root cause and customer impact. That can take days. By then the decision about whether the incident "could be material" was obvious hours earlier.

Waiting for certainty feels responsible. It is the opposite. Para 127 exists so that potentially material or systemic incidents reach the regulator early. An early report that says "we are still assessing" meets para 127. A complete report that arrives late doesn't.

An illustrative timeline

This is a composite scenario for illustration, not a reported incident. A development bank's SOC detects ransomware encrypting file servers at one branch cluster on a Friday evening. Encryption is spreading toward systems that support payment processing.

Technical track:

1. Contain. Isolate affected segments. CRG para 60(d) expects network design that allows connections to be "segmented or severed instantaneously."
2. Preserve evidence before rebuilding: memory, logs, affected images. Para 131's logging policies decide whether this is possible.
3. Start recovery against the two-hour objective for critical operations, and switch to contingency plans (paras 97 and 98) if it cannot be met.

Reporting track, running in parallel and not after:

1. Assess materiality on what is known. Payment-supporting systems at risk is enough to meet "could be material."
2. Report to NRB immediately using the channel and format NRB's related directive specifies. State what is known, what is not, and when the next update will come.
3. Escalate to law enforcement if there is extortion or fraud (para 128).
4. Log the incident for the monthly attack report under the IT Guidelines.
5. Send updates as facts change.

Who runs each track, and who can authorize the report without waiting for the CEO to land, must be decided before the incident. That is what para 126 asks for.

Rebuilding the plan

Checklist for CISOs and compliance heads:

• Replace any fixed hour-count in the plan with the para 127 trigger: report when an incident could be material or systemic.
• Write materiality criteria in advance: affected services, customer data, payment systems, duration thresholds. Make them simple enough to apply at night.
• Name the decision-maker for the NRB report and at least two alternates with authority to send it.
• Keep a pre-approved initial report template that allows "under assessment" for unknown fields.
• Confirm the current reporting channel and format under NRB's related directive. Keep the reference in the plan.
• Separate the immediate-report process from the monthly attack log. Both are required. They answer different questions.
• Check that logging policy meets para 131 before you need it: content, time sync, retention.
• Test the reporting track in tabletop exercises, not only containment.

Where this connects

The CRG expects a cross-disciplinary steering committee to own cyber resilience strategy. Incident reporting criteria belong on its agenda, covered in Surviving the NRB CRG 2023. For a stricter fixed-hour regime in the region, see Sri Lanka's two-hour reporting requirement. And if the incident starts at a branch using an unmanaged connection, the investigation has no logs to work with, which is the problem in The Branch Hotspot Problem.