Bank Indonesia regulates Indonesia's payment system infrastructure — the rails on which every electronic transaction in the country runs. For payment service providers (PSPs), e-money issuers, fintech lending platforms, and any organization building digital payment services, BI's regulations are not advisory guidelines but licensing conditions. Non-compliance with payment system security requirements can result in license suspension or revocation — consequences that are existential for payment-dependent business models.
ISO 27001 is directly relevant to BI compliance: PBI 23/2021 (Payment Service Providers) requires information security management, risk management, incident response, and availability controls that map closely to ISO 27001. A well-implemented ISO 27001 ISMS provides the governance infrastructure and control evidence that BI supervisors look for. But BI has five specific requirements that ISO 27001 does not fully address — most notably Indonesian payment data localization, the 2-hour incident notification window, and minimum cryptographic standards. Understanding these gaps prevents the costly mistake of treating ISO 27001 certification as sufficient for BI licensing compliance.
This article covers the complete BI regulatory landscape for payment system operators, maps ISO 27001 controls to PBI 23's major sections, provides specific implementation guidance for the five payment security controls most scrutinized by BI supervisors, identifies the five BI-specific gaps requiring supplementary action, and explains how ISO 27001 certification supports the BI licensing process at each stage.
The Bank Indonesia Regulatory Landscape
BI's regulatory framework for payment system security spans multiple instruments — from primary regulations (PBI) to implementing circulars (SE BI) and technical guidelines (PADG). Understanding which instruments apply to the organization's specific license category is the first step:
| PBI/SE/PADG regulation | Subject | Scope | Key IS requirements | ISO 27001 alignment |
| PBI 23/6/PBI/2021 | Penyedia Jasa Pembayaran | All entities providing payment services in Indonesia: e-money issuers, payment gateways, switching providers, transfer funds operators, APMK issuers. Covers small and large PSPs. | Security requirements for payment systems: access controls, authentication, encryption of payment data in transit and at rest, fraud monitoring, incident management with BI notification, availability SLAs, data localization for payment data, vendor security management, penetration testing of payment systems. | ISO 27001 Annex A Domain 8 technical controls are the primary vehicle for PBI 23 payment system security requirements. Particularly: 8.5 (MFA for payment authorization), 8.24 (encryption), 8.15/8.16 (logging and monitoring for fraud detection), 5.26 (incident response with BI notification). |
| PBI 22/23/PBI/2020 | Sistem Pembayaran Indonesia 2025 | All payment system operators and participants. Sets the strategic framework for the Indonesian payment system architecture through 2025 (now extended to 2030). | Interoperability security requirements, open banking API security standards, payment data governance, cybersecurity resilience for payment infrastructure, real-time payment system security. | ISO 27001 8.26 (application security requirements including API security), 8.20–8.22 (network security and segmentation for payment networks), 5.23 (cloud services security for cloud-native payment platforms). |
| SE BI No. 21/7/DKSP/2019 | Penyelenggara Jasa Sistem Pembayaran — Keamanan Informasi | Payment System Service Providers (PJSP) — technical implementation guide for information security requirements. | Detailed technical guidance on: PCI DSS alignment, application security testing (OWASP), network security standards for payment networks, security monitoring for payment transactions, incident response timelines (2-hour notification for critical payment system incidents). | SE BI 21/7 provides the technical detail that ISO 27001 controls must be implemented to — it is the 'how' that complements ISO 27001's 'what'. ISO 27001 8.29 (security testing) and 8.28 (secure coding) directly align with SE BI 21/7 application security requirements. |
| PADG No. 21/18/PADG/2019 | Implementasi Standar Nasional Teknologi Chip | APMK issuers (credit card, debit card, prepaid card issuers) | EMV chip security standards, card production security, transaction processing security, fraud monitoring for card-present and card-not-present transactions. Heavily aligned with PCI DSS. | ISO 27001 provides the management system framework for PCI DSS and EMV compliance. Particularly: 5.12 (classification of card data), 8.24 (cryptography for card data encryption), 8.22 (network segmentation for cardholder data environment). |
| PBI 24/1/PBI/2022 | Pinjaman Online dan Fintech Lending | P2P lending platforms (fintech lending) licensed by BI/OJK | Cybersecurity for lending platforms, borrower data protection, collection practices security (preventing unauthorized data access for debt collection), escrow account security, incident reporting. | ISO 27001 5.34 (privacy and PII for borrower data), 8.12 (DLP for borrower data), 5.26 (incident response), 8.5 (MFA for platform access). UU PDP compliance is particularly critical for fintech lending platforms given the sensitivity of borrower financial data. |
| BI VS OJK JURISDICTION: WHO REGULATES WHAT | Both BI and OJK regulate security for financial organizations — but with different jurisdictions. Bank Indonesia: payment system infrastructure, e-money, payment service providers, digital banking technology infrastructure. OJK: banking institutions, multifinance, insurance, capital markets, fintech lending. Many organizations fall under both — a bank with an e-money service is regulated by OJK (banking license) and BI (e-money license) simultaneously. The ISMS must satisfy both supervisors' requirements, which requires deliberate integration rather than maintaining two separate evidence libraries. |
PBI 23/2021 Deep Mapping: ISO 27001 Control Alignment
PBI 23/6/PBI/2021 is the primary BI regulation governing payment service providers. Its six major sections covering risk management, IS security, system availability, incident management, data security, and third-party management each have direct ISO 27001 counterparts — and specific gaps where supplementary action is required:
| PBI 23 Section | PBI requirement | ISO 27001 alignment | Gap | Evidence |
| Pasal 15–22: Manajemen Risiko (Risk Management) | Payment service providers must implement a risk management framework covering: operational risk, legal risk, liquidity risk, and reputational risk. IT risk must be explicitly managed within this framework. Risk appetite for payment system operations must be defined and approved at board level. | ISO 27001 Clause 6.1 risk assessment and treatment, 9.3 management review (with risk reporting). The ISMS risk management approach directly satisfies PBI 23 IT risk management requirements when the risk register includes payment system risks. | PBI 23 requires quantitative risk metrics for payment operations (transaction failure rates, fraud rates, system availability) in addition to qualitative ISMS risk scoring. The ISO 27001 risk register should be supplemented with payment operational KPIs. | IT risk management framework aligned to PBI 23 risk categories. Risk appetite statement approved by board. Risk register with payment system risks. Quarterly risk reporting to board. |
| Pasal 23–31: Keamanan Sistem Informasi (IS Security) | PSPs must implement: access controls with MFA for payment authorization interfaces, encryption of payment data in transit (minimum TLS 1.2) and at rest (minimum AES-256), fraud monitoring with real-time alert capability, penetration testing of payment systems minimum annually, vulnerability scanning with remediation SLAs, security awareness for payment staff. | ISO 27001 8.5 (MFA), 8.24 (cryptography with algorithm specification), 8.15/8.16 (logging and real-time monitoring), 8.29 (security testing including penetration testing), 8.8 (vulnerability management), 6.3 (security awareness). Strong alignment — PBI 23 IS security requirements map almost entirely to ISO 27001 Domain 8 controls. | PBI 23 specifies minimum cryptographic standards (TLS 1.2, AES-256) that ISO 27001 8.24 does not prescribe — ISO 27001 requires 'appropriate' cryptography based on risk assessment. PBI 23's specificity means organizations must verify their cryptography implementations meet the minimum thresholds, not just pass general risk assessment. | MFA deployment report for all payment authorization accounts. Cryptography policy specifying TLS 1.2+ and AES-256 minimum. SSL/TLS certificate configuration evidence. Penetration test reports (annual). Vulnerability scan reports with remediation SLA compliance. |
| Pasal 32–38: Ketersediaan Sistem (System Availability) | Payment systems must meet minimum availability standards: 99.5% availability for e-money systems, 99.9% for critical payment infrastructure. RTO for critical systems: 2 hours maximum. Backup systems operational within 4 hours of primary system failure. Regular DR testing with documented results. | ISO 27001 5.30 (ICT readiness for BCM), 8.13 (backup), 8.14 (redundancy), 5.29 (IS during disruption). The ISO 27001 BCM-related controls directly address PBI 23 availability requirements. | PBI 23's 99.5%/99.9% availability SLAs are more prescriptive than ISO 27001's principle-based approach. Organizations must verify that their architecture achieves PBI-required availability levels — ISO 27001 risk-derived RTOs may not be calibrated to PBI minimums without explicit alignment. | System availability SLA commitments aligned to PBI 23 thresholds. Availability monitoring records demonstrating SLA achievement. DR test records (annual minimum). RTO demonstration in DR test. |
| Pasal 39–45: Pengelolaan Insiden (Incident Management) | PSPs must notify BI within 2 hours of a payment system incident affecting service availability or customer data. Incident classification must include payment-specific categories. Post-incident reports within 14 calendar days. Incident root cause analysis and corrective action documentation. | ISO 27001 5.24–5.28 (full incident management lifecycle). 5.26 (incident response with stakeholder notification). The ISO 27001 incident management controls directly address PBI 23 requirements — but the BI 2-hour notification timeline is more demanding than generic stakeholder notification. | The 2-hour BI notification window for payment system incidents is more demanding than ISO 27001's general stakeholder notification requirement. The incident response procedure must explicitly include: BI as a required notification recipient, the 2-hour notification countdown trigger criteria (service disruption OR customer data exposure), and the BI notification portal/channel. | Incident response procedure with BI 2-hour notification step. BI notification records for any payment system incidents. Post-incident reports within 14-day window. Incident root cause and corrective action documentation. |
| Pasal 46–55: Keamanan Data (Data Security) | Payment data — including transaction records, cardholder data, and personal data associated with payment accounts — must meet specific security standards. Data localization: payment transaction data for Indonesian transactions must be stored in Indonesia. Retention requirements: minimum 5 years for payment records. Third-party payment data processor requirements. | ISO 27001 5.12 (classification — payment data as restricted), 8.10 (deletion per retention schedule after minimum period), 5.14 (information transfer — cross-border data transfer restrictions apply), 5.20 (processor agreements — payment data processors require specific security terms). | PBI 23's Indonesian data localization requirement — transaction data for Indonesian payments must be stored in Indonesian territory — is a prescriptive geographic requirement that ISO 27001 does not mandate. Organizations using international cloud providers for payment data storage must verify that Indonesian payment transaction data is stored in the Jakarta region (not Singapore or other regions). | Data localization confirmation (cloud provider region documentation for payment data storage). Payment data classification records. Retention schedule aligned to 5-year minimum. Processor agreements with PBI-aligned data security terms. |
| Pasal 56–65: Pihak Ketiga (Third-Party Management) | PSPs engaging third parties for payment system operations must: conduct security due diligence, establish written agreements with security obligations, monitor third-party security performance, obtain BI approval for critical third-party arrangements, maintain an exit strategy for critical payment system providers. | ISO 27001 5.19–5.23 (supplier security framework). ISO 27001 supplier security controls directly address PBI 23 third-party requirements. 5.22 monitoring requirements align with ongoing third-party performance monitoring. | BI approval requirement for 'critical' third-party payment system arrangements — before engagement — is a proactive regulatory notification obligation similar to OJK's outsourcing notification requirement. Organizations must identify which third-party arrangements meet the 'critical' threshold and have a process for seeking BI approval. | Third-party due diligence records for payment system providers. Third-party agreements with PBI-aligned security terms. Third-party monitoring records. BI approval records for critical arrangements. |
| The strongest alignment between PBI 23 and ISO 27001 is in information security controls (PBI 23 Pasal 23–31 ↔ ISO 27001 Domain 8). An organization with mature Domain 8 controls — MFA, encryption, fraud monitoring, penetration testing, and vulnerability management — will satisfy the bulk of PBI 23's IS security requirements through ISMS evidence. The data localization requirement (Pasal 47) is the most important gap: it is a hard geographic requirement with no ISO 27001 equivalent, and it is the area where cloud-native PSPs most commonly have compliance exposure without realizing it. |
Five Payment Security Controls: Implementation Deep Dive
Five payment security controls are most frequently examined by BI supervisors and most directly connected to the risk of license action for non-compliance. Each requires specific technical implementation that goes beyond generic ISO 27001 control deployment:
| Payment security control | PBI 23 requirement | ISO 27001 control | Implementation guidance | Evidence required |
| Multi-factor authentication for payment authorization | PBI 23 Pasal 25: MFA required for all payment authorization interfaces accessible to customers and operators. Minimum two factors. For high-value transactions: out-of-band OTP or hardware token. | A.8.5 Secure authentication — requires secure authentication based on risk. PBI 23 makes MFA mandatory for payment authorization regardless of risk score. | Deploy MFA for: (a) all customer payment authorization (mobile app, web portal), (b) all operator access to payment processing systems, (c) all admin access to payment infrastructure. For high-value transactions (threshold defined by the PSP): require out-of-band second factor (SMS OTP, push notification to separate device, or hardware token). Evidence: IAM MFA enrollment report showing 100% coverage for payment authorization accounts. | IAM/customer authentication report showing MFA enrollment %. Transaction authentication configuration showing OOB second factor for high-value. Penetration test report including MFA bypass testing. |
| Payment data encryption | PBI 23 Pasal 26: Payment data must be encrypted in transit (minimum TLS 1.2, recommended TLS 1.3) and at rest (minimum AES-256 or equivalent strength). Key management must prevent key compromise from exposing historical transactions. | A.8.24 Use of cryptography — requires appropriate cryptographic controls based on risk assessment. ISO 27001 does not specify algorithm minimums. | TLS configuration: enforce TLS 1.2 minimum on all payment API endpoints; disable TLS 1.0/1.1 and SSL. Audit annually and on any infrastructure change. At-rest encryption: AES-256 for all payment databases and backup storage. Key management: key rotation schedule, HSM for production payment keys, key ceremony documentation. | TLS configuration report (ssl-checker or equivalent). Encryption at rest configuration (cloud provider KMS settings). Key management procedure. HSM configuration documentation. |
| Real-time fraud monitoring | PBI 23 Pasal 30: PSPs must implement real-time monitoring of payment transactions for fraud indicators. Monitoring must generate alerts for anomalous patterns. Response SLA for fraud alerts defined and operational. | A.8.16 Monitoring activities — requires monitoring and alert generation for anomalous behavior. A.8.15 Logging — requires logging of payment transactions. | Deploy transaction monitoring rules covering: velocity checks (too many transactions in short window), geographic anomalies (transaction location inconsistent with device), amount anomalies (transaction significantly above account normal), device fingerprint mismatch, after-hours high-value transactions. Alert response SLA: P1 fraud alerts responded within 15 minutes. Alert response is a monitored process with SLA compliance evidence. | Fraud monitoring rule configuration. Alert response SLA definition and compliance records. Sample alert investigation records. Fraud detection rate metrics (quarterly report to management). |
| Payment system availability monitoring | PBI 23 Pasal 34: Real-time system availability monitoring with automatic alerting when availability falls below SLA. Availability reporting to BI on defined schedule. | A.8.16 Monitoring activities, A.8.6 Capacity management. ISO 27001 requires monitoring but does not specify minimum availability SLAs. | Deploy uptime monitoring for all payment system components with minimum 1-minute check interval. Alert thresholds: alert immediately on any component failure; alert at 99% availability (30-day rolling) for early warning before PBI SLA breach. Monthly availability report generated automatically. BI availability report format aligned to BI submission requirements. | System availability dashboard showing 99.5%+ achievement. Monthly availability reports. BI availability submission records. Alert configuration and response records. |
| Payment data localization | PBI 23 Pasal 47: Transaction data for Indonesian payment transactions must be processed and stored in Indonesian territory. Data may be replicated offshore for backup but primary processing must be onshore. | ISO 27001 does not require data localization — this is a regulatory geographic constraint outside ISO 27001 scope. | Verify that payment processing infrastructure is hosted in Indonesian data centers (Jakarta/Surabaya region). For cloud deployments: ensure payment databases and transaction processing are in the AWS ap-southeast-3 (Jakarta) or GCP asia-southeast2 (Jakarta) regions — not Singapore or other regions. Document data flow architecture showing processing location. Offshore replication (if used) must be for disaster recovery only. | Cloud infrastructure architecture diagram showing processing region (Jakarta). AWS/GCP region configuration screenshots for payment databases. Data flow diagram showing Indonesian processing with offshore DR replication. Third-party data center colocation agreement (if applicable). |
| Data localization is the most commonly overlooked BI requirement in cloud-native PSP implementations. The default AWS region in Southeast Asia is Singapore (ap-southeast-1). The default GCP region is also Singapore (asia-southeast1). A PSP that deploys to the default region and does not explicitly route Indonesian payment data to Jakarta (AWS ap-southeast-3 or GCP asia-southeast2) is in violation of PBI 23 Pasal 47 — regardless of how strong its other security controls are. Architecture review for data localization compliance should be conducted before go-live and verified annually. This is not a configuration complexity — it is a deployment decision that must be made deliberately. |
Five BI-Specific Gaps: Where ISO 27001 Is Not Sufficient
Five BI requirements are not addressed by ISO 27001 and require supplementary implementation. These gaps are consistently identified in BI licensing examinations for PSPs seeking initial or renewal licenses:
| BI-specific gap | PBI reference | ISO 27001 partial coverage | What ISO 27001 does not require | Supplementary action |
| Indonesian payment data localization | PBI 23 Pasal 47 | ISO 27001 5.14 (information transfer) addresses data transfer controls but does not require geographic storage of data. | ISO 27001 does not mandate data localization. A cloud-native PSP that stores payment transaction data in Singapore (or any non-Indonesian region) satisfies ISO 27001 data transfer controls but violates PBI 23. | Verify cloud region for all payment database storage. Migrate payment transaction data to AWS ap-southeast-3 (Jakarta) or GCP asia-southeast2 if currently in non-Indonesian region. Document with architecture diagram showing Indonesian data residence. |
| BI payment incident 2-hour notification | PBI 23 Pasal 40 | ISO 27001 5.26 requires incident notification to relevant stakeholders but does not specify BI or a 2-hour window. | The 2-hour BI notification window for payment system incidents is the most demanding regulatory notification requirement in the Indonesian financial sector. ISO 27001's general stakeholder notification requirement does not capture this specificity. | Update incident response procedure: add BI as mandatory notification recipient for payment system incidents. Define 'payment system incident' trigger criteria (service disruption > 15 minutes OR customer payment data exposure). Assign BI notification responsibility to a named role. Include BI notification portal URL and submission format in the procedure. |
| Minimum cryptographic standard specification | PBI 23 Pasal 26 | ISO 27001 8.24 requires appropriate cryptographic controls based on risk assessment — but does not specify minimum algorithm strengths. | PBI 23 specifies TLS 1.2 minimum for transit encryption and AES-256 minimum for at-rest encryption. ISO 27001's 'appropriate based on risk' standard does not set these floors explicitly. | Update cryptography policy to specify PBI-compliant minimums: TLS 1.2+ (TLS 1.3 preferred) for all payment API endpoints; AES-256 for payment databases and backup storage. Conduct TLS configuration audit. Document algorithm selection rationale in the cryptography policy. |
| BI pre-approval for critical third parties | PBI 23 Pasal 58 | ISO 27001 5.19–5.22 require supplier security assessment and ongoing monitoring. | BI pre-approval for 'critical' payment system third-party arrangements — before engagement — is a proactive regulatory obligation that ISO 27001 does not require. | Define 'critical' third-party threshold per PBI 23 criteria. Establish a process for BI pre-approval: identify arrangement, prepare BI submission package, submit and await approval before engagement. Document approval records in the supplier register. |
| Quantitative payment system risk metrics | PBI 23 Pasal 17 | ISO 27001 9.1 (monitoring and measurement) requires performance monitoring but organizations define their own metrics. | PBI 23 expects quantitative operational risk metrics for payment system operations: transaction failure rates, fraud rates, system availability percentages, incident frequency. ISO 27001 ISMS KPIs are typically security-focused (phishing click rates, vulnerability count) rather than payment operational metrics. | Add payment system operational KPIs to the ISMS monitoring framework: monthly transaction failure rate, monthly fraud detection rate, daily availability percentage, quarterly fraud incident count. Report to management review with PBI compliance context. |
The 2-hour BI incident notification window deserves particular attention in the incident response procedure. BI's notification requirement is triggered by two conditions: (1) payment service disruption lasting more than 15 minutes, or (2) payment customer data exposure of any scale. Both conditions can be triggered before the full extent of an incident is understood — the organization does not need to know the cause, the scope, or whether it is an attack or a system failure to be obligated to notify. The incident classification procedure must be designed to identify BI notification triggers early in the response process, not after root cause analysis is complete.
BI Supervision vs OJK Examination: Key Differences
Organizations subject to both BI supervision and OJK examination — particularly banks with payment services and fintech companies holding dual licenses — must manage two distinct regulatory relationships. Understanding the differences in supervision model, focus areas, and notification requirements helps organizations build appropriate compliance structures for each:
| Dimension | Bank Indonesia supervision | OJK examination |
| Primary authority | Bank Indonesia — central bank, payment system regulator | OJK — financial services authority, banking and NBFI regulator |
| Applicable organizations | Payment service providers (PSPs), e-money issuers, payment gateways, fintech lending, digital banking infrastructure | Banks, multifinance, insurance, capital markets, fintech operators in OJK sandbox |
| Primary regulation | PBI 23/6/PBI/2021 (PSPs), various sector-specific PBI | POJK 11/2022 (banks), POJK 21/2023 (IT risk), sector-specific POJK |
| Examination/supervision model | Off-site monitoring (continuous) + on-site examination (periodic or triggered). More data-driven supervision model using payment system data BI collects through PJSP reporting. | Periodic on-site examination cycle (typically every 2–3 years for larger institutions). Issue-triggered examinations following incidents or complaints. |
| Primary security focus | Payment system security: transaction integrity, fraud prevention, availability of payment infrastructure, payment data protection, cross-border payment controls. | IT governance structure, IT risk management framework, information security management, BCM, IT audit independence, outsourcing governance. |
| Notification requirements | Payment system incidents: notify BI within 2 hours. Significant PSP changes (new services, ownership): notify BI before implementation. | Significant IT incidents: notify OJK within 3×24 hours. Significant IT outsourcing: notify OJK before engagement. |
| Data localization requirement | Payment transaction data for Indonesian payments must be stored in Indonesia (PBI 23 Pasal 47). Hard requirement. | No equivalent mandatory data localization requirement (data residency guidance exists but is less prescriptive than PBI). |
| ISO 27001 recognition | BI accepts ISO 27001 certification as evidence of IS management maturity in examination context. Does not substitute for PBI-specific requirements. | OJK accepts ISO 27001 certification as positive evidence of IT governance maturity. Reduces examination depth for well-certified organizations. Does not substitute for POJK-specific requirements. |
For organizations subject to both BI and OJK, the ISMS provides a unified governance foundation that supports both supervisory relationships — with regulator-specific extensions addressing each supervisor's particular requirements. A single incident register, a single risk register, and a single evidence library — each with regulator-specific tagging and reporting views — is far more efficient than maintaining parallel compliance programs for each supervisor.
ISO 27001 in the BI Licensing Process
The BI PSP licensing process is one of the most practically consequential applications of ISO 27001 for Indonesian fintech organizations. BI explicitly considers information security management capability in licensing decisions — and an ISO 27001 certificate from an accredited CB is one of the strongest signals of that capability:
| Licensing stage | ISO 27001 role | BI requirements | Action |
| PSP License Application | ISO 27001 certification (or documented implementation plan with timeline) demonstrates to BI that the applicant has a systematic approach to information security — one of BI's key assessment criteria for PSP licensing. | BI requires applicants to demonstrate: IT infrastructure readiness, security policy and procedures, risk management framework, IS personnel competence, business continuity plan. These are directly evidenced by ISMS documentation. | For organizations applying for PSP licensing: initiate ISO 27001 implementation simultaneously with the licensing process. Submit the ISMS scope, IS Policy, risk assessment, and SoA as part of the BI application package. If certification is not yet obtained, submit the implementation plan with a target certification date. |
| PSP License Approval and Initial Examination | BI conducts an initial examination within 6 months of license grant. ISO 27001 certification at this stage significantly reduces examination depth and demonstrates post-licensing security maturity. | Initial examination covers: IS controls implementation, payment system availability, fraud monitoring capability, incident response readiness, third-party management. All areas are covered by ISO 27001 Annex A controls. | Target ISO 27001 certification within the first 12 months of PSP licensing. Use the Stage 2 audit experience as preparation for the BI initial examination — the areas tested are substantially overlapping. |
| Ongoing BI Supervision | ISO 27001 surveillance audits and the continuing operational discipline of the ISMS provide ongoing evidence of security management maturity for BI's continuous supervision program. | BI's ongoing supervision includes: quarterly availability and incident reporting, annual security assessment submission, periodic on-site examination (typically every 2–3 years for compliant operators), event-triggered examination following significant incidents. | Align the ISO 27001 surveillance audit calendar with the BI annual security assessment schedule. Use surveillance audit findings to improve the ISMS before BI examinations. Submit the ISO 27001 surveillance audit report to BI as part of the annual security assessment (if BI accepts this format). |
| License Renewal / Expansion | ISO 27001 certification strengthens the license renewal and scope expansion application — demonstrating sustained security management capability over the licensed period. | BI license renewal and scope expansion require evidence of compliance with PBI requirements throughout the license period. A clean ISO 27001 surveillance record (no major NCs, evidence of improvement) is compelling evidence of sustained compliance. | Prepare a compliance summary document for BI license renewal that maps ISO 27001 certificate milestones (initial certification, surveillance audits) to PBI 23 compliance milestones. Include the most recent internal audit and management review as evidence of ongoing ISMS health. |
| Bitlion BI compliance module: Bitlion's GRC platform includes BI regulatory mapping as a built-in feature — PBI 23/2021 requirements are mapped to Annex A controls and ISMS clause requirements. The BI examination evidence package can be generated directly from the platform, organized by PBI 23 section. The payment system incident notification workflow tracks the 2-hour BI notification countdown with escalation reminders at 30 minutes, 60 minutes, and 90 minutes from incident declaration. Data localization configuration is tracked as a control attribute in the asset inventory — flagging payment databases not in Indonesian cloud regions. |
PBI-Specific ISMS Enhancements
Payment-specific scope statement
The ISMS scope statement for a PSP should explicitly reference the payment system components within scope — not just generic 'information processing facilities'. A scope statement that reads 'The ISMS covers the payment processing platform, including the transaction processing engine, payment API gateway, customer authentication system, and fraud monitoring infrastructure, operated from AWS ap-southeast-3 (Jakarta)' is far more useful to BI examiners than a generic scope statement. It demonstrates that the ISMS covers the right systems and that data localization is addressed.
Payment risk appetite statement
The ISO 27001 IS Policy risk appetite statement should be enhanced for PSP operations to include payment-specific risk thresholds: maximum acceptable transaction failure rate (e.g. less than 0.1%), maximum acceptable fraud loss rate (e.g. less than 0.05% of transaction value), minimum acceptable system availability (e.g. 99.5%), and maximum acceptable time-to-detect a significant payment system incident (e.g. less than 30 minutes). These quantitative thresholds make the risk appetite statement directly relevant to BI supervision and give operational teams clear performance targets.
Payment IS register as evidence for BI
Beyond the standard ISMS documentation, PSPs should maintain a Payment IS Register — a consolidated document that maps each PBI 23 requirement to the ISMS control that addresses it, the implementation status, and the evidence location. This register serves as the primary navigation document for BI examinations — replacing the need for examiners to cross-reference ISO 27001 and PBI documentation independently. It demonstrates that the ISMS was designed with PBI compliance in mind, not just with ISO 27001 conformance.