Incident response and OJK reporting for rural banks: obligations and preparation

When an IT security incident hits a rural bank, two countdowns start at once. The first is technical: how long has the attacker or system failure been active, how far has it spread, and what needs to happen to stop it. The second is regulatory: when does OJK need to be notified, what information must be in the report, and who is responsible for putting it together.

For many rural banks, the technical clock is already stressful enough. The regulatory clock running alongside it often has no clear procedural foundation to stand on. The result, when an incident is underway, is a technical team working to contain the damage while nobody is handling the reporting obligation, or the reverse: someone trying to write a report without adequate technical data because the investigation is not finished yet.

POJK 34/2025 is clear that reporting IT incidents to OJK is an obligation, not an option. That obligation takes effect from 18 December 2026, but adequate procedural preparation cannot wait until the first incident arrives. This page explains what the regulation expects, why both processes need to run in parallel, and how rural banks can prepare before they face it. For a complete picture of POJK 34/2025 obligations, see our POJK 34/2025 compliance page.

Incident reporting obligations under POJK 34/2025

POJK 34/2025 requires BPR and BPRS to report IT incidents to OJK. The regulation frames reporting not as an optional step after the crisis has passed, but as an obligation that runs alongside the technical response. Banks are also required to have a reliable plan in place, because reporting an incident without organised documentation creates its own set of problems.

What happens when a rural bank faces an IT incident

IT incidents at rural banks do not always start with a dramatic cyberattack. Most incidents that end up requiring OJK notification begin with something that looks more ordinary: the core system suddenly becomes inaccessible, transactions start failing in bulk, or the IT team finds an account with activity nobody recognises. From that point, the first question is not "what happened" but "how serious is this, and what needs to happen right now."

Incidents that typically fall under mandatory OJK reporting include system outages affecting customer services, security breaches exposing data, cyberattacks disrupting operations, and infrastructure failures exceeding defined impact thresholds. The classification is not always obvious in the middle of an incident, and the decision about whether a specific situation is reportable needs to be made under time pressure based on evidence that may still be incomplete.

That is why having procedures ready before an incident produces substantially different outcomes than writing them while one is in progress.

Two processes that must run in parallel

What distinguishes an IT incident in a regulated environment from an ordinary system failure is the requirement to run two processes simultaneously: the technical response and the regulatory reporting. Both need the same underlying information, but they process it differently for different audiences.

The technical response moves fast: contain the spread, preserve evidence, identify the point of entry, restore services. The regulatory reporting moves in a structured way: document the timeline, assess the impact, explain the root cause, and present recovery steps to OJK in a format that can be verified. Both need to move within the same timeframe, and both need to be supported by different people with clearly defined roles established before the incident begins.

The dashed horizontal lines in the diagram are the key point: both tracks share the same information. A regulatory report cannot be written without data from the technical investigation, and a technical team unaware of the regulatory reporting obligation will finish their work without leaving the kind of record an OJK report requires. The two processes need to be planned together from the start.

Why preparation before an incident determines everything

A good incident response plan is not a document written to satisfy an audit requirement and then filed away. It is a set of pre-thought answers to questions that will come up during an incident: Who is called first? Who has the authority to decide which services to shut down? Who is responsible for communicating with OJK? What information needs to be collected, and in what format?

None of those questions are hard to answer under normal conditions. During an incident, with services affected and management calling for updates, every minute spent figuring out who is responsible for what is a minute not spent on containment or on preparing the OJK report.

A rural bank with a written plan, that has run through it at least once in a simulation, and that has external contacts it can reach during an incident, will respond faster and more systematically than one that has not. That difference shows up directly in how quickly services are restored and in the quality of the report submitted to OJK.

How Alpha Code supports rural banks

Our support works at two levels: preparation before an incident and active support while one is underway.

For preparation, we help rural banks write an incident response plan that covers OJK reporting procedures. The plan is tailored to the bank's size and risk profile rather than replicating a thick document no one will read. We also help the bank map the incident scenarios most likely to apply given the systems it runs, define which thresholds trigger mandatory reporting, and build a clear internal escalation path.

For active support, our incident response service can be engaged while an incident is in progress. Our team helps contain and investigate the incident technically while simultaneously supporting whoever is responsible for preparing OJK communications. We also provide forensic documentation that can form the basis of a regulatory report, not just internal technical notes.

For rural banks that do not yet have adequate internal security capacity, our managed SOC service provides continuous monitoring that can detect incidents earlier, before the scale of the impact grows into something far harder to handle.

What rural banks gain from being prepared

Our capabilities

Next steps

Incident response preparation works best without time pressure. Writing the plan, defining who is responsible for what, and making sure the OJK reporting path is clear are tasks that are easier to do in normal conditions than while an incident is underway.

If your BPR or BPRS does not yet have a documented incident response plan, or the plan you have does not yet cover OJK reporting procedures, our team can help assess your current readiness and build out what is needed before the POJK 34/2025 deadline arrives.