Penetration Testing SoW for Indonesian Banks: OJK, BI, POJK 21

For an Indonesian bank or payment operator, a penetration testing report ends up in three regulatory filings: the LKTPTI to OJK, due 21 January (PADK OJK 1/2026), the annual cyber-security maturity report to Bank Indonesia, due 31 January, with the pentest report as supporting evidence (PADG BI 24/2024), and the independent opinion required before a bank's first digital service is licensed (POJK 21/2023 Article 13). No OJK rule for commercial banks requires a pentest once a year. POJK 11/2022 leaves the frequency to the bank, and the only cyber test with a fixed annual cycle is scenario-based testing.

This piece is for the CTO or solution architect drafting the scope of work (SoW) for a web or mobile channel pentest, and for the internal audit unit (SKAI) and CISO who'll have to file what comes back. Every regulation below was downloaded fresh from ojk.go.id and bi.go.id and read in full on 21 September 2026; the OWASP versions were checked the same day. Indonesian regulation numbers are kept as issued. "Article" translates Pasal.

The pentest calendar the regulations actually set

"OJK mandates an annual penetration test" appears on a lot of vendor pages, never with an article number. The primary text says something else. POJK No. 11/POJK.03/2022 (promulgated 7 July 2022), Article 23, requires two kinds of testing: vulnerability-analysis-based and scenario-based. The elucidation to Article 24(1) names the penetration test as an example of the first kind, then says it runs "periodically according to the Bank's needs", at a frequency set by the system's criticality and cyber-risk exposure. The phrase "once a year" only turns up in Article 25(1), and it governs scenario-based testing.

Institution	Pentest frequency	Where the result goes, and when	Legal basis
Commercial bank	Periodic, set by the bank according to system criticality. No fixed number.	Into the LKTPTI, by 21 January of the following year	POJK 11/2022 Art. 23–24; PADK OJK 1/2026 Appendix II item 3.c
Commercial bank	Scenario-based testing, at least once a year	Report within 10 working days of the test ending	POJK 11/2022 Art. 25(1) and (3)
Payment system operator under BI	Vulnerability scanning (penetration testing included) consistent and continuous; evaluated at least once a year	Supporting evidence for the annual cyber-security maturity report, by 31 January	PADG BI 24/2024 Art. 26(c), 29(5), 53(2) and (4)
Bank launching its first digital service	Before the licence application	An opinion from a party independent of the bank on the adequacy of IT security	POJK 21/2023 Art. 13(3)–(4)
Insurers, multifinance, pension funds, pawnbrokers, guarantors	No pentest obligation named	None	POJK 4/POJK.05/2021; SEOJK 22/SEOJK.05/2021
P2P lending operators (LPBBTI)	Triggered by a device operating-system change, not by the calendar	Attached to the change report, within 15 working days	POJK 40/2024 Art. 186; Appendix Table 35 item 6

Four notes that change how the SoW gets written.

• The pentest schedule has to be defensible. POJK 11 gives no number, so a bank's pentest cadence is a decision it must justify to an OJK examiner on system criticality. Breaching Articles 23–25 draws a written warning, which can escalate to a ban on new products, suspension of specific business activities, or a lower governance-factor rating (Article 27).
• Two OJK deadlines contradict each other on paper. SEOJK 29/SEOJK.03/2022 Chapter VII item 4.b.1 still says 15 working days after the end of the reporting year. PADK OJK 1/2026, in force from 1 March 2026, sets 21 January and revokes SEOJK 21/SEOJK.03/2017, but it doesn't revoke SEOJK 29. We treat 21 January as the operative format rule; confirm it with your bank supervisor. The PADK's only worked example is the 2027 LKTPTI falling due on 21 January 2028. That the 2026 LKTPTI is due on Thursday, 21 January 2027 is our inference from the in-force date, not a sentence in the PADK.
• The BI deadline moves earlier, not later, over a weekend. PADG BI 24/2024 Article 53(5): if 31 January is not a BI operational working day, the report is due on the previous working day. 31 January 2027 is a Sunday, so the deadline is Friday, 29 January 2027, unless BI is closed that day.
• Non-bank doesn't mean untested. A full-text search of POJK 4/2021 and SEOJK 22/2021 for "penetra", "kerentanan" (vulnerability), "vulnerab" and "siber" (cyber) returns nothing. What exists is SEOJK 22 Chapter V item 10(h): test and apply security controls on a system before it goes live. A bank that also holds a payment service provider (PJP) licence answers to OJK and BI at once.

Format 3.2.14: the template the bank files with OJK

PADK OJK 1/2026 Appendix III, Format 3.2 item 14, "Results of Cyber Security Testing based on Vulnerability Analysis", fixes what the bank submits. A penetration testing report that doesn't follow this structure gets rebuilt by the bank's own team before January. The format asks for four parts:

1. A. Scope: the type of asset tested, including its environment (development or production), plus the purpose and method of testing (white box, black box or grey box).
2. B. Findings: a description of each finding and its criticality, plus a summary of its impact on the bank's business continuity.
3. C. Remediation status of each finding.
4. D. Other supporting information.

So OJK will read, in the LKTPTI itself, whether your pentest touched production and whether the tester had the source code.

Penetration testing SoW checklist: clause, legal basis, evidence produced

Each row is a clause you can paste into an SoW, paired with the provision behind it and the artefact the tester must hand over. Items 5–7 of control 4.2.c in SEOJK 29 Appendix I.b are what the bank's internal audit checks. Put them in the SoW and the audit evidence arrives with the report.

SoW clause	Basis	Deliverable
State the test environment per asset: production, or staging with a reason and evidence of configuration parity	PADK 1/2026 Format 3.2.14 A.1	Asset-and-environment table in the scope chapter
State the method (white, grey or black box) and the documents the bank provides: source code, system design, manuals	Format 3.2.14 A.2; the penetration test definition in SEOJK 29 Chapter VII item 2	List of documents received by the tester
The bank's own vulnerability identification output is the pentest's starting point	SEOJK 29 Appendix I.b control 4.2.c item 5	Cross-reference from findings to the bank's VA output
Dedicated test accounts, not admin accounts: at least two users per role, plus one separate admin account for vertical testing	Control 4.2.c item 6; OWASP WSTG-v42-ATHZ-02	Test-account register with role and active dates
Test accounts monitored during testing, then deleted or returned to normal function	Control 4.2.c item 7	Deletion or reversion log, signed by the system owner
Coverage by asset type: web, client-based, mobile, wireless, server, network devices	SEOJK 29 Appendix I.b control 4.1.b item 5	Matrix of assets tested and excluded, with reasons
Every finding carries a criticality rating and a business-impact summary	Format 3.2.14 B	Findings chapter with a business-impact column
Retest of each finding is in the contract, with status closed, accepted or open	Format 3.2.14 C	Dated retest report, by finding ID
The report is handled as confidential information: restricted distribution, encrypted storage, destruction of the tester's copies	SEOJK 29 Chapter VII item 7; control 4.1.b item 4	Signed handover and destruction record
Every finding mapped to a version-stamped ID (WSTG-v42-…, A01:2025, MAS profile)	OWASP WSTG numbering convention	Standards-reference column on every finding
Tester identity, certifications and a statement of independence	SEOJK 29 Chapter VII item 5; POJK 21/2023 Art. 13(4)	Team-profile appendix and signed statement

One correction to a common assumption. SEOJK 29's definition lists source code, system design and manuals "among others" (antara lain). So a black-box pentest isn't automatically non-compliant. What the definition does is assume the tester has access to internal resources, and Format 3.2.14 makes the bank declare its choice. If you pick black box, write down why.

Four scoping choices that produce "no critical findings"

A clean report can mean the system is secure. It can also mean whole classes of test were never run. The choices below produce the second.

Unauthenticated only, or a single role

WSTG v4.2 tests authorisation "for every role" the tester holds, and for horizontal testing it asks for two users with identical privileges per role (WSTG-ATHZ-02). A scope without credentials can't run this test at all. A scope with one account can't test whether one customer can reach another customer's data. So cross-account access, the core of A01:2025 Broken Access Control at the top of the Top 10, never gets exercised. A banking channel with maker, checker and approver needs an account at each of those layers. Our view is blunt: an SoW that doesn't attach a per-role test-account list isn't ready to sign.

Examples of that kind of surface: the multi-layer approval CMS WEBARQ built for BCA Group, and the investor onboarding with OCR, video call and links to KSEI and Dukcapil (the civil registry) built for CGS International. Both illustrate the shape of the flow; neither is a claim about a pentest of those projects.

Staging only

Format 3.2.14 A.1 asks the bank to name the environment of every asset. A pentest that only touched staging will say so in the LKTPTI. Staging can also differ from production in its WAF, TLS configuration, third-party integrations and data. If production is off-limits, the SoW has to demand evidence of configuration parity, not assume it.

An unversioned Top 10 mapping

"Tested against the OWASP Top 10" without a year is now ambiguous. OWASP Top 10:2025 folds SSRF into A01 Broken Access Control and adds A03 Software Supply Chain Failures and A10 Mishandling of Exceptional Conditions. Material still teaching the 2021 list produces mappings that don't match the current one. The example is close to hand: the GitHub repository kamarkamsib/penetration-testing, which Google's AI Overview in Indonesia cited for both "pentest" and "penetration testing" on 21 September 2026, still has an "OWASP Top 10 2021" chapter with SSRF as its own A10.

"MASVS Level 2" for a mobile app

A mobile banking RFP that asks for "MASVS L2" names a structure the standard no longer has. MASVS v2.0.0 (1 April 2023) removed levels from the controls and moved them into testing as MAS profiles: MAS-L1, MAS-L2 (the operating system can't be trusted and the attacker may hold the device), MAS-R (the device's user is the attacker) and MAS-P (privacy).

The versions a 2026 RFP should name

What RFPs often say	What they should say	Source, checked 21 Sept 2026
OWASP Top 10 (no year), or 2021	OWASP Top 10:2025, noting SSRF (CWE-918) now sits in A01	owasp.org/Top10/2025
"OWASP Testing Guide"	WSTG v4.2, with IDs in the form WSTG-v42-CATEGORY-NN; v5.0 is still in development	OWASP WSTG README
MASVS Level 1 / Level 2	MASVS v2 with MAS-L1, MAS-L2, MAS-R and/or MAS-P profiles	MASVS v2.0.0; MAS Profiles page
MSTG / MASTG v1	MASTG v2.0.0 (30 June 2026): 193 tests, 77 of them new; v1 tests are no longer maintained	MASTG v2.0.0 release

The WSTG README itself says IDs can change between versions and asks reports to use the version-stamped form, for example WSTG-v42-INFO-02. Without the version, this year's findings can't be matched against a v5-based test next year.

Who may test, and who may sign

Three regulators, three different requirements:

• SEOJK 29 Chapter VII item 5: testing may be done in-house or by a third party, but the bank stays responsible. A third party's competence is shown, among other ways, by certification and/or recognition from an authorised body in Indonesia or abroad.
• POJK 21/2023 Article 13(4) (promulgated 22 December 2023): for a digital service issued for the first time, the opinion comes from a party independent of and outside the bank, such as an IT security consultant. For added features that increase risk exposure, an independent internal party is enough. The elucidation excludes anyone who took part in designing or developing the system. Our reading: the team that built the channel can't be its independent tester. POJK 21 never uses the word "pentest"; what it asks for is an opinion on the adequacy of security.
• PADG BI 24/2024 Article 12(3): an external cyber-security auditor must be independent and registered with an SRO and/or another authority, which the elucidation says includes OJK and BSSN, the national cyber agency. But the PADG 24 FAQ, Q14, says BI doesn't publish a list of certified IT bodies. Checking that registration is your job.

A vendor's ISO 27001 certificate doesn't replace this report. Annex A controls 8.8 (technical vulnerabilities) and 8.29 (security testing in development and acceptance) only require that the process exists; the evidence that your channel was tested is still the penetration testing report. How to check a vendor's certificate is covered in our ISO 27001 certification vendor check.

What to settle before the SoW is signed

• CTO / solution architect: build the list of roles and test accounts from the authorisation design, not from demo accounts. Fix the environment per asset. Name the version of every standard. A channel built on cloud native architecture or shipped as a mobile app needs separate API and client scopes.
• SKAI (internal audit): make the test-account deletion log (control 4.2.c item 7) and the retest report (Format 3.2.14 C) contract deliverables, not documents chased afterwards.
• CISO: schedule the pentest and retest of live channels in Q4 so they close before 21 January (OJK) and 29 January 2027 (BI).

Scope sets the price. The cost comparison between a pentest and a vulnerability assessment is in vulnerability assessment vs penetration testing: what each costs. Where the pentest report sits in the annual evidence calendar is in types of cyber security and the documents that prove them.

This article was prepared by WEBARQ with AI assistance. Regulatory citations were checked against official copies downloaded from ojk.go.id and bi.go.id on 21 September 2026. Translations of Indonesian regulatory text are ours. This is not legal advice; confirm deadline interpretations with your supervisor.