IT audit services for BPR and BPRS: meeting POJK 34/2025 requirements

Most BPR leadership understands that POJK 34/2025 brings new IT obligations. What receives less attention is the audit requirement specifically: not a one-off assessment before the deadline, but a programme that runs periodically, that has to run at least once every year under Pasal 40. This is not something you can defer to the months before December 2026. An audit done in a rush rarely surfaces findings that the bank can genuinely act on, and it leaves the institution in a weaker position than if the work had been paced from the start.

This page covers Alpha Code's IT audit service for BPR and BPRS: what gets assessed, how the process works, and why auditor independence is a requirement that cannot be set aside. For the complete picture of POJK 34/2025 obligations, including IT governance, risk management, and cyber resilience, see the BPR IT and cybersecurity compliance page.

The IT audit obligations in POJK 34/2025

Pasal 40 requires BPR and BPRS to audit their IT implementation internally, at least once in any one-year period. The regulation does not impose a separate external review on a longer cycle. What it does say, in ayat (5), is that the internal audit may be performed by an external auditor, which is a permission rather than an obligation. Two further duties sit alongside it: the bank must hold internal audit guidelines for IT (ayat 3) and must keep an audit trail across all IT activity for supervision, enforcement, dispute resolution, verification and inspection (ayat 4).

The obligation applies from the regulation's effective date of 18 December 2026. Banks without a running IT audit programme need to design one before that date: defining scope, selecting who will conduct it, and building the documentation infrastructure that supports a repeating audit cycle.

Who performs the audit, and how often

A question that frequently comes up when we speak with BPR directors is whether an outside firm has to be brought in. It does not. The audit is an internal one that must happen at least once a year, and Pasal 40 ayat (5) leaves the choice of who performs it open, including an external auditor. Banks without an in-house IT audit function generally use that permission, because the alternative is building the capability from scratch.

The annual audit is typically conducted by the bank's own internal audit function, or by an external auditor engaged under Pasal 40 ayat (5). The purpose is the same either way: to confirm that IT controls are working as intended and that no deterioration has gone undetected. The regulation's elucidation adds that the choice of external auditor should account for the size and complexity of the bank's business, and that using one does not reduce the responsibility of the officer who heads the internal audit function.

Bringing in an external auditor changes what the bank has to have ready. Policy documentation, system logs, change records, and disaster recovery test results all need to be available and organised, because an outside auditor arrives to assess that material rather than to help compile it. The audit trail Pasal 40 ayat (4) requires is what makes this feasible, and it is easier to maintain continuously than to reconstruct in the weeks before an audit.

What an IT audit covers

The scope of an IT audit follows the areas POJK 34/2025 regulates. IT governance is the starting point: whether clear policies exist, whether roles and responsibilities are assigned at the right level, and whether technology decisions are made with a structure the board can oversee.

IT risk management is assessed for process: whether the bank identifies the risks that come from using technology, measures them consistently, and maintains mitigation steps proportionate to those risks. Information security covers the protection of customer and operational data, access controls, and detection of unauthorised attempts against systems.

Service continuity is assessed through the existence and quality of the disaster recovery plan: whether it is documented, whether it has been tested, and whether the results are recorded and acted on. Third-party IT providers are also in scope, because POJK 34/2025 requires the bank to retain accountability for services managed by vendors, not only for systems operated in-house.

How Alpha Code runs IT audit for BPR

Every engagement starts with a scoping session to map the system architecture, define the boundaries of the review, and identify the risk areas most relevant to that particular bank. Good scoping prevents the audit from becoming too broad to be useful or too narrow to catch what matters.

Evidence collection happens through document review, interviews with key staff, and targeted technical inspection of in-scope systems. We do not ask banks to produce documentation that should not already exist. A missing document is recorded as a finding, not papered over or excused.

Assessment and analysis produces a findings list ranked by risk level. The issues with the most impact on POJK 34/2025 compliance and on the bank's operational security appear first, with enough explanation that directors can understand why a finding matters without needing a technical background to read it.

The final report contains findings, context, and recommendations the bank can act on. We provide a clarification session after delivery so that management and the IT team can ask questions and build a remediation plan with a clear foundation.

Why auditor independence cannot be set aside

An external auditor carries different value, not because they are inherently more capable, but because they have no conflict of interest in the result. A person who built or manages the system being assessed naturally tends to see its strengths and overlook its weaknesses. This is not a question of honesty; it is how an insider's perspective works.

POJK 34/2025 permits an external auditor to perform the audit rather than requiring one, and its elucidation notes that engaging one does not reduce the responsibility of the officer heading internal audit. The independence argument therefore rests on practice rather than on a mandate: whoever sold, implemented, or routinely manages the systems being assessed is poorly placed to audit those same systems. Alpha Code works as an external party with no attachment to any core banking vendor or specific product used by the BPR. We assess the practices in place, not the interests of a commercial relationship.

Where Alpha Code has previously assisted a bank with certain aspects that fall within the audit scope, we discuss this upfront and establish a clear contractual separation before the engagement begins.

Next steps

Building a sustainable IT audit programme is easier done in stages than all at once before a deadline. Banks that start now have time to address findings from the first audit before the next one falls due, and will have organised documentation that makes each subsequent cycle less demanding.

If you want to discuss the right scope for your BPR or BPRS, or understand what needs to be in place before a first audit, our team is ready to assess your starting position and help you map a structured path forward.