Cyber resilience audit Indonesia: what OJK examiners check

A cyber resilience audit by OJK covers two mechanisms: the annual reporting cycle that banks submit to OJK, and on-site IT examinations the regulator can initiate at any time. Both draw from POJK No. 11/POJK.03/2022 and SEOJK No. 29/SEOJK.03/2022, the two instruments that together form the IT supervision framework for Indonesian commercial banks. This page sets out the examination scope, what evidence examiners typically request, the reporting deadlines that apply, and how Alpha Code helps banks prepare.

This page also serves as a starting point for banks and payment operators that want to understand which framework applies to their institution type.

Supervision framework by institution type

Three distinct regulatory frameworks govern cyber resilience in Indonesia's financial sector, each with its own regulator and instruments.

Commercial banks (Bank Umum) operate under POJK 11/2022 and SEOJK 29/2022. These build an annual assessment cycle, require regular security testing, and set incident reporting deadlines to OJK. The full guide on obligations and the compliance path for commercial banks is at cybersecurity compliance for commercial banks under OJK.

Rural and regional banks (BPR and BPRS) fall under POJK 34/2025, which takes effect on 18 December 2026. Its cyber resilience requirements are calibrated to the scale and business model of rural banks, and differ from the commercial bank framework in scope and detail. Full guidance is at BPR IT and cybersecurity compliance under POJK 34/2025.

Payment system operators are supervised by Bank Indonesia under PBI 2/2024. BI and OJK examinations, while related at some points, are separate and assess different things. Guidance for payment system operators is at payment operator cyber resilience compliance under PBI 2/2024.

The rest of this page focuses on OJK examinations of commercial banks under POJK 11/2022 and SEOJK 29/2022.

How OJK conducts examinations

OJK's supervision of cyber resilience and security is not a single procedure. It combines a scheduled annual reporting cycle, event-triggered reporting, and direct on-site examinations that OJK can conduct separately from any cycle.

The annual cycle starts with the self-assessment. Each year, taken at the 31 December position, a bank rates its inherent cyber security risk against four factors: technology, bank products, organisational characteristics, and its cyber incident history. The result is a rating from 1 (low) to 5 (high). The maturity assessment runs in parallel, scoring the quality of the bank's cyber security risk management and its cyber resilience process. Both combine into the cyber risk level, also rated 1 to 5.

The annual IT status report, which includes the self-assessment results, reaches OJK within 15 working days after the end of the reporting year, using the Lampiran V format in SEOJK 29/2022. OJK reviews the submission and, where it judges that the reported rating does not reflect the bank's actual condition, it can adjust the rating itself.

Outside the annual cycle, scenario-based security testing results go to OJK within 10 working days of the test completing, in the Lampiran VI format. Note that the SEOJK defines the test as complete when the result report has finished being compiled, not on the last day of testing activity. For incidents, the deadlines are tighter still: initial notification within 1x24 hours and a full incident report within 5 working days.

Examination scope

SEOJK 29/2022 runs to ten sections, which together form the examination framework OJK applies. In practice, examiners work through four main areas that span the full cycle.

What evidence examiners ask for

OJK examiners generally start with the self-assessment results: the inherent risk rating, the maturity level, and the combined cyber risk level, along with the reasoning behind each. Because OJK can adjust ratings it considers inconsistent with a bank's actual condition, a bank that cannot explain its assessment clearly risks having its rating changed.

The IT asset register needs to be current, classified by criticality and sensitivity, and have clear owners. A register that was last updated more than a year ago is itself a finding.

Incident records are examined from two directions: the technical chronology and the timestamps on the notifications and reports sent to OJK. Examiners compare the two to confirm that the reporting deadlines were met in practice, not just documented in the bank's procedures.

Security testing results are reviewed together with evidence of follow-up. The regulation does not specify a remediation deadline, so the bank's own internal SLA becomes the benchmark. Critical findings that have been open for an extended period, even in the absence of a mandatory deadline, tend to attract examiner attention.

Finally, the cyber unit's structure must show genuine independence from IT management functions, which covers IT planning, development, operations, and monitoring. A different name on the same reporting line will prompt further questions.

Independence in testing and governance

Two questions about independence get conflated here, and only one of them is an obligation.

The first is the independence of the cyber unit or function from the IT management function. The IT management function covers planning, development, operations, and monitoring. The cyber unit cannot sit within the same command structure as those activities.

The second is not an obligation, though it is often presented as one: the independence of whoever runs the security testing. Scenario-based and vulnerability-analysis testing may be run by the bank's own team or by a third party. Where a third party is engaged, the bank must confirm the provider has adequate competence, evidenced for example by certification from a competent body, and the bank remains responsible for the testing. Results go to the board of directors as a basis for improving governance, policies, and internal controls, not simply archived as technical documents.

SEOJK 29/2022 also provides one specific periodic example worth noting: the appendix gives a quarterly review of user access permissions as an illustrative cadence. That example applies to user access reviews specifically and does not extend to board reporting frequency, privileged account reviews, or the frequency of vulnerability assessments.

Internal IT audit, an obligation separate from the OJK examination

Everything above concerns supervision that OJK carries out. There is a separate, free-standing audit obligation that the bank owes over itself, and it sits not in Bab V but in Bab X of POJK 11/2022, on internal control and internal audit in IT implementation.

Pasal 54 ayat (4) requires the bank to conduct an internal audit of IT implementation according to need, priority, and the results of risk analysis, at least once a year. Pasal 54 ayat (2) requires an audit trail across all IT implementation activity, for supervision, law enforcement, dispute resolution, verification, testing, and other examination. Pasal 55 ayat (1) requires an internal IT audit charter.

Then Pasal 55 ayat (2), the most misunderstood provision in the whole regime: the bank must review its internal IT audit function at least once every three years using the services of an independent external party. The result goes to OJK under Pasal 55 ayat (3) huruf a.

This is the only place the regime mandates an independent external party, and the object of it needs reading precisely. What gets reviewed is the bank's internal IT audit function, not the bank's systems, so it is an assessment of audit quality rather than a security test. The cycle is three years, not annual. So the claim that OJK requires an external party is true of Pasal 55 ayat (2) and untrue of cyber security testing. If someone offers you penetration testing on the authority of Pasal 55, the authority is wrong.

Pasal 56 puts breaches of Pasal 54 ayat (2), ayat (4), and Pasal 55 on the same sanctions pattern as the other obligations, starting with a written warning.

How Alpha Code helps

Preparing for an OJK examination starts with understanding the current position. We begin with a gap assessment that maps the bank's governance, testing, incident reporting, and cyber unit structure against the specific obligations of SEOJK 29/2022. The result distinguishes what is already in place, what is partially covered, and what is missing entirely, so management can prioritise work against real gaps rather than assumed ones.

For testing evidence, our penetration testing service provides assessments by an independent team and delivers reports in a format that OJK examiners recognise, including risk categorisation and remediation recommendations. When an incident occurs, our incident response service supports both technical containment and the preparation of notifications and reports within OJK's deadlines.

Our SOC-as-a-Service provides continuous log monitoring and centralised log collection that supports SEOJK 29/2022's detection requirements. Our GRC consulting helps build the independent cyber unit structure, draft third-party risk management policies, and prepare the documentation examiners expect, including self-assessment templates and maturity scoring instruments.

Next steps

An OJK IT examination can happen at any time, separate from the annual reporting cycle. Banks that have not completed their most recent self-assessment, whose IT asset register has not been updated in the past year, or that have not tested their incident reporting procedures carry more risk when an examination occurs. If you want to understand how prepared your bank is, our team is ready to help outline a clear first step.