Penetration Testing for POJK & SEOJK Compliance: Obligations for Banks, Fintechs, and Payment Providers

Pentesting Is No Longer Optional for Financial Institutions

For banks, fintech lenders, and payment service providers in Indonesia, penetration testing has shifted from good practice to part of a regulatory obligation. Both OJK (the Financial Services Authority) and Bank Indonesia expect periodic security testing of critical electronic systems — and ask for the results during examinations.

This article maps the regulations, what supervisors practically expect, the scope typically tested, the engagement process from scoping to retest, and how to choose a vendor whose report will actually be accepted by auditors and supervisors.

The Regulatory Map: Who Is Required to Do What

Security testing obligations are spread across several regulations, depending on the type of institution:

What Supervisors Practically Expect

In practice — from OJK/BI examinations and internal audits referencing SEOJK 29/2022 — expectations of a security testing program typically cover:

• 1

  Periodic testing, at least annually

  Penetration testing of critical electronic systems is performed periodically — the generally accepted practice is at least once a year, plus retesting after major changes (major releases, migrations, new integrations).

• 2

  Scenario- and risk-based

  SEOJK 29/2022 directs testing toward threat scenarios — not just vulnerability scans, but realistic attack paths against critical business functions.

• 3

  Competent and independent testers

  Testers must be independent of the developers of the system under test — a separate internal team or a third party — with provable competence (certifications, methodology, track record).

• 4

  Follow-through to closure

  Findings are classified by risk, assigned owners and deadlines, closed, then verified via retest. A dangling critical finding becomes the next examination's finding.

• 5

  Complete documentation

  Scope, methodology, reports, remediation evidence, and retest results are kept in order — this is what you hand over when supervisors or auditors ask for proof.

Typical Scope in the Financial Sector

Scope priority follows system criticality — the assets whose compromise affects customer funds, personal data, or service continuity:

The Compliance Pentest Process, Scoping to Audit Evidence

Choosing a Pentest Vendor for Compliance Needs

Not every pentest offer produces compliance evidence that gets accepted. Filter vendors with this list:

• Written, recognized methodology (OWASP, PTES) — stated in the proposal, not just in marketing.

• Verifiable certified testers (e.g. OSCP, OSWE, CRTO) who are independent of your system's developers.

• A sanitized sample report showing depth: reproduction steps, business impact, and remediation — not pasted scanner output.

• Retesting included in the package — without fix verification, your compliance cycle never closes.

• A clear NDA and data handling terms: where evidence is stored, for how long, and who can access it.

• Experience with financial environments: off-peak testing windows, coordination with operations teams, and care around production systems.

• An executive summary supervisors can read — a report only engineers can parse will burden your compliance function.

The Most Common Mistakes

• Equating a vulnerability scan with a pentest

  Automated scanning is the first line, not the obligation-filler. Scenario-based testing requires human testers chaining weaknesses into attack paths.

• Testing only right before an examination

  A rushed pentest a month before an exam leaves no remediation time — open critical findings become the supervisor's notes.

• Shrinking scope to fit the budget

  Excluding back-office systems or internal APIs makes the report clean on paper — and unrepresentative of actual risk.

• Findings never reaching the risk register

  A pentest report that ends life as a PDF in a folder changes nothing. Findings must enter the risk/finding register with owners and deadlines, then be verified closed.

• No retest

  Without retesting, there is no evidence fixes actually worked — and that evidence is the auditor's first question.

Conclusion

For Indonesian financial institutions, penetration testing is a recurring obligation — commercial banks are directed by POJK 11/2022 and SEOJK 29/2022, fintech lenders by POJK 10/2022, payment providers by BI regulations, and all of it is overlaid by the PDP Law's duty to secure personal data. The expectation pattern is identical: periodic testing by competent independent parties, follow-through to closure, and documentation you can hand over.

Treat pentesting as a planned annual cycle — honest scoping, scenario-based testing, prioritized remediation, retesting, and an evidence archive — not a panic project before an examination. The same budget then buys two things at once: real security and a calm examination.

To prepare a budget, the penetration testing price guide for Indonesia offers realistic ranges. Testing that meets OJK auditor expectations falls under our security assessment services.