OJK cyber security testing for the mobile banking app your customers use.
OJK requires commercial banks in Indonesia to run cyber security testing based on vulnerability analysis, such as penetration tests, on a regular basis, and says banks that run digital banking services must do it. Its cyber security circular also expects a penetration test programme that covers mobile apps, source code review before production, and one-time passwords for high-risk transactions. Ostorlab supports your testing obligations for the mobile app and the APIs behind it, on every release.
- Penetration testing by AI agents behind login, with a working exploit you can replay for each AI-agent finding
- Static and dynamic testing of the APK, AAB or IPA before it reaches the store, with no source code needed
- Tests login, one-time codes, step-up checks and the authorization checks in the APIs behind them
- Findings rated by severity, tracked as tickets and retested, ready for your yearly report to OJK
- Who it applies to
- Commercial banks in Indonesia, conventional and Sharia, including branches of foreign banks
- Legal basis
- POJK No. 11/POJK.03/2022, with PADK OJK No. 1 of 2026 in force since 1 March 2026
- Focus
- Cyber security testing, secure coding and authentication for digital services
- Reference
- SEOJK No. 29/SEOJK.03/2022 on cyber resilience and security for commercial banks
How OJK's IT and cyber rules for banks took shape
POJK 11/2022 sets the obligations. The circular and the 2026 PADK set the detail, and POJK 21/2023 adds rules for digital services.
- 7 July 2022
POJK 11/POJK.03/2022 promulgated
The regulation on IT implementation by commercial banks, which takes effect 3 months after promulgation and replaces POJK 38/POJK.03/2016.
- 27 December 2022
SEOJK 29/SEOJK.03/2022
The circular on cyber resilience and security for commercial banks, in force from the date it was issued.
- 2023
First cyber security tests
The circular says banks carry out cyber security testing for the first time in 2023.
- 22 December 2023
POJK 21/2023 on digital services
Rules for digital services by commercial banks, including two-factor authentication, in force on promulgation and replacing POJK 12/POJK.03/2018.
- 1 March 2026
PADK OJK No. 1 of 2026
Implementing guidance and report formats for POJK 11/2022 take effect, and SEOJK 21/SEOJK.03/2017 is revoked.
- Every year, by 21 January
Report on IT implementation
The yearly report to OJK on the current state of IT implementation, which includes the results of vulnerability-based cyber security tests.
OJK's cyber security rules, applied to your mobile app
POJK 11/2022 sets the obligations, SEOJK 29/2022 and PADK 1/2026 explain how to meet them, and POJK 21/2023 covers digital services. For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team.
- POJK 11/POJK.03/2022, Article 21; SEOJK 29/SEOJK.03/2022, IV.2
Know your assets, threats and vulnerabilities
What the text says
Banks must maintain cyber resilience through at least four processes: identifying assets, threats and vulnerabilities; protecting assets; detecting cyber incidents; and responding to and recovering from them. Identification includes an inventory and assessment of IT assets, including software, identification of vulnerabilities and monitoring of cyber developments, and regular cyber security testing.
Source:POJK 11/POJK.03/2022, Article 21; SEOJK 29/SEOJK.03/2022, IV.2
What it means for your mobile app
Your mobile app, the SDKs inside it and the APIs it calls are IT assets. You need to know what each release contains before you can say where its vulnerabilities are.
How Ostorlab helps
Ostorlab shows what each release of your app contains: third-party SDKs and native libraries with their versions and their location in the app bundle, what the app and its SDKs exchange with backends over the network, and what personal data the app collects and shares.
What stays with you
The asset inventory for the rest of your IT estate, its criticality classification and the risk register.
- POJK 11/POJK.03/2022, Articles 23 and 24 and elucidation; SEOJK 29/SEOJK.03/2022, VII.2
Run vulnerability-based testing, including penetration tests
What the text says
Banks must carry out cyber security testing based on vulnerability analysis and based on scenarios. Vulnerability-based testing, for example penetration tests, must be carried out periodically, at a frequency set by the bank from factors such as system criticality and changes that raise cyber risk exposure. It starts with vulnerability identification followed by a penetration test, and must be done by banks that run digital banking services or other online services.
Source:POJK 11/POJK.03/2022, Articles 23 and 24 and elucidation; SEOJK 29/SEOJK.03/2022, VII.2
What it means for your mobile app
A mobile banking app is an online service, so it is in scope. OJK does not set a fixed frequency: your own evaluation does, and a new release that changes what the app exposes is the kind of change the circular points to.
How Ostorlab helps
Fast scans usually finish in 1 to 5 minutes and full scans in 15 to 45 minutes, so they fit every release. An AI-agent pentest goes deeper, typically in a few hours, with a working exploit you can replay for each AI-agent finding, for critical changes and your periodic deep tests.
What stays with you
The testing frequency decision, and tests of networks, servers and other systems outside the app and its APIs.
- SEOJK 29/SEOJK.03/2022, Appendix I.b, controls 4.1.b and 4.2.c
Cover mobile apps in the penetration test programme
What the text says
The criteria for assessing cyber security risk management look at whether the bank has an adequate programme for regular vulnerability identification or penetration testing of web-based applications, client-based applications, mobile applications, wireless, servers and network devices. Internal audit reviews the use of vulnerability identification tools as a starting point for penetration tests, and the use of dedicated non-admin accounts for testing.
Source:SEOJK 29/SEOJK.03/2022, Appendix I.b, controls 4.1.b and 4.2.c
What it means for your mobile app
Mobile apps are named in the programme. Automated identification feeds the penetration test, and test accounts should be dedicated, controlled and removed afterwards.
How Ostorlab helps
Mobile SAST analyses the APK, AAB or IPA directly, with no source code needed, including taint analysis across embedded SDKs. Mobile DAST runs the app, keeps authenticated sessions and captures traffic, stack traces and screenshots. The AI-agent pentest then tests the business logic behind login, with your test accounts.
What stays with you
The programme document, the test accounts and their lifecycle, and the other asset types in the programme.
- SEOJK 29/SEOJK.03/2022, IV.3.i and Appendix I.c, control 2.i
Secure coding and source code review before production
What the text says
Banks ensure secure coding in the development of systems and applications. At a minimum, development follows secure coding practices as part of the system development life cycle, source code is reviewed to detect software vulnerabilities, especially before it moves to production, and the security of software developed in-house or by third parties is reviewed and tested regularly.
Source:SEOJK 29/SEOJK.03/2022, IV.3.i and Appendix I.c, control 2.i
What it means for your mobile app
Each release of the app should be checked for vulnerabilities before it reaches the store, whether your team or a vendor built it, and the SDKs you did not write are part of that software.
How Ostorlab helps
Run automated scans from your CI/CD pipeline on every build and monitor store releases without manual triggers. Mobile SAST works on the binary, so it also covers third-party code you don't have the source for, and SCA fingerprints statically compiled libraries that manifest-based scanners can miss.
What stays with you
Your secure coding standards, source code review of server-side code, and the release approval step.
- POJK 21/2023, Articles 5 and 9; SEOJK 29/SEOJK.03/2022, Appendix I.c, control 2.g
Two-factor authentication and OTP for high-risk transactions
What the text says
Banks must apply at least two authentication factors to verify financial transactions, per transaction or with limits based on the bank's risk analysis and customer consent. For remote onboarding by electronic means, one of the two factors must be something you are. The circular's criteria include OTP verification for high-risk transactions, MFA for access to sensitive data, and controls on password attempts and inactivity.
Source:POJK 21/2023, Articles 5 and 9; SEOJK 29/SEOJK.03/2022, Appendix I.c, control 2.g
What it means for your mobile app
The second factor has to be enforced by the server, not only shown in the app. Transfers, payee changes and other high-risk actions should not go through without it.
How Ostorlab helps
Ostorlab completes SMS, email or TOTP one-time codes with your test accounts and tests MFA enforcement and step-up flows, including how attackers try to manipulate them, together with the API calls behind account changes.
What stays with you
The choice of factors, the risk analysis behind transaction limits, customer consent and customer education.
- POJK 21/2023, Article 21; SEOJK 29/SEOJK.03/2022, Appendix I.c, control 2.e
Control access to customer data and transactions
What the text says
Banks must apply security control principles for customer data and transactions in every electronic system used for digital services, covering at least confidentiality, integrity, availability, authentication, non-repudiation, authorization control in systems, databases and applications, segregation of duties, audit trails and data retention. The circular also asks banks to protect data at rest, in use and in transit.
Source:POJK 21/2023, Article 21; SEOJK 29/SEOJK.03/2022, Appendix I.c, control 2.e
What it means for your mobile app
Authorization is checked in the APIs, not in the app screens. A customer who changes an account number in a request should not see someone else's data.
How Ostorlab helps
Ostorlab intercepts the app's traffic, even with TLS pinning, and tests the APIs for broken authorization (BOLA, BFLA, IDOR), misuse of tokens and sessions, and abuse such as enumeration, replay and automation, with request and response evidence for each finding.
What stays with you
Segregation of duties, audit trails, data retention and the controls in your core banking systems.
- POJK 21/2023, Article 13(3) and (4) and elucidation, Appendix I
An independent review before a new digital service
What the text says
A licence application for a digital service that meets the criteria of a new product must include the results of a review by an independent party on the product's characteristics, the adequacy of IT system security for the product, and compliance. For a digital service offered for the first time, the review is done by an independent party outside the bank, such as an IT security consultant. The application also covers any test results on security, the two-factor authentication used and the encryption.
Source:POJK 21/2023, Article 13(3) and (4) and elucidation, Appendix I
What it means for your mobile app
Launching a new transactional app, or a feature that raises risk exposure, needs security evidence before OJK grants the licence. Findings from your own testing are best fixed before the independent review starts.
How Ostorlab helps
Mobile SAST and DAST in the release pipeline, before the app reaches the store, and an AI-agent pentest of the new flows. Each finding comes with a risk rating, reproduction steps, request and response logs and screenshots, and retesting confirms whether the underlying issue is resolved.
What stays with you
The licence application, the choice of independent reviewer and the statement signed by your directors.
- POJK 11/POJK.03/2022, Articles 24 and 25; SEOJK 29/SEOJK.03/2022, VII.4; PADK 1/2026, Appendix II and Format 3.2.14
Report test results to OJK and the board
What the text says
Test results go to the board of directors as a basis for improvement. Results of vulnerability-based testing are reported to OJK as part of the yearly report on the current state of IT implementation, due by 21 January of the following year, with the scope (asset tested and environment), the method (white box, black box or grey box), findings and their criticality, business impact and follow-up status. Scenario-based test reports are due within 10 working days after the test.
What it means for your mobile app
Each finding on the app needs a criticality, an impact statement and a follow-up status by year end. A record kept release by release makes the January report a compilation, not a scramble.
How Ostorlab helps
Findings are rated critical, high, medium or low, tracked as tickets in the platform or in Jira and ServiceNow, and retested once the fix ships. Scan results, findings with reproduction steps and retest results give you a dated record of how the app's controls were tested and fixed, release after release.
What stays with you
The report itself, the business impact assessment, board reporting and the scenario-based tests.
- SEOJK 29/SEOJK.03/2022, VII.5 and VII.7; POJK 11/POJK.03/2022, Articles 29 and 30
Stay responsible when you use third parties
What the text says
Banks may test on their own or use a third party. With a third party, the bank must make sure it has adequate competence for the testing, shown for example by certification or recognition from an authorised body in Indonesia or abroad, and stays responsible for the testing. Test results must be documented and protected to keep them confidential. Contracts with IT service providers cover data confidentiality, independent audit results and access for OJK.
Source:SEOJK 29/SEOJK.03/2022, VII.5 and VII.7; POJK 11/POJK.03/2022, Articles 29 and 30
What it means for your mobile app
A SaaS testing platform that receives your app binaries and test credentials is an IT service provider your vendor process will review, and its results are confidential data.
How Ostorlab helps
Ostorlab is SOC 2 Type II audited. On the Enterprise plan you can choose Asia-Pacific data residency or run scans on-premises, and with BYOK the AI runs on your own provider account with a spend cap per scan. SSO/SAML, role-based access control and audit logs are available as an add-on and included on Enterprise.
What stays with you
Deciding whether a provider meets the competence test, your due diligence, and the contract clauses.
Summary of POJK 11/POJK.03/2022, SEOJK 29/SEOJK.03/2022, PADK OJK No. 1 of 2026 and POJK 21/2023, checked on 27 September 2026. The texts are in Indonesian, and the English wording on this page is ours. This page is not legal advice.
OJK rules, requirement by requirement
Where Ostorlab supports your mobile apps and their APIs, and the evidence you can keep for OJK and your auditors.
| Control | How Ostorlab helps | Evidence you keep |
|---|---|---|
| Inventory of IT assets and identification of vulnerabilitiesSEOJK 29/2022, IV.2 | Lists the SDKs and native libraries in each release with their versions, and shows which backends the app and its SDKs talk to. Details | Component identity, version and location in the app bundle, per release |
| Vulnerability-based testing, such as penetration testsPOJK 11/2022, Art. 23 and 24 | AI-agent pentest of the app and its APIs, behind login, on the build you ship. Details | A working exploit you can replay for each AI-agent finding, and a coverage heatmap |
| Penetration test programme that covers mobile appsSEOJK 29/2022, App. I.b, 4.1.b | Mobile SAST on the binary and Mobile DAST on the running app, before release. Details | Findings with decompiled source context, traffic, stack traces and screenshots |
| Source code review before production, and regular testing of third-party softwareSEOJK 29/2022, App. I.c, 2.i | Taint analysis across embedded SDKs, and dependency analysis of the compiled app. Details | Findings attributed to the SDK or library they come from |
| Two-factor authentication, and OTP for high-risk transactionsPOJK 21/2023, Art. 9; SEOJK 29/2022, App. I.c, 2.g | Logs in with one-time codes and tests MFA enforcement and step-up flows, and the API calls behind them. Details | Findings on login and step-up flows, with reproduction steps |
| Authorization control in systems, databases and applicationsPOJK 21/2023, Art. 21 | Intercepts traffic even with TLS pinning and tests authorization, token misuse and abuse such as enumeration and replay. Details | Request and response evidence for each API finding |
| Protection of data at rest and in transitSEOJK 29/2022, App. I.c, 2.e | Looks for tokens and personal data in storage, caches, logs and screenshots, and checks transport protections. Details | File system evidence showing what was written, where and when |
| Security evidence before a new digital servicePOJK 21/2023, Art. 13 | Mobile SAST and DAST in the release pipeline, before the app reaches the store. Details | Scan results for each build |
| Yearly report of vulnerability-based test resultsPADK 1/2026, Format 3.2.14 | Keeps scan results, tickets and retests for each release. | Dated scan history, tickets and retest results |
| Third-party testers and IT service providersSEOJK 29/2022, VII.5; POJK 11/2022, Art. 30 | SOC 2 Type II audit, Asia-Pacific data residency, on-premises scanning and BYOK. Details | SOC 2 Type II report, on request from the Trust Center |
Ostorlab covers the mobile apps and the APIs behind them. Scenario-based tests such as table-top and cyber range exercises, disaster recovery testing, the cyber maturity self-assessment, incident reporting and the rest of your IT estate stay with other tools and teams.
Put your mobile app into your OJK testing programme
A practical sequence for security teams. Adapt it to your own risk assessment and your copy of the OJK texts.
List the app as an asset
Record the app, the APIs it calls and the SDKs it embeds in your IT asset inventory, with their criticality.
Take a baseline
Scan each customer-facing app once to see where you stand. A free scan from the store takes minutes.
Set the testing frequency
Decide how often vulnerability-based tests run, based on criticality and change. Automated scans on every release, and a deeper AI-agent pentest for critical changes.
Test before production
Add static and dynamic testing to the release pipeline, so each build is checked before it reaches the store, including vendor-built code.
Cover logged-in flows
Add test accounts and one-time code delivery, so transfers, payee changes and other high-risk actions are tested, not only the login screen.
Track findings to closure
Send findings to Jira or ServiceNow with a severity, agree fix deadlines and retest every fix.
Prepare the January report
Keep scope, method, findings, criticality and follow-up status per test, so the yearly report to OJK is ready by 21 January.
Review the vendor
Take your testing providers through your IT service provider process: competence, confidentiality of results, data residency and audit reports.
A suggested sequence, not an OJK template. This is not legal advice.
The capabilities behind this page
Each one has its own page with the details.
- Mobile Agentic Deep ScanAI agents pentest the store build on every release, with a working exploit you can replay for each AI-agent finding.Learn more
- Mobile SASTBinary-based static analysis of APK, AAB and IPA files, with taint analysis across the app and its embedded SDKs.Learn more
- Authenticated testingTest login, one-time codes and step-up flows with your test accounts.Learn more
- API and backend testingIntercept app traffic even with TLS pinning, then test the APIs and backends behind accounts and payments.Learn more
- Mobile Shielding ScanTest root and jailbreak detection, anti-tampering and pinning at runtime, and see which protections held and which were bypassed.Learn more
- SCA and SBOMFind vulnerable dependencies, including statically compiled native libraries, and track their closure release after release.Learn more
- On-premises scanningScan staging apps, APIs and repositories behind your firewall or VPN, on infrastructure you control.Learn more
- Bring your own AI keyRun AI-agent scans on your own AI provider key with a spend cap per scan, so usage follows your internal policies.Learn more
Trusted by banks and fintechs, including
Sources
The official texts this page is based on, checked on 27 September 2026.
- POJK No. 11/POJK.03/2022 tentang Penyelenggaraan Teknologi Informasi oleh Bank Umum (Implementation of Information Technology by Commercial Banks)OJK regulation, set on 6 July 2022 and promulgated on 7 July 2022. IT governance, risk management, cyber resilience and cyber security testing. Indonesian text
- Implementation of Information Technology by Commercial Banks (summary of POJK 11/POJK.03/2022)OJK's English summary of POJK 11/POJK.03/2022. OJK states it is not an official translation
- SEOJK No. 29/SEOJK.03/2022 tentang Ketahanan dan Keamanan Siber bagi Bank Umum (Cyber Resilience and Security for Commercial Banks)OJK circular, set and in force on 27 December 2022. Cyber resilience processes, cyber security testing, incident reporting and assessment criteria. Indonesian text
- PADK OJK No. 1 Tahun 2026 tentang Penyelenggaraan Teknologi Informasi oleh Bank Umum (Implementation of Information Technology by Commercial Banks)Regulation of a Member of the OJK Board of Commissioners, set on 23 January 2026 and in force since 1 March 2026. Guidelines and report formats for POJK 11/2022; revokes SEOJK 21/SEOJK.03/2017. Indonesian text
- POJK No. 21 Tahun 2023 tentang Layanan Digital oleh Bank Umum (Digital Services by Commercial Banks)OJK regulation, set on 19 December 2023 and in force on promulgation on 22 December 2023. Two-factor authentication, data and transaction security, licensing of new digital services. Indonesian text
Frequently asked questions
Straight answers on coverage, setup, and how results reach your team.
Can't find your answer? Book a demo or contact us.
Test your mobile banking app the way OJK describes it
Start with a free scan of your app from the store, or book a demo to run logged-in tests and an AI-agent pentest with our team.