Regulation of the Board of Commissioners of the Financial Services Authority Number 1 of 2026 on Information Technology Management by Commercial Banks

COPY
REGULATION OF THE BOARD OF COMMISSIONERS OF THE FINANCIAL SERVICES AUTHORITY REPUBLIC OF INDONESIA NUMBER 1 OF 2026 CONCERNING INFORMATION TECHNOLOGY MANAGEMENT BY COMMERCIAL BANKS

BY THE GRACE OF GOD THE ALMIGHTY,

THE BOARD OF COMMISSIONERS OF THE FINANCIAL SERVICES AUTHORITY,

Considering: that in order to implement the provisions of Article 10, Article 11, Article 12, Article 15, Article 16, Article 17, Article 18, Article 34, Article 38, Article 39, Article 43, Article 47, Article 52, Article 57, and Article 65 of the Financial Services Authority Regulation Number 11 of 2022 concerning Information Technology Management by Commercial Banks, as well as to support the continuity of bank operations and services in the utilization of information technology, it is necessary to establish a Regulation of the Board of Commissioners of the Financial Services Authority concerning Information Technology Management by Commercial Banks;

Recalling: 1. Law Number 21 of 2011 concerning the Financial Services Authority (State Gazette of the Republic of Indonesia Year 2011 Number 111, Supplement to the State Gazette of the Republic of Indonesia Number 5253) as amended by Law Number 4 of 2023 concerning the Development and Strengthening of the Financial Sector (State Gazette of the Republic of Indonesia Year 2023 Number 4, Supplement to the State Gazette of the Republic of Indonesia Number 6845);
2. Financial Services Authority Regulation Number 11 of 2022 concerning Information Technology Management by Commercial Banks (State Gazette of the Republic of Indonesia Year 2022 Number 5/OJK, Supplement to the State Gazette of the Republic of Indonesia Year 2022 Number 5/OJK);

DECIDING:

To establish:
A REGULATION OF THE BOARD OF COMMISSIONERS OF THE FINANCIAL SERVICES AUTHORITY CONCERNING INFORMATION TECHNOLOGY MANAGEMENT BY COMMERCIAL BANKS.

Article 1
Provisions regarding IT management by Banks as contained in:
a. Appendix I containing guidelines for information technology management by commercial banks; b. Appendix II containing procedures for submitting reports and permit applications;
c. Appendix III containing report and notification formats; and
d. Appendix IV containing permit application and realization report formats, which are an inseparable part of this Regulation of the Board of Commissioners of the Financial Services Authority.

Article 2
Banks that have used third-party IT service providers prior to the implementation of this Regulation of the Board of Commissioners of the Financial Services Authority must adjust the agreements made in accordance with the provisions in this Regulation of the Board of Commissioners of the Financial Services Authority.

Article 3
The submission of reports on the current condition of IT management using the format as contained in Appendix III of this Regulation of the Board of Commissioners of the Financial Services Authority is carried out in accordance with:
a. Financial Services Authority provisions regarding reporting by conventional commercial banks through the Financial Services Authority reporting system; and b. Financial Services Authority provisions regarding reporting by Islamic commercial banks and Islamic business units through the Financial Services Authority reporting system.

Article 4
At the time this Regulation of the Board of Commissioners of the Financial Services Authority comes into force, the provisions as referred to in Financial Services Authority Circular Letter Number 21/SEOJK.03/2017 concerning the Implementation of Risk Management in the Use of Information Technology by Commercial Banks are revoked and declared invalid.

This copy is in accordance with the original
Head of the Legal Development Directorate
Legal Department signed.
Aat Windradi

Article 5
This Regulation of the Board of Commissioners of the Financial Services Authority comes into force on March 1, 2026.

Established in Jakarta on January 23, 2026

EXECUTIVE HEAD OF BANKING SUPERVISOR
FINANCIAL SERVICES AUTHORITY
REPUBLIC OF INDONESIA,
DIAN EDIANA RAE signed.

APPENDIX I
REGULATION OF THE BOARD OF COMMISSIONERS OF THE FINANCIAL SERVICES AUTHORITY REPUBLIC OF INDONESIA NUMBER 1 OF 2026 CONCERNING INFORMATION TECHNOLOGY MANAGEMENT BY COMMERCIAL BANKS

GUIDELINES
FOR INFORMATION TECHNOLOGY MANAGEMENT BY COMMERCIAL BANKS

TABLE OF CONTENTS
GUIDELINES FOR IT MANAGEMENT BY COMMERCIAL BANKS
TABLE OF CONTENTS.........................................................................................................- 3 -
CHAPTER I - INTRODUCTION......................................................................................- 5 -
CHAPTER II - BANK IT GOVERNANCE .........................................................................- 6 -
A. Introduction ......................................................................................- 6 -

Factors for Implementing IT Governance.................................................- 6 -
Aspects of IT Governance...................................................................- 7 -
B. Roles and Responsibilities..............................................................- 10 -
Board of Directors......................................................................................- 10 -
Board of Commissioners......................................................................- 11 -
IT Steering Committee ..................................................................- 11 -
Head of IT Work Unit........................................................- 12 -
C. IT Work Unit.................................................................................- 13 -
Planning.............................................................................- 13 -
Formulation or Development.............................................- 13 -
Operation ..........................................................................- 20 -
Monitoring .............................................................................- 26 -
CHAPTER III - BANK IT ARCHITECTURE........................................................................- 27 -
A. IT Architecture .....................................................................................- 27 -
Consideration Factors in Formulating IT Architecture ............- 27 -
Formulation of IT Architecture.........................................................- 28 -
B. IT Strategic Plan.........................................................................- 31 -
Formulation of IT Strategic Plan ............................................- 31 -
Changes to IT Strategic Plan...............................................- 32 -
CHAPTER IV - IMPLEMENTATION OF IT MANAGEMENT RISK IN BANK IT MANAGEMENT ...- 33 -
A. IT Risk Management Process .............................................................- 33 -
Risk Identification.....................................................................- 33 -
Risk Measurement ...................................................................- 34 -
Risk Monitoring...................................................................- 35 -
Risk Control .................................................................- 35 -
B. Information Security in Bank IT Management..................- 36 -
Information Security.............................................................- 37 -
Communication Networks ...............................................................- 45 -
Disaster Recovery Plan ...................................................- 46 -
CHAPTER V - USE OF THIRD-PARTY IT SERVICE PROVIDERS IN BANK IT MANAGEMENT
BANK ................................................................................................................- 54 - A. Introduction ....................................................................................- 54 - B. Policies and Procedures....................................................................- 54 -
Process for Identifying Needs for Using Third-Party IT Service Providers (PPJTI)....................- 54 -
PPJTI Selection Process ............................................................- 55 -
Working Relationships with PPJTI .......................................- 56 -
Risk Management Process for Using PPJTI ...........................- 59 -
Procedures for Assessing PPJTI Performance and Compliance ...................- 61 -
C. Use of PPJTI Outside the Territory of Indonesia ..................................- 61 -
D. Reassessment of Materiality towards PPJTI ....................................- 62 -
CHAPTER VI - PLACEMENT OF ELECTRONIC SYSTEMS AND IT-BASED TRANSACTION PROCESSING
....................................................................................................................- 63 - A. Placement of Electronic Systems.........................................................- 63 - B. IT-Based Transaction Processing....................................................- 63 -
CHAPTER VII - DATA MANAGEMENT AND PERSONAL DATA PROTECTION IN
BANK IT MANAGEMENT .........................................................................- 64 - A. Data Management ..............................................................................- 64 -
Data Ownership and Administration.......................................- 64 -
Data Quality ...........................................................................- 64 -
Data Management System ..........................................................- 64 -
Supporting Resources for Data Management .............................- 65 -
B. Personal Data Protection .................................................................- 65 -
Consent for Personal Data Processing......................................- 65 -
Personal Data Protection Impact Analysis..............................- 66 -
Exchange of Personal Data...........................................................- 66 -
CHAPTER VIII - PROVISION OF IT SERVICES BY BANKS..................................................- 68 -
A. Introduction ....................................................................................- 68 - B. Policies, Standards, and Procedures ....................................................- 68 -
Policies and Standards for IT Service Provision by Banks .............- 68 -
Procedures for IT Service Provision by Banks ...................................- 69 -
C. IT Service Provision Agreements by Banks..........................................- 69 -
CHAPTER IX - INTERNAL CONTROL AND AUDIT IN BANK IT MANAGEMENT
................................................................................................................- 71 - A. Internal Control in IT Management................................................- 71 - B. Internal Audit in IT Management ............................................- 71 -
Policies, Standards, and Procedures related to IT Audit ...................- 71 -
IT Audit Process .........................................................................- 73 -
Fulfillment of IT Internal Audit Functions by External Auditors .........- 74 -

CHAPTER I
INTRODUCTION

Information Technology (IT) plays an important role in supporting the operations and business of the banking industry. The very rapid development of IT offers various alternative solutions and conveniences for the banking industry. On the other hand, increased utilization of IT can also generate risks that need to be identified, mitigated, and even controlled, so as not to disrupt banking business. Therefore, Banks need to strengthen governance in IT management so that IT utilization can add value to the Bank through the optimization of resources to mitigate the risks faced by the Bank.

In connection with the implementation of the Financial Services Authority Regulation Number 11/POJK.03/2022 concerning Information Technology Management by Commercial Banks (POJK PTI), guidelines regarding IT management by Banks are needed.

The IT management guidelines contain further elaboration of the provisions in POJK PTI which can serve as a reference for Banks in managing IT in accordance with POJK PTI. The scope of the IT management guidelines includes:

implementation of IT governance;
formulation of IT architecture, including IT strategic plans;
implementation of IT risk management;
cybersecurity resilience and security;
use of third-party IT service providers;
placement of Electronic Systems and IT-based transaction processing;
data management and personal data protection;
provision of IT services by Banks;
IT internal control and audit; and
assessment of the Bank's digital maturity level.

The guidelines for cyber resilience and security as referred to in item 4 refer to the Financial Services Authority Circular Letter concerning Cyber Resilience and Security for Commercial Banks (SEOJK Siber), and the guidelines for assessing bank digital maturity as referred to in item 10 refer to the Financial Services Authority Circular Letter concerning Assessment of the Digital Maturity Level of Commercial Banks (SEOJK DMAB).

CHAPTER II
BANK IT GOVERNANCE

A. Introduction

The utilization of IT by Banks aims to ensure that IT adds value and aligns with the Bank's business strategy. IT governance provides a framework and structure guide, which connects IT resources and information with business objectives and strategies. IT governance aims to ensure that IT assets support the Bank's business objectives, through IT performance planning, development, implementation, and monitoring in accordance with best practices. In IT management, Banks are required to implement good IT governance as regulated in Article 2 paragraph (1) of POJK PTI.

The implementation of IT governance is an integral part of the implementation of general Bank governance. IT governance is applied to all activities related to IT management, including risk management, IT and cyber resilience and security, data management, use of Third-Party IT Service Providers (PPJTI), provision of IT services by Banks, internal control, as well as development and changes to IT. The implementation of IT governance applies to all units and/or functions in the Bank, both as IT managers and IT users.

Factors for Implementing IT Governance

In implementing good IT governance, Banks consider at least 7 (seven) factors as referred to in Article 2 paragraph (2) of POJK PTI, namely:
a. Bank's Business Strategy and Objectives
IT governance is adjusted to the Bank's business strategy and objectives. The Bank's business strategy and objectives reflect the business direction and needs of stakeholders. In determining business strategy and objectives, Banks can consider among others:

business growth;
types of products and/or services provided, including business innovation; and
cost efficiency strategy.
b. Size and Complexity of Bank's Business
The size and complexity of the Bank's business can be determined based on among others organizational structure, total number of employees, total number of office networks, and complexity of products and services provided.
c. Role of IT for the Bank
The role of IT for the Bank reflects how important IT is in supporting the Bank's business. Some business models that show the role of IT for the Bank include:
IT has a direct impact on the continuity of business processes and services, but IT is not yet considered a driver of business process and service innovation;
IT is considered a driver of business process and service innovation, but there is no critical dependence on IT for the continuity of business processes and services; and
IT plays a very important or critical role in running business processes and services.
d. IT Resource Acquisition Methods
IT resource acquisition methods are adjusted to the Bank's needs and capabilities, including among others self-acquisition, acquisition using PPJTI, and a combination of both. e. IT-Related Risks and Issues The implementation of IT governance needs to be adjusted to the risk profile and IT-related issues faced by the Bank. f. Practices or Standards Applicable Nationally and Internationally The determination of practices or standards applicable nationally and internationally to be used as the basis for implementing IT governance is in accordance with the Bank's needs and capabilities. g. Provisions of Legislation The implementation of IT governance is carried out in accordance with the provisions of legislation.

Aspects of IT Governance

In accordance with Article 3 Paragraph (1) of POJK PTI, Banks are required to map, plan, and/or establish aspects of IT governance. Banks also ensure the creation of synergy in all aspects of IT governance. Aspects of IT governance consist of at least:
a. Business Processes
Business Processes are a set of structured activities arranged to achieve business objectives, and produce outputs that support the achievement of IT-related objectives as a whole. At the governance level, business processes are reflected through activities evaluating strategy choices, directing IT management strategies, and monitoring strategy achievement. Whereas at the management level, business processes are reflected through activities:

alignment, planning, and organization of all units, strategies, and activities supporting IT management;
definition, acquisition, and implementation of IT solutions and their integration into the Bank's business processes;
provision of operational IT service support to stakeholders; and
monitoring IT management performance and compliance with internal performance targets, internal controls, and legislative provisions.
b. Organizational Structure
Banks must establish the duties and responsibilities of each position related to each business process owned by the Bank in IT management. In determining the organizational structure, Banks need to adjust to the needs of IT management and use, considering at least:
the organizational structure specifically describes the lines of authority, reporting, and responsibilities for each IT function owned, including the person designated as a replacement in the event of a vacancy in the organizational structure;
an organizational structure that does not open opportunities for anyone independently to commit and/or conceal errors or deviations in the implementation of duties and can deactivate system security facilities;
the principle of segregation of duties to prevent someone from having responsibility for different and critical functions, such that errors are not easily detected, for example, designating different employees as the information security administrator and the IT development manager with employees carrying out IT operational activities;
other forms of supervision (compensating controls) to prevent errors related to IT management, for banks with relatively small business scales or branch offices in remote areas that cannot apply the principle of segregation of duties and responsibilities adequately either wholly or partially.
In determining the form of compensating controls to be applied, Banks need to consider data ownership, transaction authorization responsibility, and data access rights. Examples of compensating controls include audit trails, reconciliation, exception reporting, transaction logs, supervisory review, and independent review. Even if compensating controls are applied, IT management must still be based on the principle of prudence;
personnel placement considers Human Resource (HR) competence, including knowledge and expertise, appropriate to the position or duties;
the division of responsibilities and target setting are well formulated among the IT risk management implementation function and the functional fields of IT management.
c. Policies, Standards, and Procedures
Banks establish policies, standards, and procedures for all IT management.
Policies
Policies are provisions or principles describing the Bank's commitment or plans regarding a particular issue stated formally, and serve as the working foundation for the Bank.
Standards
Standards are a set of technical rules that must be complied with in order to implement an IT framework and governance (can be from internal or external sources). Standards establish specific requirements or measures that can be used as a reference for Banks in managing IT. a) internal standards include among others desktop application standards, computer configuration standards, and document numbering standards. b) external standards include among others International Organization for Standardization (ISO), Indonesian National Standards (SNI), or other standards related to IT management.
Procedures
Procedures are the sequence of activities in an IT management process involving one or more units and/or functions in the Bank.
In accordance with Article 3 paragraph (3) of POJK PTI, policies, standards, and procedures are applied by Banks consistently and continuously. In addition, Banks are required to conduct reviews and revisions of policies, standards, and procedures periodically in accordance with Article 3 paragraph (4) of POJK PTI. Banks establish the review and revision period for policies, standards, and procedures in accordance with the Bank's needs, considering the Bank's internal and external conditions. The establishment of the review and revision period for policies, standards, and procedures is formulated by the Bank in a written policy. Example:
Bank "X" establishes the review and revision period for:
policies every 5 (five) years;
standards every 2 (two) years; and
procedures every 1 (one) year.
d. Information Needs and Flow Supporting Business Processes Every decision, directive, monitoring, and evaluation in the governance system always requires accurate, relevant, and timely information. Banks need to ensure that available information is relevant, accurate, timely, secure, and actionable in accordance with the Bank's needs to support the Bank's business processes. Therefore, Banks need to ensure the availability of a Management Information System (MIS) that can generate the information needed to support the role and function of management effectively. The MIS owned by the Bank must be able to:
facilitate the management of the Bank's business operations including customer service;
document and collect information objectively;
distribute data or information to various appropriate work units, both in terms of information type, quality and quantity of information, as well as the frequency and time of report delivery required;
improve the effectiveness and efficiency of communication in the Bank;
help the Bank improve compliance with legislative provisions; and
support the performance assessment process of all work units.
e. Supporting Human Resources
Banks need to map, plan, and establish the number, competence, and expertise of HR suitable for IT management. The development of competence and expertise of the Bank's HR, such as organizing training or certification, needs to be done so that the Bank's HR can support the successful implementation of IT governance. This includes the Bank's HR recruitment strategy and requirements.

f. IT Culture
IT Culture refers to the values and ethics applicable to employees as individuals and to the Bank as an organization, which are consistent with the objectives of achieving IT governance. The Bank implements IT culture across all units and/or functions of the Bank. IT culture includes, among others, a culture of innovation and a culture of collaboration. g. Infrastructure and Applications The Bank ensures the availability of infrastructure and applications that are managed with regard to IT governance.

B. Roles and Responsibilities
Pursuant to Article 4 of the POJK on IT Governance, the Bank is required to establish clear authority and responsibilities for the Board of Directors, the Board of Commissioners, and officials at every level of position related to the implementation of IT governance. The success of IT governance implementation heavily depends on the commitment of the Board of Directors, the Board of Commissioners, the IT Steering Committee, and all work units in the Bank, both as IT providers and users. The implementation of IT governance is carried out through the alignment of the IT Strategic Plan (RSTI) with the Bank's corporate plan, as well as the optimization of resource management, IT utilization, performance measurement, and the application of effective risk management. The realization of the commitment of the Board of Directors and the Board of Commissioners is in the form of active supervision by the Board of Directors and the Board of Commissioners over IT governance as regulated in Article 5 and Article 6 of the POJK on IT Governance, as well as the active role of the IT Steering Committee in providing recommendations regarding IT management as regulated in Article 7 of the POJK on IT Governance. In this regard, policies containing the roles and responsibilities of the Board of Directors, the Board of Commissioners, and the IT Steering Committee in ensuring the implementation of IT governance are required.

Board of Directors
In addition to the authority and responsibilities for the Board of Directors as regulated in Article 5 of the POJK on IT Governance, the authority and responsibilities for the Board of Directors may also include:
a. ensuring the availability of sufficient and competent human resources according to needs; b. ensuring efforts to improve the competence of human resources related to IT management, including through adequate education or training and education programs to increase awareness of information security;
c. ensuring that the organizational structure for project management of all IT-related projects is used to its fullest extent;
d. ensuring that the Bank has a written contract regulating the roles, relationships, obligations, and responsibilities of all parties bound by such contract, and having the conviction that such contract is a legally binding agreement that protects the Bank's interests, in the event the Bank uses the services of third parties; e. applying digital-oriented leadership; f. ensuring that digitalization initiatives or digital transformation contained in the Bank's RSTI are in line with the Bank's direction and strategy in the corporate plan; and g. applying a digital culture development program to support digital transformation.

In establishing the authority and responsibilities for the Board of Directors, the Bank must also pay attention to the SEOJK on Cybersecurity and the SEOJK on Digital Banking and Financial Technology.

Board of Commissioners
In addition to the authority and responsibilities for the Board of Commissioners as regulated in Article 6 of the POJK on IT Governance, the authority and responsibilities for the Board of Commissioners may also include:
a. evaluating, directing, and monitoring risk management policies in the IT field and the suitability of their implementation with the Bank's characteristics, complexity, and risk profile; b. providing guidance for improvements in the implementation of risk management policies in the IT field;
c. conducting evaluations of audit planning and implementation, ensuring audits are carried out with adequate frequency and scope, and monitoring follow-up on audit results related to information systems;
d. conducting evaluations of reliable and effective security management over IT to guarantee the availability, confidentiality, and accuracy of information; e. evaluating, directing, and monitoring the alignment between the RSTI and the Bank's direction and strategy in the corporate plan; f. evaluating, directing, and monitoring the application of digital-oriented leadership; and g. evaluating, directing, and monitoring the application of digital culture development programs to support digital transformation.

In establishing the authority and responsibilities for the Board of Commissioners, the Bank must also pay attention to the SEOJK on Cybersecurity and the SEOJK on Digital Banking and Financial Technology.

IT Steering Committee
Pursuant to Article 7 of the POJK on IT Governance, the Bank is required to have an IT Steering Committee. For Banks that are Branch Offices of Banks located Abroad (KCBLN), the function of the IT Steering Committee may be carried out by a similar function located at the head office or regional office of the KCBLN. The IT Steering Committee must have an IT Steering Committee Charter that states the authority and responsibilities of the IT Steering Committee. To carry out its duties effectively and efficiently, the IT Steering Committee holds regular meetings to discuss topics related to IT strategy, which are documented in the form of meeting minutes. The authority and responsibilities of the IT Steering Committee as regulated in Article 7 of the POJK on IT Governance are to provide recommendations to the Board of Directors, at least regarding:
a. RSTI that aligns with the Bank's corporate plan. In providing recommendations, the IT Steering Committee must pay attention to:

a roadmap to meet IT needs that support the Bank's business strategy. The roadmap consists of the current state, the desired future state, and the steps to be taken to achieve the desired state;
the resources required;
the benefits to be obtained when the RSTI is implemented; and
constraints that may arise in the implementation of the RSTI, while still considering factors of effectiveness and efficiency;
b. the formulation of main IT policies, standards, and procedures, such as IT security policies and risk management related to the use of IT in the Bank;
c. the alignment between IT development plans and the RSTI. The IT Steering Committee also sets the priority status of IT development plans that are critical and have a significant impact on the Bank's operational activities, such as the replacement of the core banking system, production servers, and network topology;
d. the alignment between the implementation of IT development and the agreed IT development plan, including through project charters. The IT Steering Committee must complete recommendations with the results of analysis of the implementation of main IT development, thereby enabling the Board of Directors to make decisions efficiently; e. the evaluation of IT cost effectiveness against the achievement of planned benefits, so that IT investments can contribute to the achievement of the Bank's business objectives; f. monitoring IT performance and efforts to improve IT performance, such as detecting obsolete IT infrastructure and measuring the effectiveness and efficiency of IT security policy implementation; g. efforts to resolve various IT-related problems that cannot be resolved effectively, efficiently, and on time by the user work units and IT provider work units; and h. the adequacy and allocation of IT-related resources owned by the Bank. In the event that the owned resources are inadequate and the Bank will use the services of third parties in IT management, the IT Steering Committee must ensure that the Bank has the necessary policies and procedures.

Head of IT Work Unit
In order to carry out IT management, the Bank establishes the main authority and responsibilities of the highest official leading the IT work unit, including at least:
a. formulating IT policies, plans, and budgets; b. coordinating the Bank's IT development in accordance with the established strategic plans;
c. implementing all IT policies, standards, and procedures as well as plans established by the Board of Directors;
d. providing IT service support to IT user work units to achieve business targets responsively and on time; e. ensuring that all information owned by IT user work units receives good protection against all disturbances that could cause losses due to data leaks or important information leaks; f. ensuring the adequacy and effectiveness of IT policies, procedures, and the application of risk management to identify, measure, assess, and supervise IT risks; g. ensuring adequate supervision in every IT system development or modification; h. reporting to the Board of Directors on the periodic implementation of IT. If necessary, it may also propose actions to address IT weaknesses that have been found;
i. assessing the performance of IT services in the Bank, for example, the percentage of system downtime, security violations, project developments, and the application of Service Level Agreements (SLA) between the IT work unit and user work units or Third-Party IT Providers (PPJTI);
j. ensuring that appropriate actions have been taken to fix audit findings from both internal and external auditors or based on examination results reports from the Financial Services Authority; k. ensuring the adequacy of human resources both in IT management and in the application of risk management, and guaranteeing the retention of human resources in critical IT positions to support operational continuity and IT development;
l. supervising the implementation of IT budgets such as procurement and training in the IT field, in the event the highest official of the IT work unit is a director;
m. being responsible for the preparation and implementation of IT architecture and other strategic plans that significantly affect the Bank's capital, in the event the highest official of the IT work unit is a director; n. ensuring that the organizational structure for project management of all IT-related projects is used to its fullest extent, in the event the highest official of the IT work unit is a director; and o. ensuring that written contracts between the Bank and PPJTI cover matters regulated for the use of PPJTI services. If the IT work unit is not led by an IT director, then the roles and responsibilities as referred to in letters l, m, and n become the responsibility of the director who oversees the IT work unit.

C. IT Work Unit
Pursuant to Article 8 of the POJK on IT Governance, the Bank is required to have an IT provider work unit responsible for IT management. IT management includes at least:

Planning
The main activity in planning is determining strategic plans and the direction of IT management, in order to support the Bank's business needs. In carrying out planning activities, the IT work unit must at least:
a. prepare an RSTI that is aligned with the Bank's corporate plan; b. align IT development plans to match the established RSTI and business objectives in the Bank's corporate plan;
c. prepare investment plans in IT management, including IT budgets; and
d. plan IT resource management strategies.
Preparation or Development
The main activity in preparation or development is to ensure that IT solution development can be implemented effectively and in accordance with the Bank's needs. In carrying out IT development, the Bank pays attention to the following processes:
a. Planning, including identifying and analyzing user needs, and defining user needs; b. Design, construction/configuration (build), and testing; and
c. Implementation and post-implementation review.
The above processes can be carried out in accordance with the IT development policies and methodologies conducted by the Bank. The Bank must also establish IT development processes in the event of emergency conditions (emergency change). In the event that IT development involves PPJTI, the Bank must pay attention to guidelines regarding the use of PPJTI as regulated in the Appendix of this Commissioner Board Regulation. The Bank must have adequate risk management against the IT development process to minimize various risks or losses caused by errors, fraud, data manipulation, system abuse, or inaccuracy of developed service functions. Risk management against the development process includes, among others, policies, standards, procedures, and processes for identifying and measuring risks in the IT development process. In carrying out IT development, the Bank takes control steps to generate system integration and ensure data confidentiality, as well as supporting the achievement of the Bank's objectives. Control steps aim to ensure, among others:
a. the accuracy and functionality of systems according to the Bank's needs; b. the compatibility of one system with another (interoperability and compatibility);
c. the availability of documentation on system development, changes, and maintenance;
d. the maintenance of confidentiality, integrity, and availability principles; e. the continuity of the Bank's operations, including in the event the Bank uses PPJTI; f. the separation of development and operational (production) environments; g. the accountability of tasks and responsibilities of all parties involved in IT development; h. the availability of audit trails when needed for examination purposes; and
i. the possession of source code for software developed specifically for the respective Bank (proprietary) so that the source code can be accessed when needed for examination and investigation purposes.
The IT development process must always be under the control of the IT work unit and managed by project management. Project management can take the form of a work team whose members come at least from the IT work unit and the IT user work unit, tasked with ensuring that systems have been developed with a good structure and have accommodated user needs.

a. Policies, Standards, and Procedures for Development Processes in IT development include:

Planning Stage
In the planning stage, the Bank applies steps, including:
a) identification and analysis of user needs to support the Bank's business strategy; b) review and approval by the Bank; c) project feasibility study, which includes considerations of the Bank's business, functional needs, project implementation schedule, factors affecting the project, and cost-benefit analysis; d) Bank's approval of the project feasibility study document; e) signing of the project feasibility study document by all parties related to IT development; f) requirements gathering, which is a process of collecting information, either through interviews, research, and/or filling out specific document formats or forms, regarding the system development objectives, desired outputs, system capabilities in accommodating business process needs and system work mechanisms, and system usage procedures; g) requirements analysis, which is a process of understanding problems and needs to determine solutions that can be developed; h) preparation of business process flows based on the results of requirements analysis, including business process flow, use cases modeling, and data flow diagrams, which can clarify understanding of needs and solutions for both users and system developers; i) determination of general estimates of time and cost for the development of each requirement and its compliance with applicable regulations; j) requirements specification, which is a process to describe the functional system to be developed, process or procedure specifications, and existing systems, both in terms of software and supporting hardware as well as database design. Requirements specifications must be complete, comprehensive, testable, consistent, clear, and detail the required input, process, and output; and k) requirements management, which is a process to identify, control, and store every change to requirements when development is carried out by the project team.
Design Stage
The design stage is divided into 3 (three) main steps, namely:
a) System Design
The Bank converts the identified information needs, functions, and infrastructure from the planning stage into the basis for system development. In system design, an application control standard is required, covering policies and procedures related to user activities and integrated controls in the system to be developed. This is necessary to increase security, integrity, and system reliability by ensuring that authorized, accurate, complete, and safe input, process, and information are maintained. The Bank needs to pay attention to the alignment of the design with the existing IT architecture to ensure integration and continuity between systems. b) Programming The Bank converts design specifications into executable programs. The Bank must create policies, standards, and procedures for programming. In addition, the Bank must prepare migration plans, implementation, end-user and operator training, and maintenance manual documents. (1) Programming Standards Programming standards explain, among others, the responsibilities of system programmers. Project managers must understand the entire programming process to ensure that control implementation in programming activities is adequate, including:
(a) limiting access to data, programs, utilities, and systems outside the programmer's responsibility; and (b) performing version control as a method that systematically stores the chronology of improved program copies and serves as one of the documents in IT development management. (2) Documentation (a) The Bank must manage and maintain detailed documents for each system, whether developed internally or products or software purchased or developed by third parties, including:
i. detailed descriptions of applications;
ii. programming documentation in the form of source code, downloadable documents, and displays of the developed system;
iii. format standards for various aspects used related to the system such as databases, display formats, and information;
iv. naming standards; and
v. guidelines for operators and end-users in executing system functions in detail, comprehensively, and clearly.
(b) Documentation must be able to identify development standardization, such as system narratives, system flows, special system coding, and internal controls in the application documents themselves. (c) In the event that products or software are purchased or developed by third parties, the Bank must ensure that a review has been conducted previously, either internally or by an independent party, that the product or software documentation has met the Bank's minimum documentation standards. c) Testing The Bank must carry out several series of tests to ensure the accuracy and functionality of systems according to user needs as well as the relationship of such systems with other systems already used by the Bank. All corrections and modifications made during testing must be documented to maintain the integrity of the entire program documentation. The Bank must complete guidelines for users and managers and prepare implementation and training plans. Tests that can be carried out by the Bank include:
(1) Unit test, which is a test conducted by developers on the functionality of each unit or sub-module of the completed system; (2) System Integration Test (SIT), which is testing conducted by developers on the overall functionality of the system after it has been integrated into a whole; (3) Stress test, which is a resilience test conducted by developers on the system's ability to handle processes or transactions on a large scale or quantity; and (4) User Acceptance Test (UAT), which is the final test conducted by end-users on the completed system to test the overall functionality of the system, whether it meets user needs as defined in the user requirements definition stage before deciding that implementation can be carried out. UAT by end-users is conducted after the developer provides a report on the results of SIT testing. At this stage, internal audit may also participate in testing while maintaining the level of independence if internal audit needs to verify the availability, adequacy, and effectiveness of existing controls in the system. If the test results show that the system meets user needs and the Bank's security standards, a UAT report approved by the user must be created.
Implementation and Review Stage
At this stage, the Bank must carry out, among others, notification of the implementation schedule, installation of the approved system into the operational environment, and training for users. Matters to be paid attention to include:
a) checking program integrity by means of adequate controls over the conversion from source code to object code to be implemented; b) data migration from the old system to the new system; c) checking the accuracy and security of data results from migration on the new system; d) the possibility of implementing a parallel run between the old and new systems until it is certain that the data on the new system is accurate and reliable; e) the Bank must ensure data integrity in terms of the accuracy and reliability of the database, including data stored within it; f) direct data and reference fixes (patching data) during implementation should be avoided as they can affect data integrity in the production server database; g) arrangement for storing source code and databases from the old system; and h) anticipation of weaknesses in the operating system, developed systems, databases, and networks, including threats from unauthorized parties such as viruses, trojan horses, worms, spyware, Denial-of-Service (DoS), wardriving, spoofing, and logic bombs, by testing and applying security controls over the system to be implemented. The Bank must conduct a post-implementation review at the end of the project to ensure that all activities in the project have been carried out and project objectives have been achieved. The effectiveness of project management activities is carried out by comparing, among others, plans and actual costs, benefits obtained, and project schedule accuracy. Analysis results must be documented to support reporting needs related to the project. In the event that system development also involves the procurement process, attention must also be paid to the alignment of specifications with the Bank's needs, impact on existing systems, after-sales technical support, vendor reputation, documentation completeness, escrow agreements, and training.

In the system procurement process, the Bank must also ensure that:

the procurement of hardware and software has gone through a project feasibility study, received Bank approval, has user requirement definitions, has adequate system controls and security, and has product testing and implementation; and
there is proof that the application to be purchased from the vendor can meet the Bank's needs (Proof of Concept/PoC). Several approaches that can be used for the purpose of concept proof include:
a) concepts from vendors that have been built in prototype form have passed the testing stage by a small group of operational users covering several types of roles (business role); b) concept proof can be done technically on all aspects of technology involved in the application (steel thread); c) proof of technology can be done to ensure that the technology to be adopted can overcome existing technical problems. For example, the technology in question can integrate two different systems or can achieve certain performance with the established configuration. The proof of technology process does not need to involve operational users; and d) implementation in a smaller scope can be preceded by a pilot project with a more limited final target. Scope limitation can be done by limiting the number of users who can access the system, the number of business processes, organizational components and stakeholders involved, or other limitations deemed appropriate. The purpose of this pilot project is to test system performance as expected by limiting the risk of loss to the Bank if there is a system failure.

b. Project Management and Change Management in IT Development In carrying out IT development, the Bank needs to carry out project management by paying attention to, among others:

The Bank ensures the adequacy of resources to achieve project goals, paying attention to timeliness, cost suitability, and quality;
The Bank must ensure the adequacy of training and clarity of system usage instructions prepared;
The Bank ensures that all deliverables at each stage of project management must be well documented; and
The Bank must have project charter documentation, which contains at least:
a) project information, including code, sponsor, and project manager; b) project goals, background information, and development strategy; c) description of tasks and main responsibilities of each party in project management; d) success criteria for each development stage; e) identification of project risks; f) mechanism for monitoring project achievement; g) project schedule; and h) budget estimate. In the event of changes that have a significant impact on the implementation of the project, the Bank must review the project planning.

Operation
The main activity in operation is to run IT services stably, securely, and sustainably. The Bank needs to apply adequate controls over IT operations so that the Bank can minimize the risk of disruption to the confidentiality, integrity, and availability of information.

a. Data Center and Disaster Recovery Center
IT operations in the provision of Data Centers (DC) and Disaster Recovery Centers (DRC) must be able to guarantee the continuity of the Bank's business.

Data Center Operational Activities
Policies, standards, procedures, and systems applied in Data Center operational activities cover routine and non-routine activities. Activities related to Data Center operations include:
a) task scheduling (shifting); b) execution of routine tasks according to authority; c) backup processes (backup) both onsite and offsite, restore, download, and upload for databases; and d) monitoring of hardware and software.
Physical Access Control of Data Centers
Physical access controls to Data Centers include:
a) Data Center doors must always be locked and equipped with access cards and/or biometric devices; b) Data Center rooms must not be labeled or have signage boards so that people cannot easily recognize them; and c) The Bank must have a log-book to record guests entering the Data Center.
Data Center Environmental Controls
Data Center environmental controls include:
a) supervision and monitoring of environmental factors and Data Center facilities, including power sources, fire, water, temperature, and air humidity. Environmental controls that can be applied include the use of Uninterruptible Power Supply (UPS), raised floors, temperature and humidity control using Air Conditioners (AC), thermometers and hygrometers, smoke and/or fire detectors, fire extinguishing systems, and Closed-Circuit Television (CCTV) cameras; b) availability of sufficient, stable power sources, and alternative power sources to anticipate the unavailability of power from the main power source. To anticipate sudden power outages, the Bank needs to ensure that voltage regulators, UPS, and electric generators can work properly when needed. The Bank must also use automatic switching methods if there is a disturbance in one of the power sources to maintain power supply according to equipment needs; c) ensuring the Data Center has fire and smoke detectors and water drainage pipes. The Bank must also provide adequate fire extinguishing systems, both those that can operate automatically and those operated manually. Fire extinguishing agents and systems used must pay attention to safety for equipment and personnel executing tasks inside the Data Center; d) using raised floors to secure cabling systems and avoid grounding effects in the Data Center; and e) inventorying Data Center support devices.

b. Hardware and Software Configuration Management Policy The Bank must establish procedures regarding:

the installation process of hardware and software;
parameter settings (hardening) of hardware and software; and
inventorying and storing information on hardware, software, network infrastructure, storage media, and other support devices present in the Data Center. The inventory includes:
a) Hardware
Hardware inventory must be done comprehensively, including inventory of third-party hardware located at the Bank. Important information that must be covered in hardware inventory includes vendor name, model, purchase date, installation date, processor capacity, main memory, storage capacity, operating system, function, and location. b) Software The Bank must inventory information regarding the name and type of software such as operating systems, application systems, or utility systems. Other information that must be covered in software inventory includes vendor name, installation date, version and release number, software owner, active parameter settings and services, number of licenses owned, number of installed software, and number of users. c) Network Infrastructure The Bank must document information related to the configuration of each network infrastructure comprehensively. The scope of information in network configuration documentation includes:
(1) diagrams and configuration of network devices and network security devices; (2) list of Bank's internal and external connections; (3) list and specifications of network equipment such as switches, routers, hubs, gateways, and firewalls; and (4) list of telecommunications vendors. d) Storage Media Information required in storage media inventory includes type and capacity, storage location both onsite and offsite, type and classification of data stored, as well as frequency and retention period of backups.

c. Hardware and Software Maintenance Policy
Periodic preventive maintenance of IT equipment is carried out to minimize IT equipment operational failures and detect potential problems early.
The Bank must establish maintenance methodologies appropriate to the characteristics and risks of the existing systems.
Maintenance is implemented as a guarantee for users to continue running systems according to current needs. Maintenance stages pay attention to aspects including:

IT System Changes
In the event of mergers, consolidations, takeovers, integrations, and conversions of Banks requiring the integration of systems used by Banks involved in mergers, consolidations, takeovers, integrations, and conversions, an IT system change process is required. In this process, modifications or major changes to existing systems are carried out and new system development if necessary. Structured processes such as project management and system development cycles must still be applied. Given the complexity of systems in each Bank involved in mergers, consolidations, takeovers, integrations, and conversions, a comprehensive analysis of the impact of changes on Bank operations, especially transaction processing, is required. To ensure the change process runs effectively, the Bank needs to anticipate increased demand for balancing, reconciliation, exception handling, user and customer support, problem resolution, network connectivity, and administrative systems.
Documentation Maintenance
Documentation standards must identify main documents and detailed documents that have been approved and are in the required format. The documentation must contain all changes that have occurred in the system, whether from software, hardware, and network, as well as configurations according to established standards. System-related documentation can only be accessed by Bank personnel who are authorized and/or have the authority to administer the documentation. The Bank must have special storage locations for documentation, both hardcopy and softcopy, including locations to be used for emergency conditions.

d. Change Management Policy
Change management is a procedure that regulates the addition, replacement, or deletion of objects in the operational environment. The objects in question can be data, programs, menus, applications, computer devices, network devices, and processes. The Bank must have change management policies, standards, and procedures that cover at least requests, analysis, change approval, and change installation, including the transfer of hardware and software from the testing environment to the operational environment. The change management process consists of at least:

review before modification and authorization;
testing before modification in a separate testing environment;
data and source code backup procedures before modification; and
necessary documentation, including:
a) explanation of the modification; b) date and time the modification was carried out; c) identification of systems, databases, and work units affected; d) resource requirements; e) consideration of potential security and reliability of system modifications; f) implementation procedures; and g) evaluation after modification. Change management must pay attention to:
Change Control
Interdependence between applications used in various work units requires integrated IT management. Therefore, all changes must go through the supervision function in coordinated change management involving representatives from business work units, IT organizing units, information security, and internal audit. Change installation procedures must pay attention to operational continuity in the operational environment, supervision, and information system security arrangements. Minimum standards regulated must include risk, testing, authorization and approval, implementation time, validation after installation, and back-out or recovery.
Patch Management
In change management, the Bank must have complete documentation about the installation of patches carried out. In addition, the Bank must ensure that the Bank uses tested software versions. The Bank must also have up-to-date information regarding product fixes, security issues, patches or upgrades, or other issues relevant to the software version used.
Data Migration
Data migration occurs if there are major changes in application systems or if data is merged from several different systems. In the event of data migration, the Bank needs to have policies, standards, and procedures regarding data migration handling. Stages to be undergone in carrying out data migration start from strategic planning, project management, change management, testing, contingency plans, backup, vendor management, and post-implementation review.

e. Incident or Problem Handling Policy
Good incident or problem handling procedures are needed by the Bank to face financial, operational, and reputational risks arising from problems.
Incident or problem handling procedures must cover all IT infrastructure including hardware, operating systems, application systems, network devices, and security devices. Incident or problem handling procedures pay attention to the criticality and urgency of the incident or problem. The Bank must maintain the facilities needed to handle problems including:

Helpdesk Management
The Bank must have a helpdesk function so that the Bank can respond to and handle problems faced by all users in the Bank immediately.
Things to pay attention to in the helpdesk function include:
a) availability of complete problem documentation, including user data, problem explanation, impact on the system, priority scale, current resolution status, party responsible for resolution, root cause if identified, resolution time target, and comment field to record user contacts and other relevant information; and b) availability of a helpdesk system that can help helpdesk staff with alternative solutions for common problems, which are updated periodically.
Privilege Access Management
Privilege access is an account or user that has special access rights to systems and networks for the purpose of handling incidents or problems. The Bank establishes privilege access management procedures so that its use is not abused. The procedures include:
a) determination of parties having privilege access rights including the application of dual custody (splitting passwords among more than 1 (one) person); b) privilege access password storage procedures; c) privilege access ID break procedures in emergency situations; d) privilege access password replacement procedures after use; and e) documentation of privilege access usage in the form of minutes or other forms.

f. Database Management
Failure to manage and secure databases can result in changes, destruction, or disclosure of sensitive information by users intentionally or unintentionally or by unauthorized parties. Unauthorized disclosure of confidential information can result in reputational, legal, and operational risks and can cause financial losses. The Bank needs to have a sensitivity classification for information stored in databases as a basis for applying appropriate security. Databases storing confidential information require stricter controls compared to databases storing non-sensitive information. Therefore, the Bank has a Database Administrator (DBA) function responsible for managing the Bank's databases. Procedures owned by the Bank related to databases include access, maintenance, problem handling, and database administration.

g. Information Exchange Control
Sending information online or via storage media (such as tapes and disks) must be adequately managed by the Bank to prevent risks related to information security. The Bank must have procedures for managing the transmission of information physically and logically, including:

requests and provision of information by internal and external parties; and
sending information through various media, such as hardcopy, tape, disk, email, post, and internet.
The Bank must consider the separation of Wide Area Network (WAN) and Local Area Network (LAN) segments with security devices such as firewalls that limit access and the flow of incoming and outgoing data, according to the Bank's IT complexity.

h. Repository Management
Repository managers are responsible for inventorying and storing information related to all IT assets, software, and data stored in various media. Repository managers ensure that IT information and assets are documented and can be accessed correctly to support IT service processes. In addition, repository managers also store copies of all policies and procedures such as run book manuals related to Data Centers. The procedures that must be established include:

securing access to data in the repository;
handling storage media (for databases and audit journals);
retention period of storage media;
testing of storage media; and
entry and exit of storage media from and to the repository.
In making policies, standards, and procedures for repository management, the Bank must pay attention to the adequacy of storage, backup, and disposal procedures for media. Backups of data and programs must always be updated so that the Bank can ensure its ability to restore systems, applications, and data in the event of disasters or other disturbances.

i. Disposal of Hardware and Software
Every IT asset that is no longer used in operational activities and based on Bank considerations is believed to no longer be needed and will no longer be maintained will enter the disposal stage. This is done to ensure the use of the most accurate and up-to-date IT system assets used in operational activities and to avoid misuse by unauthorized parties. Disposal includes the deletion of software, hardware, and data that are no longer used or whose retention period has expired. For example, for software handling, old source code versions that are no longer used must be stored with clear information regarding date, time, and other information when replaced with the latest source code version. Things to pay attention to at the disposal stage:

retention period of data or end of life of IT assets;
ensuring all sensitive data has been deleted/destroyed, according to the retention period;
adjusting or deleting access/configurations of unused IT assets;
documenting information on the transfer of IT assets to be disposed of;
applying disposal methods appropriate to the classification of IT assets, such as degaussing or shredding; and
adequate approval to carry out disposal.

Monitoring
The main activity in monitoring is to measure, evaluate, and ensure that IT runs according to goals, policies, and regulations. Including identifying things that can be improved and developed in the context of IT management.

CHAPTER III
BANK IT ARCHITECTURE
A. IT Architecture
IT architecture is a strategic documentation of the Bank's IT resources that are organized and integrated to achieve and support the Bank's business goals. IT architecture covers IT resources in the form of data, applications, and technologies used by the Bank to support its business. IT architecture is a living document that can be adjusted according to the Bank's business needs and developments.

Consideration Factors in Preparing IT Architecture
As regulated in Article 11 paragraph (2) of POJK on IT, the preparation of IT architecture needs to consider at least the following factors:
a. Bank's Vision and Mission
The Bank's vision and mission describe the goals the Bank wants to achieve in the long term as well as the steps and/or efforts needed to achieve those goals. IT development must align with the Bank's vision and mission so that it can support the Bank's business and operations well. b. Bank's Corporate Plan The Bank's corporate plan is a comprehensive 5 (five) year long-term strategic plan, containing the formulation of directions to achieve the Bank's goals.
c. Bank's Business Processes and Capabilities
Business processes are a series of interrelated activities that generate value in order to achieve business goals. Meanwhile, business capabilities are the abilities that need to be possessed to carry out business processes to achieve business goals. d. IT Governance IT governance is IT governance as stated in Chapter II Bank IT Governance. e. Principles of Bank Data, Application, and Technology Management The principles of Bank data, application, and technology management are general guidelines underlying the use and application of all IT resources and assets at the Bank. f. Size and Complexity of Bank's Business The preparation of IT architecture needs to be adjusted to the size and complexity of the Bank's business. Banks with high business complexity require more detailed IT architecture so that the Bank can manage the IT complexity it owns well. g. Bank's Capital Adequacy The Bank's capital adequacy becomes a consideration in the process of allocating IT costs in the form of investment costs or operational costs. h. Standards Applicable at the National or International Level Practices or standards applicable at the national or international level become considerations in the preparation of IT architecture.
i. Provisions of Legislation
The preparation of IT architecture is carried out in accordance with the provisions of legislation.

In addition to the aforementioned factors, the Bank may consider other factors in accordance with the Bank's business characteristics.

IT Architecture Development
As regulated in Article 11 paragraph (3) of the POJK on IT, the process of developing the Bank's IT architecture includes the stages of planning, design, implementation, and control. In developing IT architecture, the Bank must have policies and procedures for IT architecture development. The IT architecture developed describes the current state and the future state that the Bank aims to achieve. Furthermore, the Bank needs to define IT architecture periodically and whenever necessary.

a. Planning Stage
In the planning stage, the Bank determines architectural principles and establishes roles and responsibilities.
The determination of architectural principles aims to ensure alignment in the direction of IT development policies across every unit or function in the Bank. Furthermore, the Bank must also ensure that there is a party responsible for the development of the Bank's IT architecture.

Determination of Architectural Principles
Architectural Principles define the rules and general guidelines underlying the use and application of all IT resources and assets in the Bank. These principles reflect a level of understanding among work units and provide a basis for decision-making related to IT. Thus, the Bank's IT development policy remains in line with the Bank's business objectives.

Some principles that can be referenced in architecture development include:

No.	Principle	Explanation
1.	Information Management is Everyone's Responsibility	Every business unit participates in decision-making related to information management required to achieve business objectives.
2.	Business Continuity	Bank operations must continue to run under system disturbance conditions.
3.	Applications for Shared Use	Development of applications that can be used jointly across all business units in the Bank is prioritized over the development of other similar or duplicate applications used only by specific business units.
4.	Compliance with Applicable Laws and Regulations	The Bank's information management process must comply with relevant laws and regulations.
5.	Data is an Asset	Data is a valuable asset for the Bank, so it needs to be managed well.
6.	Data Accessibility	Data can be accessed by users to perform functions according to their authority.
7.	Data Security	Data is protected from unauthorized use, modification, and disclosure.
8.	Change Based on Needs	Changes to applications and technology are only made in response to business needs.
9.	Interoperability	Owned software and hardware must meet standards that prioritize data, application, and technology interoperability.

In accordance with business needs and complexity, the Bank may adjust the architectural principles as above. The Bank needs to supplement the referenced principles with further explanations, considerations for the principles, implications of implementation, and examples of principle implementation, in accordance with the Bank's characteristics.

Establishment of Roles and Responsibilities
The Bank establishes the unit or function responsible for the development of IT architecture. This unit or function coordinates with relevant work units in the development of IT architecture to ensure alignment with business objectives.

The unit or function responsible for the development of IT architecture has main tasks, including:
a) being responsible for designing IT architecture to achieve business objectives and the Bank's strategic plan; b) ensuring that IT architecture can provide a complete picture of the Bank's current IT condition and the desired condition to support integrated Bank unit operations; c) communicating IT architecture in achieving business objectives to Bank management; d) reviewing existing infrastructure and IT activities and collaborating with relevant units to determine the capabilities required by the IT system to provide new products or services; and e) collaborating with relevant units to evaluate the implications of strategic planning, including significant changes in IT architecture on the Bank's technology landscape.

b. Design Stage
In the design or planning stage, the Bank designs IT architecture, which includes data architecture, application architecture, and technology architecture. IT architecture is designed to meet the Bank's business needs; therefore, the Bank must first have a comprehensive overview of the Bank's business as a whole.

Bank Business Needs
Some techniques that can be used to break down the Bank's business to obtain a comprehensive overview include:
a) Business capability mapping, which involves identifying, categorizing, and breaking down business capabilities required so that business units or functions have the ability to provide value to stakeholders; b) Organization mapping, which involves creating a representation of the business organizational structure (including third parties), describing business units along with units/functions below them and relationships within the organization (inter-unit and mapping to business capabilities, location, and other attributes); and c) Process modeling, which involves breaking down a business function to identify process elements such as activities, roles, inputs, outputs, and more detailed or specific business functions.
Data Architecture
Data architecture defines the structure and interaction of the Bank's main data types and sources, which includes logical data assets, physical data assets, and data management resources required to support business needs. The development of data architecture will produce, among others:
a) a list of data types owned and data storage facilities; b) a correlation matrix of data types with business functions in the Bank; and c) a correlation matrix of data types with related applications.
Application Architecture
Application architecture defines the structure and interaction of applications as a set of business capabilities that support main business functions and process data. The development of application architecture will produce, among others:
a) a list of owned applications; b) a correlation matrix of applications with business functions in the Bank; c) a correlation matrix of applications with work units in the Bank; and d) an inter-application interaction matrix.
Technology Architecture
Technology architecture defines the structure and interaction of technology services and technology components used to support applications, data, and the Bank's business needs. Technology services are IT services or capabilities supported by technology, such as network connectivity and storage and backup services. Technology components are IT assets that support technology services, including networks, middleware, and databases. The development of technology architecture will produce, among others:
a) a list of technologies used by the Bank, including hardware and software; b) an application-to-technology mapping matrix; and c) a network and communication diagram describing connections between the Bank's IT assets.

Furthermore, the Bank establishes an IT development plan in accordance with data architecture, application architecture, and technology architecture. This includes:

creating a roadmap, including implementation and migration plans;
establishing success evaluation mechanisms; and
estimating resource needs and completion timeframes.

c. Implementation Stage
In the implementation stage, the Bank implements the established IT development plan and ensures that each stage aligns with the developed IT architecture.

d. Control Stage
In the control stage, the Bank evaluates the alignment of IT development with the IT architecture roadmap periodically. Furthermore, the Bank needs to review the relevance of the existing IT architecture to the Bank's business conditions and developments periodically, especially in the event of changes to consideration factors as referred to in item A.1.

B. Strategic IT Plan

Development of Strategic IT Plan
As regulated in Article 12 of the POJK on IT, Banks are required to have a Strategic IT Plan (RSTI). The RSTI is developed to support the Bank's corporate plan. The RSTI is developed for the implementation of IT in the long term according to the Bank's corporate plan period.

Example:
Bank "AS" has a corporate plan with a 5 (five) year period, starting from 2026 to 2030, so the RSTI developed by Bank "AS" must also correspond to that period, i.e., the RSTI from 2026 to 2030. The RSTI is formulated in a document describing the Bank's IT vision and mission, supporting strategies, and main principles that serve as references in the use of IT. The development process is carried out by the IT work unit, the IT user work unit, and the IT steering committee.

a. The RSTI document contains at least:

the Bank's IT vision and mission, clearly describing alignment with the Bank's vision and mission;
targets for the Bank's business development;
identification of the Bank's current IT resource capabilities;
IT planning to support the achievement of the Bank's business development targets, including cost estimates required;
gap analysis between the IT resource capabilities currently available and those required to support the Bank's business development targets; and
IT strategy to achieve the required IT resource capabilities, elaborated through a roadmap.

b. In developing the RSTI, the Bank considers among others:

alignment with the overall strategic plan of the Bank;
alignment with the strategies and activities of each business unit, market conditions, demographic structure, and customer segmentation;
management's understanding of the role of IT in supporting the execution of the Bank's existing and planned business activities;
management's understanding of the relationship between IT resources currently used and planned with the strategies and work plans of IT user work units;
analysis of direct and indirect benefits to be obtained compared to the costs to be incurred for technology usage;
the need for new investment in the field of technology;
human resource needs plan;
alignment with applicable legislation; and
technological developments.

Changes to Strategic IT Plan
In the event of conditions that significantly affect the objectives and strategies of the Bank's IT as contained in the currently running RSTI, the Bank may make changes to the RSTI. Significant conditions include among others:
a. changes in the corporate plan, such as mergers, consolidations, takeovers, and conversions, or changes in the Bank's business model to a digital bank; and b. changes in applicable legislation that affect the implementation of IT in the Bank, such as prohibitions on implementing new technologies that may endanger customer data security. In making changes to the RSTI, the Bank continues to consider the items in the development of the RSTI as stated in item B.1.

CHAPTER IV
IMPLEMENTATION OF IT MANAGEMENT RISK IN BANK IT IMPLEMENTATION A. IT Risk Management Process To implement Article 15 of the POJK on IT, Banks implement effective risk management in IT implementation. The scope of effective risk management implementation is carried out in accordance with Financial Services Authority Regulations regarding the implementation of risk management for commercial banks or Financial Services Authority Regulations regarding the implementation of risk management for Sharia commercial banks and Sharia business units. Risk management applies to all IT implementation, including cyber security, data management, use of Third-Party IT Service Providers (PPJTI), and general IT usage.

Risk management implementation is integrated into every stage of IT implementation, including the planning, development, operation, maintenance, cessation, and deletion of IT resources stages. IT resources include among others hardware, software, networks, human resources, data, and information.

The Bank is required to ensure the adequacy of the risk management information system in IT implementation. The aforementioned information management system must be able to produce complete and accurate reports to detect and correct deviations in a timely manner. Furthermore, the Bank also needs to have a reporting mechanism that can provide information as needed.

In implementing IT risk management, the Bank carries out the following process:

Risk Identification
In conducting IT risk identification and assessment, the Board of Directors must ensure risk awareness across all levels of the Bank, namely:
a. risk awareness from the Board of Directors and officials at all levels of position; b. clear understanding of the Bank's risk appetite;
c. understanding of applicable legislation and standards related to IT; and
d. transparency and integration of responsibilities regarding significant risks from every aspect related to IT implementation.
To ensure the above, the Bank can run a risk awareness program for all employees and Bank management or run other methods that can increase users' awareness of existing risks.

IT risk identification can also be done through the collection of data or documents on IT-related activities that have the potential to cause or increase risks, from ongoing or upcoming activities, including among others:
a. critical IT assets, in order to identify access points and deviations regarding confidential customer information; b. results of the strategic plan review of the Bank;
c. results of due diligence and monitoring of PPJTI performance;
d. results of reviews of reports or complaints submitted by customers and/or IT users to the call center and/or helpdesk; e. results of self-assessments conducted by all work units regarding controls implemented related to IT; f. audit findings related to IT implementation; and g. evaluation of the use of new technology and changes in the Bank's business model.

Risk Measurement
The Bank needs to pay attention to the significance of the impact of identified risks on the Bank's condition and the frequency of risk occurrence. The methods used by the Bank can be quantitative or qualitative methods depending on the complexity of the business and IT used. In qualitative methods, the magnitude of impact and likelihood of risk occurrence can be described narratively or by giving ratings.

Example of a simple qualitative measurement method includes the use of checklists or subjective risk ratings such as high, medium, or low.

For identified and assessed or measured risks to be monitored by management, the Bank needs to have risk documentation, often referred to as a risk register.

Examples of creating a risk register include:
a. setting assets, processes, products, or events containing risks; b. measuring or rating the likelihood of occurrence and impact (inherent risk assessment);
c. steps for handling potential risks (potential risk treatment), such as Accept, Control, Avoid, or Transfer (ACAT).

In documenting the handling of potential risks, the Bank needs to consider among others risk appetite, facilities that can be used as preventive or corrective controls, and the alignment of the risk mitigation plan with the Bank's financial conditions. Documentation of potential risk handling needs to be defined periodically.

Potential risk handling that the Bank can take is as follows:

Accept
The Bank decides to accept the risk if the magnitude of impact and tendency level are still within the organization's tolerance limits.

Example:
a) Setting risk acceptance criteria related to risk evaluation and handling, for example, the final risk value is "low". b) Setting the final risk value as "medium" or "high", but it has been decided to be accepted by the Bank and a system procedure is created to monitor the risk.

Control
The organization decides to reduce the impact or likelihood of risk occurrence.

Example: installing a firewall on Personal Computers (PC) to prevent unauthorized access.

Avoid
The organization decides not to perform an activity or chooses an alternative activity that produces the same output to avoid the occurrence of risk.

Example: Users are not given administrator privilege rights to avoid IT risks such as malicious code on PCs resulting from configuration changes and software installation on PCs performed by users.

Transfer
The organization decides to transfer all or part of the responsibility for implementing a process to a third party.

Example:
Insuring room or building facilities containing the risk of fire occurrence; and d. measuring or rating the likelihood of occurrence and impact after ACAT (residual risk assessment).

Risk Monitoring
The Bank monitors IT risk by evaluating the alignment, adequacy, and effectiveness of IT implementation performance.

a. Items that can be covered in the evaluation include among others:

audit results and related studies;
received feedback;
policies, standards, procedures, and their implementation;
status of preventive and corrective actions related to risks faced by the Bank;
weaknesses and threats, both existing and potential;
measurement results of IT implementation effectiveness;
follow-up on previous evaluation results;
changing conditions affecting IT implementation; and
recommendations for improvement or refinement.

b. Follow-up on evaluation results can be formulated in the form of decisions or actions to improve IT implementation effectiveness, including among others:

defining risk profiles, measuring risks, and risk handling plans;
refining policies, standards, and procedures in the field of IT;
fulfilling human resource needs;
establishing and implementing preventive and corrective actions based on assessments of existing or potential non-conformities, considering priority scales; and
monitoring and evaluating the implementation of preventive and corrective actions.

c. The results of evaluations and follow-up as referred to in letter b must be adequately documented.

Risk Control
The Bank must apply adequate risk controls as part of the overall IT risk mitigation strategy by considering at least:
a. risk assessment results; b. risk handling criteria and recommendations for risk handling forms;
c. applicable legislation and requirements in agreements;
d. control practices including among others:

implementation of policies, standards, and procedures, and organizational structure including workflows;
effective internal controls that can mitigate risks in the IT process. The scope and quality of internal controls are the main keys in the risk management process, so the Bank must identify specific internal control requirements needed in each policy and procedure implemented;
establishment of policies, standards, and procedures for the Bank's information security management system required to secure assets related to IT implementation, including data or information;
evaluation of review and test results for the Disaster Recovery Plan (DRP);
establishment of policies and procedures regarding the use of PPJTI. The Board of Directors must have a comprehensive understanding of risks related to the use of PPJTI services for IT operations;
evaluation of information security performed by PPJTI regarding data confidentiality, integrity, and information availability;
the use of insurance as an effort to complement the mitigation of potential losses in IT implementation. Risks to be insured are residual risks. The Bank must periodically review the needs, scope, and value of insurance coverage; and
supervising and monitoring PPJTI, given that IT operations carried out by PPJTI remain the responsibility of the Bank.

B. Information Security in Bank IT Implementation Information is a very important asset for the Bank, including information related to customers, the Bank's finances, and reports prepared by the Bank. Leaks, damage, inaccuracy, unavailability, or other disturbances to such information can cause adverse effects, both financial and non-financial, to the Bank. The aforementioned impact is not limited to the Bank but also extends to customers. Given the importance of information, information must be protected or secured by all Bank personnel. Information security not only covers security regarding all aspects and components of related IT such as software, hardware, networks, supporting equipment (such as power resources and cooling systems) and human resources (such as qualifications and skills), but also information security in a broader form.

Information Security
Effective and efficient information security implementation must consider at least:
a. information security aimed at ensuring the confidentiality, integrity, and availability of managed information while considering compliance with regulations; b. information security conducted regarding technology, human resources, processes, physical, and environmental aspects in the implementation of IT; and
c. information security applied based on the results of risk assessments on information owned, managed, and processed by the Bank.

The Bank also implements comprehensive and continuous information security by establishing policies, standards, and procedures related to information security, implementing information security controls, monitoring and evaluating the performance and effectiveness of information security policies, and conducting improvements.

In addition, the Bank needs to consider the implementation of standards and/or best practices nationally and internationally in the field of information security, considering the objectives, business policies, size, and complexity of the Bank's business, which includes diversity in transaction types, products, office networks, and supporting technologies used.

a. Information Security Policy
The Bank must establish a policy and have a high commitment to information security. The policy must be in accordance with the Bank's risk appetite and communicated regularly to all Bank personnel and relevant external parties. In addition, the policy needs to be evaluated regularly and whenever there are significant changes.

The information security policy covers at least:

information security objectives containing at least asset management, human resources, physical security, logical security, IT operational security, information security incident handling, and information security in system development;
the Bank's commitment to information security in line with strategy and business objectives;
the framework for establishing controls through the implementation of the Bank's risk management;
compliance with internal regulations and statutory regulations;
training and increasing awareness of the importance of information security (security awareness program);
duties and responsibilities of parties in information security;
sanctions for violations of the information security policy; and
documents or other regulations supporting the information security policy.

b. Information Security Standards
The Bank must establish information security standards in accordance with the information security policy, including by referring to statutory regulations and standards and/or best practices.

Information security standards are the basis for implementing and assessing compliance with information security regulations and a reference for drafting information security procedures.

Examples of information security standards:

password standards;
encryption standards;
server security standards;
network device security standards;
end-point or computer security standards;
logging standards; and
application security standards.

c. Information Security Procedures
The Bank must have information security procedures consisting of:

IT Asset Management Procedure
The IT asset management procedure contains at least:
a) IT assets can be in the form of data (hardcopy or softcopy), software, hardware, networks, and supporting devices, such as power resources and cooling systems, as well as human resources including qualifications and skills; b) IT assets are identified, owners or persons in charge are determined, and recorded so that they can be protected appropriately; c) the regulation of the use of information and IT assets, such as the regulation of the use of email, internet, mobile devices, and teleworking, must be identified, documented, and implemented. All Bank personnel and third parties must comply with these regulations; and d) information needs to be classified so that appropriate security can be implemented according to its classification. Classification can be made based on value, level of confidentiality, law or regulations, and level of importance to the Bank. Examples of such classifications:
(1) "confidential" information (e.g., customer deposit data and customer personal data), "internal" (e.g., regulations regarding Bank employee salaries); and (2) "public" information (e.g., information about banking products offered to the public).
Human Resources Management Procedure
The human resources management procedure contains at least:
a) The Bank must implement adequate controls before employing IT employees (permanent, contract, or casual), consultants, including Third-Party IT Service Providers (PPJTI) in positions that have significant vulnerability or impact on information security. For example, conducting background checks on criminal records or other crimes such as data theft during recruitment for positions such as network administrator or system administrator; b) Human resources (Bank employees, consultants, casual employees, and PPJTI employees) who have access to information must understand their responsibilities regarding information security; c) the roles and responsibilities of human resources (Bank employees, consultants, casual employees, and PPJTI employees) who have access to information must be defined and based on the level of need for information access and documented in accordance with the information security policy; d) employment agreements with Bank employees (permanent and non-permanent employees) must contain provisions regarding information security in accordance with the Bank's information security policy. For example, there needs to be a clause stating that Bank employees (permanent and non-permanent employees) must maintain the confidentiality of information they obtain according to information classification; e) in the event the Bank cooperates with PPJTI (including consultants), the cooperation agreement between the Bank and PPJTI must contain provisions regarding information security, such as information confidentiality clauses (non-disclosure agreement). In addition, all employees assigned to PPJTI at the Bank must sign an information confidentiality agreement if the relevant party has access to Bank data; f) training and/or socialization about information security must be provided to Bank employees, consultants, casual employees, and PPJTI employees. This training and/or socialization is provided according to the roles and responsibilities of employees and PPJTI; g) The Bank must establish sanctions for violations committed by human resources against the information security policy; and h) The Bank must establish procedures regulating the requirement to return assets and change or close access rights of Bank employees, consultants, casual employees, and PPJTI employees caused by changes in duties or the completion of employment or agreements.
Physical and Environmental Security Procedure
The physical and environmental security procedure contains at least:
a) important information processing facilities (e.g., mainframes, servers, computers, and active network devices) must be provided with adequate physical and environmental security to prevent access by unauthorized parties, damage, and other disruptions; b) physical and environmental security for important information processing facilities includes among others room barriers, entry access control (e.g., use of access control cards, Personal Identification Number (PIN), and biometrics), completeness of security equipment inside the room, such as alarms, fire detectors and extinguishers, temperature and humidity sensors, and CCTV cameras, as well as maintenance of room and equipment cleanliness, such as from dust, cigarettes, food, drinks, and flammable items; c) supporting facilities such as cooling systems, power resources, and fire alarms must ensure capacity and availability to support the operation of information processing facilities; d) PPJTI-owned assets such as servers and switching tools must be clearly identified and given adequate protection, for example by applying sufficient security, dual control, or placing them separately from Bank assets; and e) regular maintenance and inspection of information processing facilities and supporting facilities according to established procedures.
Access Control Procedure
The access control procedure contains at least:
a) physical and logical access control; b) The Bank must implement identification and authentication methods according to risk analysis. Authentication methods used can be one or a combination of:
(1) "what you know" (among others PIN and password); (2) "what you have" (among others mobile phones, magnetic cards with chips, and tokens); and (3) "something you are" (among others biometrics such as retina and fingerprints); c) The Bank must have a formal written procedure approved by management regarding user administration, including registration, modification, and deletion of users, both for internal and external Bank users, such as vendors or PPJTI; d) access provision refers to the principle of business need and with minimal access; e) The Bank must establish control procedures through the provision of initial passwords or PINs to users, considering among others:
(1) initial passwords or PINs must be changed upon first login; (2) passwords or PINs are provided securely, for example, through double-layered carbon paper so that they are only known by authorized parties; (3) initial passwords or PINs are unique (unique) for each user and not easily guessed; (4) user-id account owners, especially Bank employees, casual employees, and PPJTI employees, must sign a statement of responsibility or user-id and password or PIN usage agreement when receiving user-id accounts and initial passwords or PINs; and (5) default passwords or PINs owned by operating systems, application systems, database management systems, as well as network and security devices must be changed by the Bank before implementation and replacing default user-id accounts; f) The Bank must require users to:
(1) maintain the confidentiality of passwords or PINs; (2) avoid writing passwords or PINs on paper and other places without adequate security; (3) choose quality passwords or PINs, namely:
(a) adequate password or PIN length so that it is not easily guessed; (b) easy to remember and consisting of at least a combination of 2 (two) character types (letters, numbers, or special characters); (c) not based on user personal data such as name, phone number, or date of birth; and (d) not using common words and easily guessed by software (to avoid brute force attacks); (4) change passwords or PINs regularly; and (5) avoid using the same password or PIN repeatedly; g) The Bank must disable access rights if user-ids are not used for a certain period, set the maximum number of password or PIN failures (failed login attempts), and disable users after reaching the maximum number of password or PIN failures; h) The Bank must conduct periodic reviews by work units not involved in access control operations regarding user access rights to ensure that access rights are in accordance with the authority granted; i) operating systems, application systems, databases, utilities, and other devices owned by the Bank can help implement password or PIN security, for example:
(1) forcing users to change their passwords or PINs after a certain period and rejecting if users enter the same password or PIN used previously when changing passwords or PINs; (2) storing passwords or PINs securely (encrypted); (3) disconnecting or accessing users if there is no response for a certain period (session time-out); and (4) disabling or deleting user access rights if users do not log-on for more than a certain period (expiration interval), for example, due to leave, rotation, and transfer; and j) Banks using file or folder sharing must establish access restrictions at least through the use of passwords or PINs and the regulation of authorized parties to access.
Security Procedures in IT Development and Operations
Security procedures in IT development and operations contain at least:
a) The Bank must also maintain records of the software versions used and routinely monitor information about product enhancements, security issues, patches or upgrades, or other issues relevant to the software versions used; b) The Bank must create procedures that include identifying existing patches, conducting testing, and installing if indeed needed; c) The Bank must establish the type of logs (e.g., administrator logs, user logs, or system logs) and data that must be entered into logs, storage periods considering applicable regulations, to assist in future investigations and monitoring of access controls; d) The Bank must conduct periodic reviews of audit trails or logs based on risk analysis results at the network, operating system, database, and application levels; e) Audit trails or logs must be protected against disruption and unauthorized access; f) Timestamps of all Bank Electronic Systems must be synchronized with an agreed-upon accurate time source; g) The Bank must conduct periodic reviews of IT operational services performed by PPJTI. The review period must be established in the cooperation agreement between the Bank and PPJTI; h) The Bank must implement physical media controls in transit, to protect media against unauthorized access, misuse, or damage during transportation outside the Bank's physical boundaries; and i) The Bank performs secure coding/programming in IT development.
Information Security Monitoring Procedure
The Bank must conduct monitoring to detect attempts threatening information security with methods determined based on risk or the criticality level of the Bank's information or IT assets. Monitoring needs to be done in real-time to provide alerts when activities are considered suspicious, such as brute force attacks against administrator passwords or attempts to access servers on unusual ports, or done periodically, for example, at the end of the day, based on risk levels.
Information Security Incident Handling Procedure
Matters that the Bank must consider in handling IT incidents in information security include among others:
a) The Bank must identify the types of incidents in information security, for example, users can access a system that is not permitted or other known vulnerabilities. b) Bank employees, casual employees, and PPJTI employees report every time they know, find, or see indications or potential incidents in information security according to letter a). c) The Bank needs to consider the formation of a special team to handle security incidents, such as the Information Security Incident Response Team (TRIPI), according to the size and complexity of the Bank's business. d) The Bank must establish several matters regarding the reporting of incidents in information security as follows:
(1) work units or personnel to be contacted if Bank employees, casual employees, or PPJTI know of incidents in information security (Point of Contact/PoC); (2) reporting mechanisms that can be used to report incidents in information security by personnel who know of the occurrence of incidents; (3) verification mechanisms by the PoC to ensure that reports of incidents in information security submitted by the reporter are in accordance with the conditions on the system both before and after the reporter submits evidence of the occurrence of incidents in information security; and (4) assessment mechanisms by the PoC to determine the correspondence of reports with the types of information security incidents submitted by the reporter. In the event that the PoC has determined that the report is classified as an incident in information security, the PoC must immediately submit the report to TRIPI. e) The Bank must establish several matters regarding the handling of incidents in information security as follows:
(1) personnel who are members of TRIPI including their duties and responsibilities; (2) guidelines for conducting assessments on the validity of incident reports including the classification of incidents in information security submitted by the PoC; (3) guidelines for handling incidents in information security to be carried out by TRIPI; (4) verification methods by TRIPI to ensure that reports of incidents in information security submitted by the PoC are correct, including being classified as incidents in information security. In the event that the reported incident in information security is indeed an incident in information security, TRIPI must follow up on the incident in information security according to the guidelines for handling incidents in information security that apply; (5) TRIPI guidelines in handling incidents in information security according to their types, covering steps including among others:
(a) documenting all information regarding incidents in information security; (b) identifying IT systems affected by incidents in information security; (c) isolation of IT systems identified as affected by incidents in information security; (d) collecting all information stored in IT systems identified as affected by incidents in information security. In the event that such information will be used as digital evidence, the collection and preservation of information must be done with forensically sound digital methods; (e) implementing solutions to incidents in information security according to their types, with prior management approval; (f) in the event that TRIPI identifies that the incident in information security cannot be controlled, escalation to management must be done to activate crisis handling procedures; and (g) drafting a complete report on activities handling incidents in information security to be submitted to management both while still in the process of handling and after the solution is implemented and the incident in information security status is closed; (6) improvements to the guidelines for handling incidents in information security using lessons learned from previous activities handling incidents in information security. f) The Bank must maintain complete documentation of an incident in information security. g) The Bank periodically reviews the guidelines for handling incidents in information security to ensure that the guidelines are relevant to the current condition of the Bank's IT systems. h) The Bank may consider providing incentives to Bank employees, casual employees, and PPJTI employees who report incidents or IT vulnerabilities that pose a risk of exploitation and threaten information security, in order to encourage the achievement of strong or adequate information security.

Communication Networks
Communication networks include hardware, software, and transmission media used to transmit information in the form of data, voice, images, and video.
The implementation of communication networks is greatly influenced by IT changes, both systems and infrastructure, and is vulnerable to disruptions and misuse. Therefore, the Bank needs to ensure that network integrity is maintained by implementing policies, standards, and network management procedures well, maximizing network performance, designing networks that are resistant to disruptions, and clearly defining network services and implementing necessary security.

The Bank must have policies, standards, and procedures as guidelines in providing communication networks to ensure that operational continuity and communication network security remain maintained. Communication network policy is the direction and objectives of communication network management to be implemented by the Bank, for example, regarding the application of encryption on communication networks. Communication network standards are a number of parameters established by the Bank to meet communication network policies, for example, the use of Secure Socket Layer (SSL). Communication network procedures are a series of technical steps to be carried out by the Bank to meet communication network standards.

Policies, standards, and procedures that need to be established include at least:
a. performance and capacity planning; b. network security (network access control, including remote access);
c. change management (settings, configuration, and testing);
d. network management, network logging, and network monitoring; e. use of the internet, intranet, e-mail, and wireless (including mechanisms for using communication networks); f. problem handling procedures; g. backup and recovery facilities; and h. agreements and SLAs that are appropriate to the Bank's needs and monitored periodically if the communication network used by the Bank is managed by a Third-Party IT Service Provider (PPJTI).

Disaster Recovery Plan
Banking activities cannot be avoided from disruptions or damage caused by nature and/or humans, such as earthquakes, bombs, fires, floods, power failures, technical errors, human negligence, labor strikes, and riots. The disruptions or damage that occur not only affect the Bank's technological capabilities but also impact the Bank's business operational activities, especially services to customers. If not handled specifically, the Bank will face risks such as operational risk and reputational risk, which impact the level of customer trust in the Bank. To minimize these risks, the Bank must have a Disaster Recovery Plan. The Disaster Recovery Plan emphasizes technological aspects with a focus on data recovery (data recovery or restoration plan) and the functioning of critical IT application and infrastructure systems.

a. Policies, Standards, and Procedures related to the Disaster Recovery Plan Policies, standards, and procedures related to the Disaster Recovery Plan include at least:

Policies related to the Disaster Recovery Plan
The Bank must have policies related to the Disaster Recovery Plan that support the effectiveness of the implementation of the necessary Disaster Recovery Plan, containing at least:
a) Formation of the Disaster Recovery Plan Working Team The Bank needs to form an organization or working team to coordinate the implementation of the Disaster Recovery Plan, consisting of:
(1) a coordinator; and
(2) team members who are responsible for, among others:
(a) business work units; and
(b) IT work units which among others oversee the functions of offsite storage management, applications, hardware, software, network, security, communication, and data preparation and records.

As for the roles of the working team responsible for the Disaster Recovery Plan, at least:
(a) are fully responsible for the effectiveness of the implementation of the Disaster Recovery Plan, including ensuring that awareness programs regarding the Disaster Recovery Plan are applied; (b) decide on disaster conditions and its recovery; (c) determine the recovery scenarios to be used if disruptions or disasters occur based on priority levels of activities, functions, and services considered critical; (d) review reports regarding each stage in the testing and implementation of the Disaster Recovery Plan; and (e) communicate to internal and external parties of the Bank in the event of significant (major) operational disruptions. b) Principles of Drafting the Disaster Recovery Plan In formulating policies, strategies, and procedures to be applied to handle disaster conditions, the Bank must ensure the implementation of the following principles:
(1) The Disaster Recovery Plan is drafted based on adequate business impact analysis and risk assessment; (2) The Disaster Recovery Plan is flexible to respond to various threat scenarios, disruptions, and unexpected disasters originating from internal and/or external conditions; (3) The Disaster Recovery Plan is specific, containing certain conditions and actions required immediately to address those conditions; and (4) The Disaster Recovery Plan clearly states the interdependencies between processes and systems in running critical business processes. c) Business Impact Analysis (Business Impact Analysis) The effectiveness of a Disaster Recovery Plan depends on the Bank's ability to identify the level of criticality of various work processes or activities in the Bank before the Disaster Recovery Plan is drafted or reviewed. Thus, business impact analysis is the basis for formulating the entire Disaster Recovery Plan. Matters that must be analyzed in business impact analysis include:
(1) the criticality level of each business process and interdependencies between business processes as well as the required priority scale; (2) interdependencies between processes and systems in running critical business processes; (3) the level of dependency on service providers, both IT and non-IT; (4) the time period the Bank can operate without systems or facilities experiencing disruptions (Maximum Tolerable Downtime/MTD) and/or the tolerance time period for system or facility recovery until they function again (Recovery Time Objective/RTO), as well as tolerance for data loss and cessation of business processes (Recovery Point Objective/RPO); (5) the minimum number of personnel, data, system completeness, and facilities required for business to operate (minimum resources requirement); (6) potential impacts of non-specific and uncontrollable events on business processes and customer services; (7) the impact of disruptions and/or disasters on all work units and business functions, not just data processing; (8) communication channels needed for the recovery process; and (9) legal impacts and compliance with relevant regulations, such as regulations regarding customer data confidentiality. In conducting business impact analysis, both IT work units and each business unit need to note that the Disaster Recovery Plan to be drafted is not only for total disasters, but also for various disaster and disruption situations ranging from minor, major, to catastrophic. The impacts to be considered are not only those that can be clearly measured (tangible impacts) such as penalties for late interest payments or employee overtime costs, but also those that cannot be clearly measured (intangible impacts) such as difficulties for customers in obtaining services. d) Risk Assessment Risk Assessment, consisting of risk identification and measurement, is the second stage that must be passed in formulating the Disaster Recovery Plan. This process is necessary to determine the likelihood of disruptions in important (critical) Bank activities and their impact on the Bank's business continuity. Risk assessment includes at least:
(1) analyzing the impact of disruptions or disasters on the Bank, customers, and the financial industry; (2) conducting gap analysis by comparing current conditions with steps or scenarios that should be applied; and (3) ranking potential business disruptions based on the level of damage (severity) and likelihood of occurrence (likelihood). e) Formulation of the Disaster Recovery Plan The formulation of the Disaster Recovery Plan is conducted after the business impact analysis and risk assessment processes. The objectives and targets of formulating the Disaster Recovery Plan include:
(1) securing important Bank assets;
(2) minimizing risks due to disasters, for example, by limiting financial losses, legal risks, and reputational risks; (3) ensuring Bank operations continue; (4) ensuring continuous service availability to customers; and (5) preparing alternatives so that critical business functions can continue to maintain Bank operational continuity. The Disaster Recovery Plan consists of necessary policies, strategies, and procedures to ensure business process continuity during disruptions or disasters. The Disaster Recovery Plan must contain several alternative strategies that the Bank can take to address each type and size of disruption or disaster. Recovery strategies are adjusted based on the results of business impact analysis, risk analysis, available resources, and the Bank's technology capacity and level. Each chosen strategy should be accompanied by analysis or reasons for its validity and must be supported by appropriate systems and procedures.
2) Procedures related to the Disaster Recovery Plan
a) Types of Disaster Recovery Plan Procedures
The types of procedures in the Disaster Recovery Plan include:
(1) emergency response procedures (immediate steps) to control crises during disruptions and/or disasters, limit loss impacts, and determine whether or not to declare a disruption and/or disaster; (2) system recovery procedures that allow Bank operational activities to return to normal conditions; and (3) data synchronization procedures used to ensure equality between production machine data and data at the backup site, as well as to ensure all business processing data during the recovery period has entered the system. b) Components of Disaster Recovery Plan Procedures Each Disaster Recovery Plan procedure includes at least the following components:
(1) personnel
The Disaster Recovery Plan must clearly state the composition, authority, and responsibilities of the system recovery implementation team and have an integrated communication flow; and (2) technology procedures drafted must consider the technology components owned by the Bank such as hardware, software, communication facilities, up to equipment for processing operational activities in each business function. Furthermore, the Bank also needs to consider the availability of Disaster Recovery Centers, system documentation, and data backup. c) Disaster Recovery Center The Bank must ensure the availability of a Disaster Recovery Center as a backup for the Data Center that can be operated if the Data Center cannot operate due to disruptions and/or disasters. According to the alternative strategy chosen by the Bank, the Disaster Recovery Center can be managed by the Bank itself or by a PPJTI. In managing the Disaster Recovery Center, the Bank must consider at least:
(1) the Disaster Recovery Center should be located considering different risk exposures of each Data Center and Disaster Recovery Center; (2) the vulnerability conditions of the chosen Disaster Recovery Center location with the possibility of riots and unrest; (3) the Disaster Recovery Center must have electricity supplies and telecommunications facilities that guarantee the operation of the Disaster Recovery Center; (4) systems at the Disaster Recovery Center must be compatible with systems used at the Data Center and must be adjusted if changes occur at the Data Center; (5) the Disaster Recovery Center is a restricted area; and (6) the travel time to ensure the recovery process at the Disaster Recovery Center. d) Backup (Backup) of Documentation, Systems, and Data The Bank must ensure the availability of effective backups of important business information, software, and related system and user documentation for each important (critical) business function process. Matters that must be considered in backup documentation, systems, and data include at least:
(1) the backup must be stored in a location other than the Data Center (off site). Every change and modification must be documented and copies must also be updated; (2) backup media must be stored in a safe environment at the off site location with adequate security system standards; (3) full system backups must be performed periodically. If fundamental system changes occur, full system backups must be performed as soon as possible; (4) all backup media use standard labeling to identify usage, date, and retention schedules; (5) backup media must be tested periodically to ensure they can be used when needed (emergency situations); (6) the Bank must have procedures for the disposal of backup media; and (7) the Bank needs to have documentation including information about backup objects, backup methods, and backup periods. e) Communication Facilities The Bank must ensure that there are communication channels in the Bank's operational area that can be used during disruptions and/or disasters, both within the internal environment and with external parties of the Bank. This includes alternative communication channels in case the main communication channel cannot be used.

b. Testing the Disaster Recovery Plan
Testing the Disaster Recovery Plan is necessary to ensure that the Disaster Recovery Plan can be implemented well during disruptions and/or disasters. Testing is conducted on the Disaster Recovery Plan at least 1 (one) time in 1 (one) year for all critical systems or applications according to the results of business impact analysis and representing all critical infrastructure, involving IT users. If the Bank uses a PPJTI in its operational activities, the testing conducted also needs to involve the external party.

Scope of Disaster Recovery Plan Testing
The Bank must clearly determine the functions, systems, and processes to be tested. Matters to be tested include the effectiveness of:
a) procedures for determining disruption and/or disaster conditions; b) procedures for recovering important (critical) data; and c) the return of Bank operational activities and the Data Center to the original business unit location and Data Center. Testing conducted must be documented systematically and evaluated to ensure the effectiveness and success of the testing. In the event that weaknesses are found during testing, the Disaster Recovery Plan needs to be improved.
Disaster Recovery Plan Testing Scenarios (Test Plan)
The Bank must have testing scenarios for each test to be conducted, and the scenarios must be reviewed for adequacy. The implementation of these scenarios must not disrupt Bank operational activities. Test results are expected to detect weaknesses in existing procedures for the purpose of improving the Disaster Recovery Plan. In this case, the Bank needs to validate assumptions used in the testing scenarios, including:
a) the criticality of business process functions or systems being tested; b) transaction volume; and c) the Disaster Recovery Plan strategy chosen by the Bank.
Analysis and Reporting of Disaster Recovery Plan Testing Results
Test results and analysis of each problem found during testing must be reported to the Board of Directors. Matters reported include:
a) assessment of test objective achievement; b) assessment of the validity of data processing tests; c) corrective actions to address problems that occurred; d) descriptions of gaps between the Disaster Recovery Plan and test results, as well as proposed changes to the Disaster Recovery Plan; and e) recommendations for future testing. In the event that test results fail, the Bank must examine the causes of failure or problems that occurred and conduct retesting.
c. Maintenance of the Disaster Recovery Plan and Internal Audit
Maintenance of the Disaster Recovery Plan
The Bank must ensure that the Disaster Recovery Plan can be used at all times, including by storing copies of the Disaster Recovery Plan documents at an alternate site. The Bank needs to ensure that all parties in the Bank and in the PPJTI understand the importance of the Disaster Recovery Plan and actively participate in the implementation of the Disaster Recovery Plan. Furthermore, each work unit must periodically conduct self-assessments of the adequacy of business impact analysis with changes occurring in operational activities, whether managed by the Bank itself or by a PPJTI. The Bank must conduct reviews of the Disaster Recovery Plan to ensure its suitability with external and internal conditions. In conducting reviews, matters that need to be considered include changes in business processes, systems, software, hardware, operating systems, personnel or key staff, and service providers. These changes must be analyzed for their impact on the existing Disaster Recovery Plan and determine the improvements needed to accommodate these changes in the latest Disaster Recovery Plan. Subsequently, the reviewed Disaster Recovery Plan must be documented and distributed to the IT work unit.
Internal Audit
Internal auditors must conduct examinations of:
a) the adequacy of the Disaster Recovery Plan with the Bank's risk management policies; b) the Disaster Recovery Plan includes critical activities based on business impact analysis conducted by the Bank; c) the adequacy of the Disaster Recovery Plan to control and mitigate risks established in risk assessment; d) the adequacy of Disaster Recovery Plan testing procedures; e) the effectiveness of Disaster Recovery Plan testing implementation; and f) the currency of the Disaster Recovery Plan according to the development of the Bank's operational activities and the results of the last testing. Internal auditors must communicate examination results and provide recommendations to the Board of Directors. The Board of Directors should review the audit report results and plan improvements or corrections. The frequency of audit implementation can be conducted according to the Bank's complexity and needs.

CHAPTER V
USE OF THIRD-PARTY IT SERVICE PROVIDERS IN MANAGING BANK IT A. Introduction The use of PPJTI is the use of services from other parties providing IT solutions such as software, hardware, and/or technical support and consultation in managing Bank IT, and is conducted continuously and/or for a certain period, causing the Bank to have dependencies on the services provided. The use of PPJTI can affect the Bank's risks, including failures by the PPJTI in providing services or the inability to comply with regulatory provisions. Therefore, to mitigate and control risks from the use of PPJTI, the Bank must have the ability to supervise the implementation of Bank activities managed by the PPJTI. Furthermore, the Financial Services Authority has the authority to supervise all IT management activities conducted by the Bank itself or by a PPJTI. Thus, Bank examinations and supervision must not be hindered by the transfer of Bank operational functions to a PPJTI. B. Policies and Procedures Banks using a PPJTI must have policies and procedures in accordance with Article 29 paragraph (3) of the OJK Regulation on IT. Policies and procedures in the use of PPJTI include at least:

Process for Identifying the Need for PPJTI Use
To identify the need for PPJTI use, the Bank first defines business needs regarding the use of PPJTI, including:
a. specific identification of functions or activities whose management will be handed over to the PPJTI; b. risk assessment processes that may arise from handing over the management of functions or activities; and
c. establishing the basis for identifying adequate control measurements.
The results of the above need definition must contain documents containing a detailed description of the Bank's desires regarding services or services to be handled by the PPJTI, consisting of several components as follows:
a. scope and characteristics of services and technology used, as well as support for customers; b. service levels including availability and performance, change management, service quality, security, and business continuity;
c. minimum characteristics that must be met by the PPJTI to be used, such as experience, IT architecture and systems, process controls, financial conditions, and references regarding reputation;
d. monitoring and reporting including criteria to be used in monitoring and reporting for both the Bank and third parties; e. requirements to be met from the system, data, and personnel training sides during transition or migration to systems provided by the PPJTI;

f. duration, termination, and minimum content of the agreement; and g. protection of the agreement against liabilities such as limitation of liability, indemnification, and insurance. The process of identifying IT Service Provider (PPJTI) usage needs is conducted at least with:
a. Examining Potential PPJTI Candidates
In examining potential PPJTI candidates, the Bank conducts among others:

monitoring of potential PPJTI candidates that can provide IT services in accordance with the needs to achieve the Bank's business objectives and IT strategy, on a continuous basis; and
evaluation and comparison of the performance of PPJTI currently used by the Bank with other alternative PPJTI candidates, to identify urgent opportunities or needs in order to reconsider cooperation agreements with the PPJTI currently used by the Bank.
b. Formulating Required PPJTI Criteria
The criteria for required PPJTI can be formulated or established based on the type, significance, and criticality of the IT services or facilities provided by the PPJTI. The formulation of PPJTI criteria aims to assist the Bank in finding and selecting PPJTI that are suitable for the Bank's needs. After establishing the required PPJTI criteria, the Bank identifies, documents, and categorizes PPJTI according to the established criteria to be managed.

PPJTI Selection Process
In addition to considering Article 30 paragraph (2) of the POJK on IT, in the PPJTI selection process, the Bank must ensure that it is conducted in accordance with fair practices and does not contradict applicable regulations. The Bank must also have PPJTI selection standards in accordance with the complexity of the IT services required by the Bank (best fit). Stages of the PPJTI selection process that can serve as a reference for the Bank:
a. Request for Proposal from PPJTI
The PPJTI selection process begins with a request for a proposal from the PPJTI. The proposal submitted must explain in detail the Bank's needs such as the scope and type of work to be performed, expected service levels, completion timeframes, service cost details, work measurement and control, security, and business continuity. The Bank must be able to ensure PPJTI policies related to the Bank's IT implementation audit interests regarding access for internal auditors, external auditors, and the Financial Services Authority (Otoritas Jasa Keuangan). Thus, the data and information required for IT implementation can still be obtained accurately and on time whenever needed, even if IT is not implemented directly by the Bank. b. PPJTI Due Diligence Due diligence needs to be conducted to assess reputation, technical capability, operational capability, financial condition, development plans, and the ability to follow IT innovations in the market, so that the Bank gains confidence that the PPJTI can meet the Bank's needs. During due diligence, the Bank must consider among others:

the reputation and track record of the PPJTI company;
the qualifications, background, and reputation of the PPJTI company owners;
other companies using the same services from the PPJTI as references;
capability and effectiveness of service provision, including after-sales support;
technology and system architecture;
internal control environment, information security history, and audit scope;
compliance with laws and statutory regulations;
trust and success in relationships with subcontractors;
maintenance guarantees;
ability to provide disaster recovery and business continuity;
implementation of risk management;
IT audit results conducted by independent parties; and
financial conditions including a review of audited financial reports.
Due diligence conducted by the Bank during the selection process must be well documented and conducted periodically as part of the monitoring process. In conducting periodic due diligence, the Bank should consider changes or developments that have occurred since the last due diligence using the latest information.
c. PPJTI Proposal Evaluation
In this stage, the Bank conducts an evaluation of at least the technical and financial aspects for each alternative to be selected. d. Determination of PPJTI In determining the PPJTI, the Bank must consider among others:
cost-benefit analysis for each alternative PPJTI to be selected, including its reasonableness; and
the application of the "arm's length principle" in cooperation with the PPJTI, including related parties with the Bank.

Cooperation Relationship with PPJTI
After selecting the PPJTI, the Bank creates a written cooperation agreement with the PPJTI. In drafting the written agreement, the Bank considers the following:
a. agreement content in accordance with the Bank's agreement standards. The Bank must have standards for cooperation agreements with PPJTI containing at least:

scope of work or services;
costs and duration of the cooperation agreement;
rights and obligations of the Bank and PPJTI;
guarantees for data security and confidentiality;
service level guarantees (Service Level Agreement/SLA), containing performance standards such as agreed service levels and performance targets, including in the event of ownership changes in both the Bank and the PPJTI;
reports on PPJTI performance monitoring results related to SLA;
agreement on the division of responsibility for risks arising in the future, among others:
a) changes in the scope of work and/or implementation timeframes; b) changes in the business and organizational scope of the PPJTI; c) regulatory changes; and d) legal aspects including copyrights, patents, and logos or trademarks;
the Bank's written approval in the event the PPJTI outsources part of its activities (subcontracting) to subcontractors, and ensuring that subcontractors have adequate IT implementation standards;
the PPJTI's willingness to provide access to the Financial Services Authority and/or other authorized parties to conduct examinations of IT service provision activities in accordance with statutory regulations;
the PPJTI must provide technical documents to the Bank regarding the services performed by the PPJTI;
the PPJTI must report to the Bank every critical incident, i.e., incidents that can cause significant financial losses and/or disrupt the smooth operations of the Bank;
the PPJTI's responsibility to provide human resources with qualifications and competencies in accordance with the services provided to ensure Bank operations remain guaranteed;
the PPJTI's willingness to transfer knowledge to Bank human resources regarding the IT services provided;
changes, termination, or cancellation of the agreement, including in the event the Financial Services Authority orders the Bank to stop IT service provision before the end of the agreement duration;
sanctions and penalties for unclear reasons for agreement cancellation and violations of agreement content; and
compliance with laws and statutory regulations in Indonesia.
In addition to the agreement content standards above, cooperation agreements with PPJTI may also contain among others:
ownership and licenses;
availability of communication facilities connected to the internet network and security against access and data transmission to and from Data Centers and/or Disaster Recovery Centers;
clear arrangements regarding data backup, policies in contingency situations threatening Bank operations, data protection for the Bank (record protection) including hardware, software, and equipment, to guarantee the continuity of IT implementation;
for the implementation of Data Centers, Disaster Recovery Centers, and IT-based transaction processing, the PPJTI submits to the Bank the latest audited financial reports annually;
the PPJTI submits to the Bank the results of IT audits conducted by independent auditors periodically;
commitment that the PPJTI will continue to support the services provided to the Bank for a certain period after implementation;
system security standards to be met by the PPJTI; and
document storage agreement (escrow agreement) standards.
The content of the above agreements is applied by considering the scheme, type of service, and/or complexity related to IT service provision used by the Bank, including the significance of the impact of IT service unavailability on Bank operations; b. through a discussion process with the legal work unit; and
c. considering the existence of special clauses for terminating the agreement before its expiration if the PPJTI is in breach of contract. In the use of special clauses, the Bank must consider the following:
In agreements made between the Bank and the PPJTI, special clauses regarding the possibility of modifying, creating new agreements, or taking over activities organized by the PPJTI or terminating the agreement before its expiration must be included. This includes at the request of the Financial Services Authority if deemed necessary with the consideration that implementation by the PPJTI may disrupt the implementation of the Financial Services Authority's duties.
The Bank is able to measure the risk and efficiency of IT implementation entrusted to the PPJTI so that the Bank can know early if there are conditions:
a) materiality reassessment results show that PPJTI performance has the potential to not run effectively; b) deterioration of IT implementation performance by the PPJTI that has the potential to cause and/or result in significant impacts on business activities and/or Bank operations; c) the PPJTI becomes insolvent, in the process towards liquidation, or is declared bankrupt by a court; d) there are violations of statutory regulations regarding Bank secrets and customer personal data; e) there are conditions that cause the Bank to be unable to provide data required for supervision by the Financial Services Authority; and/or f) there are other conditions that cause the disruption or cessation of IT service provision from the PPJTI to the Bank.
In the event the Bank finds conditions as referred to in item 2), the Bank must take actions at least:
a) reporting to the Financial Services Authority no later than 3 (three) working days after the condition is known by the Bank; b) deciding on follow-up actions to be taken to address the problems, including stopping the use of the PPJTI if necessary; and c) reporting to the Financial Services Authority no later than 3 (three) working days after the Bank stops using the PPJTI before the end of the agreement duration, in the event the Bank decides to stop using the PPJTI.
To maintain the continuity of the Bank's business in the event IT service usage is stopped before the agreement expires, the Bank must have a tested and adequate follow-up plan (contingency plan) in force majeure situations.

IT Risk Management Process for PPJTI Usage
a. Risk Identification
Risk identification in the use of PPJTI must at least consider the following:

The use of other PPJTI in implementing Bank IT can contribute to several types of risks, namely:
a) operational risk, i.e., the inability of the PPJTI to fulfill the agreement; b) legal risk, i.e., legal uncertainty over disputes with the PPJTI, third parties, and/or customer claims over the misuse of customer data by the PPJTI; c) reputational risk, i.e., customer dissatisfaction due to the PPJTI's inability to meet SLA; d) strategic risk, i.e., the mismatch of IT used by the Bank with the Bank's strategic objectives and plans made to achieve those objectives; e) compliance risk, i.e., the Bank's inability to meet statutory regulations; and f) country risk, i.e., conditions in foreign countries that can affect the PPJTI's ability to meet service standards.
In conducting risk identification, measurement, monitoring, and control, the Bank must consider matters related to:
a) activities and functions organized by the PPJTI including data sensitivity accessed, protected, or controlled by the PPJTI, transaction volume, and the level of importance of those activities and functions to the Bank's business; b) PPJTI such as financial conditions, workforce competence, management and workforce turnover, PPJTI experience, and professionalism; and c) technology used including reliability, security, availability, and timeliness, as well as the ability to follow technological developments and changes in statutory regulations. b. Risk Measurement After risks are identified, the Bank must measure those risks to determine the level of risk faced. The measurement of PPJTI usage risk must be integrated with the measurement of other IT-related risks using the same risk measurement approach. The results of this PPJTI usage risk measurement must produce a risk level that subsequently becomes one of the parameters for the overall IT risk assessment of the Bank.
c. Risk Mitigation
From the results of risk measurement, the Bank knows the level of risk faced. Next, the Bank must establish risk mitigation strategies in accordance with that risk level. The risk mitigation actions taken by the Bank must be effective in controlling risks.
Risk mitigation actions that can be taken by the Bank include among others applying controls to reduce the likelihood of risk occurrence, among others:
a) adequate PPJTI agreements; b) periodic monitoring of service provider performance; and c) selection of reliable PPJTI.
Other risk mitigation actions are reducing the impact of losses if identified risks occur, such as insurance and Disaster Recovery Plans.
The Bank must ensure that dependency risk on PPJTI can be mitigated so that the Bank remains able to conduct its business if the PPJTI experiences breach of contract, termination of relationship, or is in the process of liquidation. Mitigation risks that can be done include:
a) ensuring that the PPJTI has a Disaster Recovery Plan in accordance with the type, scope, and complexity of activities or services provided; b) actively obtaining guarantees of the PPJTI's Disaster Recovery Plan readiness such as periodic testing of the Disaster Recovery Plan; c) having a source code escrow agreement, if the Bank does not have the source code of application programs organized by the PPJTI; and d) providing guarantees from the PPJTI to the Bank that application continuity is supported by software development officials in the event the source code is not owned by the PPJTI.
In order to guarantee the function and effectiveness of the Disaster Recovery Plan, the Bank must formulate and conduct periodic, complete, and significant testing of the Disaster Recovery Plan based on the type, scope, and complexity of activities or operations conducted by the PPJTI. In addition, the PPJTI must conduct Disaster Recovery Plan testing on its own PPJTI systems or IT facilities or transaction processing organized without involving the Bank. The results of the PPJTI's Disaster Recovery Plan testing are used by the Bank to update the Disaster Recovery Plan owned by the Bank.
d. Other Risk Controls
Even though the Bank and PPJTI already use sophisticated systems, deviations are still possible, such as human error, weak procedure application, and employee theft. The Bank must ensure the existence of security controls to mitigate risks and include:
the PPJTI must conduct background research on its employees;
ensuring the PPJTI's obligation to conduct security controls over all IT facilities used and data processed and information generated is stated in the agreement;
ensuring the PPJTI understands and can meet the level of security required by the Bank for each type of data based on data confidentiality sensitivity; and
ensuring the costs incurred for each security are proportional to the level of security required and in accordance with the risk tolerance level established by the Bank.

PPJTI Performance and Compliance Assessment Procedures
In conducting PPJTI performance and compliance assessments, the Bank considers among others:
a. periodic monitoring and evaluation of PPJTI reliability regarding performance, PPJTI reputation, and service provision continuity; b. the application of adequate IT controls by the PPJTI, proven by audit results and/or assessments conducted by independent parties; and
c. fulfillment of service levels (Service Level Agreement/SLA) in accordance with the service level agreement between the Bank and the PPJTI.
C. Use of PPJTI Outside the Territory of Indonesia
Banks planning to use PPJTI outside the territory of Indonesia must not hinder supervision or examination by the Financial Services Authority. Similar to domestic PPJTI usage, the use of IT services from foreign parties or those located outside the territory of Indonesia must meet the same policies and procedures, but because it involves differences in jurisdiction, there are other matters that the Bank must consider such as the availability of access for the Financial Services Authority to conduct examinations when necessary.

D. Materiality Reassessment against PPJTI
Banks need to conduct reassessment against PPJTI in the event of significant organizational changes in the PPJTI. The changes referred to include among others changes in ownership or changes in the PPJTI's financial conditions, which can impact the provision of IT services provided to the Bank. Reassessment is conducted to assess the materiality of changes in the nature, scale, and complexity of risks inherent in IT service provision. The Bank must have policies, standards, and procedures for materiality reassessment against PPJTI containing at least:

evaluation of reliability regarding reputation, performance, and continuity of service provision by the PPJTI;
timing of reassessment implementation; and
follow-up plans for reassessment results.
Materiality reassessment against PPJTI is conducted by considering among others:
the application of the arm's length principle;
the potential continuity of service provision by the PPJTI; and
assessment of PPJTI performance and compliance.

CHAPTER VI
PLACEMENT OF ELECTRONIC SYSTEMS AND IT-BASED TRANSACTION PROCESSING A. Placement of Electronic Systems In accordance with Article 35 paragraph (1) of the POJK on IT, in IT implementation, the Bank is required to place Electronic Systems in Data Centers and Disaster Recovery Centers within the territory of Indonesia. Placement of Electronic Systems can be conducted outside the territory of Indonesia, provided the Bank has obtained permission from the Financial Services Authority by meeting the provisions regulated in Article 35 paragraph (3) and Article 36 paragraph (3) of the POJK on IT. In placing Electronic Systems in Data Centers and Disaster Recovery Centers outside the territory of Indonesia, the Bank must still ensure:

the application of confidentiality, integrity, and availability principles;
guarantees for the continuity of the Bank's business; and
no reduction in the effectiveness of supervision by the Financial Services Authority.
One of the criteria for placing Electronic Systems outside the territory of Indonesia is Electronic Systems used for internal management. Electronic Systems used for internal management refer to systems used by the Bank for internal purposes, which are not directly related to customer services and/or Bank operations. Electronic Systems used for internal management include among others:
personnel systems;
remuneration systems;
internal audit systems;
internal Bank document processing systems;
internal Bank collaboration applications; and
knowledge management system applications, including those utilizing artificial intelligence.
B. IT-Based Transaction Processing
Article 39 of the POJK on IT regulates that the Bank is required to organize IT-based transaction processing within the territory of Indonesia. IT-based transaction processing can be conducted by PPJTI within the territory of Indonesia.
IT-based transaction processing outside the territory of Indonesia conducted by PPJTI can be implemented provided the Bank obtains permission from the Financial Services Authority. IT-based transaction processing conducted by PPJTI, whether located within the territory of Indonesia or outside the territory of Indonesia, must:
meet the principle of prudence, among others:
a. the Bank applies risk management processes in the implementation of IT-based transaction processing by the PPJTI; b. the Bank ensures the application of confidentiality, integrity, and availability principles by the PPJTI;
c. the Bank remains responsible for transaction processing in the event it is conducted by the PPJTI; and
d. the Bank accounts for documents used in transaction processing, including those conducted by the PPJTI;
consider customer protection aspects, including the application of personal data protection principles; and
be implemented in accordance with provisions regarding the use of PPJTI in Chapter V.

CHAPTER VII
DATA MANAGEMENT AND PERSONAL DATA PROTECTION IN THE IMPLEMENTATION OF BANK IT A. Data Management In fulfilling the obligations referred to in Article 43 of the POJK on IT, Banks manage data effectively in data processing to support the achievement of the Bank's business objectives. The forms of data processing carried out by the Bank include, among others, acquisition, distribution, processing, maintenance, storage, and deletion of data.

In the Bank's business, the main objective of data management is to enable the Bank to manage data as an asset and to ensure the availability of reliable and accurate data for risk aggregation and reporting, including data accountability and data traceability. Data management is implemented by all work units and individuals within the Bank, not limited to IT work units alone. Data management must involve all aspects of human resources (people), processes (process), and technology (technology) required to ensure that processed data aligns with the intended objectives.

In data management, the Bank must have data management policies and standards covering at least the following aspects:

Data Ownership and Stewardship
The Bank establishes the division of duties, authorities, and responsibilities of each unit or function related to data management according to the complexity of the Bank's business, taking into account data ownership and data stewardship.
Data Quality
The Bank establishes data quality standards that must be met in data management, including:
a. accuracy; b. completeness;
c. consistency;
d. integrity; e. fairness; f. timeliness; and g. uniqueness.

The Bank carries out development and efforts to maintain and/or improve data quality, including through:
a. establishing standards, requirements, and specifications for the application of data quality controls; b. identifying issues related to data quality;
c. efforts to improve identified data quality; and
d. evaluating data quality levels.

Data Management System
The Bank needs to form a comprehensive and effective data management system, including:
a. having a data architecture as part of the IT architecture; b. applying data and information protection covering:
1. establishment of data security standards according to data classification; and
2. implementation of data and information security controls and procedures;
  The Bank establishes data classification based on the criticality and sensitivity of each type of data. The Bank establishes methods to maintain data security and privacy based on the established data classification. The aforementioned methods may include, among others, the application of encryption, Role-Based Access Control (RBAC), key management, authentication, and other methods;
  c. The Bank establishes data interoperability and integration standards to enable different systems to exchange data efficiently. Data integration is the merging of data into a consistent form. Data interoperability is the ability of several systems to communicate. The application of data integration and interoperability ensures that the Bank can obtain data anywhere, anytime, and in any form as needed;
  d. establishing a management cycle for each data phase, from creation, usage, storage, archiving, retention, to disposal; e. managing data warehouses and/or business intelligence application systems; and f. establishing policies on metadata management aimed at ensuring the quality and security of metadata. Metadata is a series of data that describes and provides information about other data.
Supporting Resources for Data Management
Supporting resources for data management include:
a. technology used to support the data management system; and b. competent human resources to carry out data management.

B. Personal Data Protection
In processing personal data, the Bank is required to apply personal data protection principles in accordance with the provisions of legislation regarding personal data protection, as regulated in Article 44 of the POJK on IT. The processing of personal data carried out by the Bank must have a legal basis for personal data processing in accordance with the provisions of legislation regarding personal data protection. In the event that the processing of personal data involves third parties, the Bank supervises the parties involved in the processing of the aforementioned personal data.

The Bank may appoint an official or officer responsible for ensuring the implementation of personal data protection principles. The appointment of such officials or officers is carried out by considering the competence possessed by the official or officer to be appointed.

Consent for Personal Data Processing
Before the processing of customer personal data is carried out, the Bank must first obtain explicit consent from the customer and/or prospective customer, which is well-documented. The process of requesting customer consent for the processing of personal data of the customer and/or prospective customer is carried out adequately, taking into account, among others:
a. the Bank's request for consent is not in the form of automatic consent without instructions from the customer, such as the use of pre-checked tick boxes or other types of automatic consent; b. the request for consent is drafted in clear, simple, and easy-to-understand language;
c. the Bank informs the customer of the purpose of the Bank's request for the customer's personal data;
d. the Bank provides consent options for each different purpose and type of personal data processing; e. the Bank provides information on the legality of the processing of the customer's personal data in accordance with applicable legislation; f. the Bank provides information on the customer's right to withdraw consent previously given to the Bank; g. the Bank ensures that the customer has the right to refuse to give consent; h. the Bank does not make the provision of consent for matters not directly related to the customer as a prerequisite for providing Bank services; and
i. the Bank deletes data after the retention period for personal data (only for maintenance/audit/record-keeping purposes) ends in accordance with legislation regarding personal data protection.
Personal Data Protection Impact Analysis
The processing of personal data by the Bank carries risks, including data exploitation, data leaks, privacy violations, and data theft. Therefore, the Bank needs to identify criteria for high-risk personal data according to criteria regulated in legislation regarding personal data protection.

In the event that there are specific conditions in the processing of personal data that have the potential to increase risks for the personal data subject, the Bank needs to conduct an impact assessment on personal data protection in accordance with Article 44 paragraph (2) of the POJK on IT for Business Units. Specific conditions include, among others:
a. the use of new technology; b. tracking customer location and behavior;
c. monitoring public facility locations on a large scale; and
d. processing of sensitive personal data related to ethnicity, religion, race, and inter-ethnic groups.

The personal data protection impact assessment carried out by the Bank contains at least:
a. a description of the personal data processing activities and the purpose of personal data processing, including the Bank's interest in the processing of personal data; b. an assessment of the need and proportionality between the purpose and activities of personal data processing;
c. an assessment of risks to the rights of the data subject (the data subject refers to an individual to whom personal data is attached); and
d. steps taken by the Bank to protect the data subject from risks associated with personal data processing.

Exchange of Personal Data
a. Policies, Standards, and Procedures
The Bank needs to have adequate policies, standards, and procedures regarding the exchange of personal data, containing at least:
1. types of customer data for the exchange or transfer of data and information;
2. customer consent for the exchange or transfer of data and information;
3. mechanisms for information requests by external parties and the provision of information to external parties;
4. data transfer mechanisms;
5. media or facilities permitted for use in the exchange of data and information;
6. security of communication networks and data and information transmission, including the use of encryption;
7. customer rights in transactions involving the exchange or transfer of data and information; and
8. division of responsibilities of parties involved in the exchange or transfer of data.

b. Cooperation Agreements
In carrying out the exchange or transfer of data with third parties, the Bank needs to have adequate cooperation agreements. Adequate cooperation agreements between the Bank and third parties contain at least:

scope and duration of processing;
nature and purpose of processing;
types of personal data and categories of customer data;
obligations and rights of the personal data controller, including all parties involved in the processing of data;
aspects of personal data security; and
data exchange processes in emergency situations.

c. Classification of Data Types
The Bank needs to establish the classification of personal data types and policies and procedures for data exchange in accordance with the established data type classification. The Bank must apply security to customer data being exchanged in accordance with data classification. The establishment of data type classification that can serve as a reference for the Bank includes, among others:

data provided by customers/prospective customers;
transaction data;
data that has added value (value-added) from data provided by customers/prospective customers; and
aggregate data.

CHAPTER VIII
PROVISION OF IT SERVICES BY BANKS
A. Introduction
In implementing IT, Banks require adequate IT infrastructure. The provision of such infrastructure can be done by the Bank itself or by an IT Service Provider (PPJTI). In the event that the Bank provides IT infrastructure independently, there is a possibility that the aforementioned infrastructure is not fully utilized (idle), thus becoming inefficient. Therefore, in order to increase efficiency, the Bank may provide IT services. In addition, the provision of IT services by the Bank can also be carried out to support synergy between banks and/or financial service institutions.

As regulated in Article 48 of the POJK on IT, Banks may only provide IT services to other financial service institutions:

which are supervised by the Financial Services Authority; and/or
outside the territory of Indonesia which are supervised by the local financial service institution supervisory and regulatory authority.

IT services that can be provided by the Bank include, among others, the operation of Data Centers, Disaster Recovery Centers, applications, and communication networks. The provision of IT services in the form of applications to financial service institutions other than banks may be carried out as long as the financial service institution using the IT service is in the same group or cluster as the Bank and the use of the application is intended to support general operational activities. What is meant by "general operational activities" refers to activities that are not specific to the type of financial service institution. Examples of applications intended to support general operational activities include remuneration systems and personnel systems.

The decision to provide IT services must essentially consider efficiency and risk factors. Therefore, the provision of IT services must meet the provisions of the Financial Services Authority and must:

obtain approval from the authorized Bank official;
have an IT service provision agreement that allows for termination clauses according to the agreement term or before the agreement ends;
establish the roles and responsibilities of parties related to the provision of IT services; and
evaluate prospective recipients of IT services, among others based on financial conditions and reputation.

B. Policies, Standards, and Procedures

Policies and Standards for IT Service Provision by Banks
The Bank must have policies and standards for IT service provision by the Bank covering at least:
a. standards for the content of work agreements with recipients of IT services; b. scope of work or services;
c. term of the IT service provision agreement;
d. rights and obligations of the Bank and the recipient of IT services; e. guarantees of data security and confidentiality. Specifically, to maintain the confidentiality of the Bank's data as a user of applications, the Bank as a provider of IT services must separate at least the database(s) adjusted to the Bank's IT architecture as a provider of IT services; f. service level guarantees (Service Level Agreement/SLA), containing performance standards such as agreed service levels and performance targets; g. SLAs remain valid in the event of changes in ownership in either the Bank or the recipient of IT services; h. agreements on the division of responsibilities for risks arising in the future, including:
1. changes in the scope of work and/or implementation time;
2. regulatory changes; and
3. legal aspects including copyright, patents, and logos or trademarks;
  i. clear regulations regarding protection of the Bank's data (record protection), including supporting infrastructure such as hardware, equipment, and software, to ensure the continuity of IT implementation;
  j. ownership and licenses in the event of IT service provision in the form of applications; k. changes, termination, or cancellation of agreements, including in the event that the Financial Services Authority orders the Bank to stop providing IT services before the end of the agreement term;
  l. sanctions and penalties for unclear reasons for agreement cancellation and violations of agreement content;
  m. compliance with Indonesian legislation; and n. system security standards that must be met.
Procedures for IT Service Provision by Banks
The Bank must have procedures for IT service provision by the Bank, namely procedures for defining the needs of the recipient of IT services. The definition of the business needs of the recipient of IT services for IT service provision by the Bank must be carried out before the Bank decides to provide IT services, including through a risk assessment process arising from the provision of IT services by the Bank and the establishment of a basis to be used to identify adequate risk control measurements.

The aforementioned needs definition stage must result in a document containing a detailed description of at least:
a. the scope and characteristics of the services and technology used; b. the term, termination, and minimum content of the agreement; and
c. agreement protection against obligations such as limitation of liability, compensation, and insurance.

C. IT Service Provision Agreements by Banks
After the definition of the business needs of the recipient of IT services for IT service provision by the Bank, the next step in drafting the agreement is that the Bank must go through a discussion process with the legal work unit and consider the existence of special clauses for terminating the agreement before the end of the agreement if the recipient of IT services defaults. Special clauses take into account, among others:

Inclusion of special clauses regarding the possibility of changing, creating new agreements, or stopping the agreement before the end of the agreement.
The Bank is able to measure the risk and efficiency of the IT service provision carried out so that the Bank can know early if there are conditions:
a. worsening of the Bank's conditions due to the provision of IT services, thereby having a significant impact on the Bank's business activities; b. worsening of the recipient of IT services' conditions, thereby having a significant impact on the Bank's business activities;
c. the recipient of IT services' solvency level is inadequate, in the process of becoming liquid, or declared bankrupt by the court; and/or
d. violations by the recipient of IT services regarding legislation regarding the confidentiality of customer personal data.
In the event that the Bank finds matters as referred to in item 2, the Bank decides on the follow-up actions to be taken to address the problems, including the cessation of IT service provision if necessary.

CHAPTER IX
INTERNAL CONTROL AND INTERNAL AUDIT IN THE IMPLEMENTATION OF BANK IT A. Internal Control in the Implementation of IT An effective Internal Control System (SPI) is an important component in the Bank and serves as the basis for healthy and safe operational activities of the Bank. An effective SPI, among others, can help the Bank in safeguarding Bank assets, ensuring the availability of reliable financial and managerial reporting, and reducing the risk of losses, deviations, and violations of prudential aspects.

In the implementation of IT, the Bank must implement SPI effectively across all aspects of IT usage.

In the context of internal control over the implementation of IT, the Bank must pay attention to the following:

The availability of adequate evidence and documents to support the audit trail process. The audit trail must be carried out effectively and documented to ensure that the automation process has worked effectively and accurately. Auditors must assess the effectiveness and accuracy of the audit trail process when evaluating the implementation of the Bank's internal controls.
Implementation of controls over computer systems and their security (general controls) as well as controls over software applications and other manual procedures (application controls).
Anticipation of risks of disruption or loss caused by factors outside the Bank's routine control scope, so that the Bank must organize a recovery system and contingency plans, as well as periodic checks for possibilities of previously unpredictable events (disaster and recovery plan).
Information systems must provide relevant, accurate, timely data and information, accessible to interested parties, and presented in a consistent format.
As part of the recording or bookkeeping process, information systems must be supported by a good accounting system, including the establishment of procedures and schedules for transaction record retention.

B. Internal Audit in the Implementation of IT

Policies, Standards, and Procedures Related to IT Audit
Internal IT audit is necessary to conduct independent and objective evaluations of the implementation of IT, including to improve the efficiency and effectiveness of risk management, internal controls, and good governance.

In accordance with Article 54 of the POJK on IT, the Bank implements an effective and comprehensive internal IT audit function in accordance with the Financial Services Authority's Regulation regarding the application of the internal audit function in general banks. To ensure the implementation of internal IT audit, the Bank must ensure the availability of audit trails for all IT implementation activities for the purposes of supervision, law enforcement, dispute resolution, verification, testing, and other examinations.

The Bank must carry out internal audits on all aspects of IT implementation according to needs, priorities, and IT risk analysis results at least 1 (one) time in 1 (one) year.

In carrying out IT audits, the Bank must have policies, standards, and procedures covering:
a. IT Audit Policy
The Bank must have an IT audit policy covering at least:

the purpose and background of the need for IT audits;
a statement of independence from the operational activities of the auditee;
the auditor's responsibility for IT audits conducted independently from the auditee, including risk assessment execution up to the completion of the audit report;
the auditor's authority to conduct IT audits on data, information, personnel, systems, and other matters required to ensure that the audit runs efficiently and effectively;
the auditee's responsibilities, including system owners, data owners, system administrators, security officers, Chief Information Officer/CIO, regarding IT audits conducted, such as providing data, implementing recommendations, and improvements;
deadlines for data and responses by the auditee;
a statement that every Bank activity must fall within the scope of the Bank's IT audit;
follow-up in the event of violations of the IT audit policy; and
periodic review of the internal audit function regarding IT implementation using the services of independent external parties, in accordance with the Financial Services Authority's Regulation regarding the application of the internal audit function in general banks.

b. IT Audit Standards
The Bank must have IT audit standards covering at least:

audit working plan (Audit Working Plan/AWP);
audit working papers, including audit results or findings;
audit reports; and
monitoring of follow-up on audit results.

c. IT Audit Procedures
The Bank must have IT audit procedures covering at least:

IT governance;
IT architecture;
IT risk management, including information security, communication networks, and Disaster Recovery Plans;
the use of IT Service Providers (PPJTI);
the placement of Electronic Systems;
data management and personal data protection;
IT service provision by the Bank; and
critical business applications.

Inspection steps are adjusted to each inspection object and scope.

IT Audit Process
In conducting IT audits, the following processes are carried out:
a. IT Audit Planning
The Bank must have an IT audit plan that covers the frequency and schedule of IT audits. In conducting risk assessments, internal IT audit performs at least:

identifying IT assets, including data (hardcopy or softcopy), software, hardware, and networks;
identifying activities and business processes that utilize IT;
identifying the level of IT risk impact on Bank operations; and
considering priority scales based on risk levels.
The IT audit plan must receive approval in accordance with Financial Services Authority Regulations regarding the implementation of the internal audit function in commercial banks. b. IT Audit Execution
The execution of IT audits aims to:
a) ensure that IT management policies, standards, and procedures are implemented effectively; b) ensure the effectiveness of IT risk management implementation; c) ensure the effectiveness of information management standards and IT usage security; d) assess the adequacy of controls implemented in IT management; e) provide improvement recommendations to address deficiencies in IT management; and f) ensure IT management compliance with applicable legislation.
In implementing the annual IT audit plan, audit work plans must be prepared for each audit assignment, covering among others:
a) audit objectives, schedule, number of auditors, budget, and reporting; b) audit scope based on risk assessment results; and c) division of duties and responsibilities of auditors.
In performing their duties, IT auditors must pay attention to data and information confidentiality. IT audit execution must use standard examination working papers and be well documented. IT auditors may request data or information for duty purposes in hardcopy or softcopy form, including databases from applications.
IT auditors must uphold the principles of the code of ethics (ethics) in performing their duties as follows:
a) integrity
(1) work honestly, diligently, and responsibly; (2) comply with regulations and make disclosures in accordance with regulations; (3) not engage in illegal activities; and (4) respect and play a role in supporting Bank objectives; b) objectivity (1) do not participate in activities that may affect the objectivity of audit execution; (2) do not accept anything that may affect audit execution and work according to expertise; and (3) disclose facts as found during audit execution; c) confidentiality (1) be careful in using data or information and protect data or information during audit execution; and (2) do not use data or information for personal interests or contrary to law; and d) competence (1) possess adequate knowledge; (2) perform audit duties in accordance with standards set by the Bank; and (3) continuously strive to improve abilities to enhance audit quality.
Statements regarding IT auditor ethics may be formulated in a written statement of commitment signed by each Bank IT audit personnel, including sanctions for violations of such ethics.
c. IT Audit Results Reporting
IT audit results reports are prepared based on standard report formats. The report serves as a tool for the Bank to assist in assessing IT control quality. IT audit results reports must be submitted to the audited work unit. Submission of reports is done promptly in accordance with Financial Services Authority Regulations regarding the implementation of the internal audit function in commercial banks. d. Monitoring of IT Audit Results Follow-up The auditee must respond to examination results. If findings require follow-up, the auditee must provide commitment and target completion times. Subsequently, IT auditors must periodically monitor the auditee's implementation of commitments regarding examination results and verify improvements already made. IT auditors must maintain documentation of such follow-up results. Reports on the monitoring of follow-up improvements for significant findings are submitted in accordance with Financial Services Authority Regulations regarding the implementation of the internal audit function in commercial banks.

Fulfillment of Internal IT Audit Function by External Auditors
In the event of limitations in the internal audit work unit's capabilities, the internal IT audit function may be carried out by external auditors. The use of external auditors to perform internal IT audit functions does not reduce the responsibility of the internal audit work unit leadership. Furthermore, the use of external auditors must consider the size and complexity of the Bank's business and pay attention to relevant legislation regarding external auditors, and implementation is carried out in accordance with the Bank's IT audit standards and procedures. The implementation of the internal IT audit function by external auditors continues to pay attention to competence (among others adequate knowledge and experience) and independence, and is based on a cooperation agreement. In addition, the Bank periodically reviews the internal IT audit function by independent external parties to ensure the effectiveness of IT audit execution. EXECUTIVE HEAD OF BANKING SUPERVISOR FINANCIAL SERVICES AUTHORITY REPUBLIC OF INDONESIA, DIAN EDIANA RAE signed.

This copy is in accordance with the original.
Head of Legal Development Directorate
Legal Department signed.
Aat Windradi

APPENDIX II
REGULATION OF THE BOARD OF COMMISSIONERS OF THE FINANCIAL SERVICES AUTHORITY REPUBLIC OF INDONESIA NUMBER 1 OF 2026 CONCERNING INFORMATION TECHNOLOGY MANAGEMENT BY COMMERCIAL BANKS

PROCEDURES FOR SUBMISSION OF REPORTS AND PERMITS

A. Submission of Information and Reporting

IT Strategic Plan
a. The Bank submits the ITSP as referred to in Article 12 of the POJK IT to the Financial Services Authority, containing documents/information in accordance with Appendix I Chapter III letter B number 1. b. The ITSP is submitted to the Financial Services Authority at the latest by the end of November in the year before the start of the ITSP period. Example:
The ITSP for the period from 2027 to 2031 is submitted to the Financial Services Authority at the latest by the end of November 2026.
c. The Bank may change the ITSP in the event of conditions that significantly affect the Bank's IT objectives and strategies as contained in the currently running ITSP.
d. The Bank submits changes to the ITSP to the Financial Services Authority at any time during the ITSP period, accompanied by documents containing:

reasons for the ITSP change;
evaluation of the Bank's performance in IT management in the previous period;
the Bank's vision and mission regarding IT management or its update;
analysis of the current internal and external environment; and
the Bank's current objectives and strategies regarding IT management.
e. The ITSP and changes to the ITSP are submitted to the Financial Services Authority online through the Financial Services Authority's reporting system.

IT Development Plan Report
a. In accordance with Article 58 of the POJK IT, the Bank is required to report the IT development plan. The IT Development Plan Report (LRPTI) is a document detailing the IT development plan for the next 1 (one) year in accordance with the Bank's ITSP. b. The Bank submits the LRPTI to the Financial Services Authority using the format as referred to in Format 3.1 in Appendix III of this Regulation of the Board of Commissioners.
c. The LRPTI is submitted at the latest by the end of November before the year of the IT development plan.
Example:
The Bank submits the LRPTI for the 2027 IT development plan at the latest by the end of November 2026. d. The LRPTI can be changed at most 1 (one) time, submitted at the latest by the end of June of the current year. Changes to the LRPTI may be submitted by the Bank provided that:

certain considerations are met, including to support the implementation of policies and/or regulations in the financial services sector and/or government to drive economic development; and
approval is obtained from the Financial Services Authority.
e. In the event of a need to change the LRPTI related to IT development for the implementation of advanced Bank products in the form of IT-based activities, the Bank may change the LRPTI at most 3 (three) times and at the latest submitted by the end of March, June, and September of the current year, in accordance with Financial Services Authority Regulations regarding the implementation of Bank products. f. Examples of change periods for the LRPTI as referred to in letter e may refer to the chart in letter C of Appendix II of this regulation. g. The Financial Services Authority may request the Bank to adjust changes to the LRPTI as referred to in letter d and letter e. h. The LRPTI and changes to the LRPTI are submitted online through the Financial Services Authority's reporting system.

Current Condition Report on IT Management
a. In accordance with Article 59 of the POJK IT, the Bank is required to report the current condition of IT management. The Current Condition Report on IT Management (LKTPTI) contains the Bank's IT management conditions, including changes made during the 1 (one) year reporting period. b. The Bank submits the LKTPTI to the Financial Services Authority using the format as referred to in Format 3.2 in Appendix III of this Regulation of the Board of Commissioners.
c. The LKTPTI is submitted on January 21 of the following year, in accordance with general bank reporting regulations through the Financial Services Authority's reporting system.
Example:
The Bank submits the LKTPTI for 2027 at the latest on January 21, 2028. d. The LKTPTI is submitted online through the Financial Services Authority's reporting system.
Results of Review of Internal IT Audit Function and Internal IT Audit Results
a. In accordance with Article 55 paragraph (3) of the POJK IT, the Bank is required to submit:

results of the review of the internal IT audit function as part of the results of the review by independent external parties; and
results of internal IT audits submitted as part of the report on the implementation and main points of internal audit results, in accordance with Financial Services Authority Regulations regarding the implementation of the internal audit function for commercial banks.
b. The results of internal IT audits as referred to in letter a number 2) are submitted to the Financial Services Authority using the format as referred to in Format 3.3 in Appendix III of this Regulation of the Board of Commissioners.

Initial Notification and IT Incident Reports
a. IT incidents are critical events, misuse, and/or crimes in IT management. IT incidents are divided into 2 (two) categories: cyber incidents and non-cyber incidents. b. The IT incident reporting provisions in this Regulation of the Board of Commissioners apply to non-cyber incidents. Reporting provisions for cyber incidents refer to the SEOJK Cyber.
c. In the event of a non-cyber incident that has the potential and/or has caused significant losses and/or disrupted the smooth operation of the Bank, the Bank is required to submit:

initial IT incident notification; and
IT incident report,
in accordance with Article 60 paragraph (1) of the POJK IT. d. Initial IT incident notifications are submitted by the Bank with the following provisions:
Initial notifications are prepared using the format as contained in Format 3.4.1 in Appendix III of this Regulation of the Board of Commissioners. The initial notification contains initial information available regarding the IT incident at the Bank.
The initial notification is submitted to the Financial Services Authority at the latest 24 (twenty-four) hours after the IT incident is known by the Bank, addressed to the relevant Bank supervisor via written electronic means. The Bank makes efforts to ensure that the initial notification has been received by the Financial Services Authority.
e. As a follow-up to the initial IT incident notification submitted, the Bank conducts further analysis and handling of the IT incident. This follow-up is submitted through the IT incident report to the Financial Services Authority with the following provisions:
The IT incident report is prepared using the format as contained in Format 3.4.2 in Appendix III of this Regulation of the Board of Commissioners. The IT incident report contains more complete information than the information submitted in the initial notification.
The IT incident report is submitted online through the Financial Services Authority's reporting system at the latest 5 (five) working days after the IT incident is known.
f. In the event that other authorities have regulations regarding the submission of initial notifications and/or IT incident reports, the Bank submits initial notifications and/or IT incident reports to the Financial Services Authority with the following provisions:
In the event that other authorities regulate the submission time for initial notifications and/or IT incident reports to be faster than the time regulated in the POJK IT, the Bank submits initial notifications and/or IT incident reports to the Financial Services Authority simultaneously in accordance with the legislation of the other authority.
Example:
Regulations of Authority "ABC" a) Initial notification submission time is at the latest 1 (one) hour after the IT incident is known. b) IT incident report submission time is at the latest 3 (three) working days after the cyber incident is known. Bank "X" experienced an IT incident on January 2, 2026 at 13:00 WITA. Given that the submission time for initial notifications and/or IT incident reports based on the regulations of Authority "ABC" is faster than those regulated in the Financial Services Authority's regulations, Bank "X" submits the initial notification within 1 (one) hour after the IT incident is known. If Bank "X" submits the initial IT incident notification to Authority "ABC" at 13:45 WITA, then Bank "X" also submits the initial notification to the Financial Services Authority at the same time. The same applies to the submission of IT incident reports. If Bank "X" submits the IT incident report on January 4, 2026 at 10:00 WITA to Authority "ABC", then Bank "X" also submits the IT incident report to the Financial Services Authority at the same time.
If other authorities regulate the submission time for initial notifications and/or IT incident reports to be longer than the time regulated in the POJK IT, then the Bank submits initial notifications and/or IT incident reports to the Financial Services Authority in accordance with the POJK IT.
Example:
Regulations of Authority "DEF" a) Initial notification submission time is at the latest 3 (three) working days after the cyber incident is known. b) IT incident report submission time is at the latest 10 (ten) working days after the cyber incident is known. Bank "Y" experienced a cyber incident on January 2, 2026 at 13:00 WITA. Given that the submission time for initial notifications and/or IT incident reports based on the Financial Services Authority's regulations is faster than those regulated in the regulations of Authority "DEF", Bank "Y" submits the initial notification to the Financial Services Authority within 24 (twenty-four) hours after the IT incident is known. The same applies to the submission of IT incident reports. Bank "Y" submits the IT incident report within 5 (five) working days after the IT incident is known to the Financial Services Authority.

B. Licensing and Realization Reports

Licensing
a. Banks that will operate Electronic Systems located in Data Centers and/or Disaster Recovery Centers outside the territory of Indonesia must submit a permit application to the Financial Services Authority. In submitting the permit application, the Bank must fulfill Article 35, Article 36, and Article 37 of the POJK IT. The permit application is accompanied by documents as contained in Format 4.1 in Appendix IV of this Regulation of the Board of Commissioners. b. Banks that will hand over the management of IT-based transaction processing to service providers outside the territory of Indonesia must submit a permit application to the Financial Services Authority. In submitting the permit application, the Bank must fulfill Article 39 of the POJK IT. The permit application is accompanied by documents as contained in Format 4.3 in Appendix IV of this Regulation of the Board of Commissioners.
c. Banks that have plans to become IT service providers must submit a permit application to the Financial Services Authority. In submitting the permit application, the Bank must fulfill Article 48 of the POJK IT. The permit application is accompanied by documents as contained in Format 4.5 in Appendix IV of this Regulation of the Board of Commissioners.
d. The permit applications as referred to in letter a, letter b, and letter c are submitted to the Financial Services Authority online in accordance with Article 40 paragraph (1) of the POJK IT, through the Financial Services Authority's integrated licensing and registration system. e. In the event that the submission medium as referred to in letter d is not yet available, submission is done online through the Financial Services Authority's reporting system at the address https://sipenaojk.ojk.go.id, addressed to:

Relevant Bank Supervision Department or Financial Services Authority Regional Office in Jakarta, for Banks headquartered in the Special Capital Region of Jakarta or Banten Province; or
Financial Services Authority Regional Office or Local Financial Services Authority Office, for Banks headquartered outside the Special Capital Region of Jakarta or Banten Province.
f. In the event that the submission medium as referred to in letter e is not available, submission is done online through the Financial Services Authority's mailing room service. g. The Financial Services Authority grants or rejects permit applications:
for the placement of Electronic Systems in Data Centers and/or Disaster Recovery Centers outside the territory of Indonesia as referred to in Article 35 of the POJK IT; or
for IT-based transaction processing by ITSP outside the territory of Indonesia as referred to in Article 39 of the POJK IT,
at the latest 3 (three) months after all requirements are fulfilled by the Bank and the permit application documents are received completely by the Financial Services Authority.

Realization Reports
a. The Bank must place Electronic Systems in Data Centers and/or Disaster Recovery Centers outside the territory of Indonesia as referred to in number 1 letter a. b. The Bank must implement IT-based transaction processing by ITSP outside the territory of Indonesia as referred to in number 1 letter b.
c. The Bank must implement the IT service provision plan as referred to in number 1 letter c.
d. If the Bank does not realize the implementation as referred to in letter a, letter b, and letter c within a period of 6 (six) months since the permit was obtained from the Financial Services Authority, the Financial Services Authority's permit becomes invalid. e. The Bank submits realization reports on the placement of Electronic Systems in Data Centers and/or Disaster Recovery Centers outside the territory of Indonesia as referred to in number 1 letter a using the format as referred to in Format 4.2 in Appendix IV of this Regulation of the Board of Commissioners. f. The Bank submits realization reports on the implementation of IT-based transaction processing by ITSP outside the territory of Indonesia as referred to in number 1 letter b using the format as referred to in Format 4.4 in Appendix IV of this Regulation of the Board of Commissioners. g. The Bank submits realization reports on the implementation of the IT service provision plan as referred to in number 1 letter c using the format as referred to in Format 4.6 in Appendix IV of this Regulation of the Board of Commissioners. h. The realization reports as referred to in letter e, letter f, and letter g are submitted online through the Financial Services Authority's reporting system at the address https://sipenaojk.ojk.go.id at the latest 3 (three) months after implementation.

This copy is in accordance with the original.
Head of Legal Development Directorate
Legal Department signed.
Aat Windradi

C. Timeline Chart for Submission of IT Development Plan Reports in the Context of Implementing Advanced Bank Products in the Form of IT-Based Activities
Explanation:
(1) T = Year of the IT management plan related to advanced Bank products in the form of IT-based activities.
(2) The Bank can only change the IT Development Plan Report at most 1 (one) time at each stage.
EXECUTIVE HEAD OF BANKING SUPERVISOR
FINANCIAL SERVICES AUTHORITY
REPUBLIC OF INDONESIA,
DIAN EDIANA RAE signed.

30 November (T-1) 31 March (T)
Submission Period for Changes to the IT Development Plan Report Stage I 1 January (T) 30 June (T) 30 September (T) Submission Period for Changes to the IT Development Plan Report Stage II Submission Period for Changes to the IT Development Plan Report Stage III Deadline for Submission of IT Development Plan Report signed.

APPENDIX III
REGULATION OF THE BOARD OF COMMISSIONERS OF THE FINANCIAL SERVICES AUTHORITY REPUBLIC OF INDONESIA NUMBER 1 OF 2026 CONCERNING INFORMATION TECHNOLOGY MANAGEMENT BY COMMERCIAL BANKS

REPORT AND NOTIFICATION FORMATS

TABLE OF CONTENTS
Format 3.1 IT Development Plan Report
Format 3.2 Current Condition Report on IT Usage Format 3.3 Internal IT Audit Results Report Format 3.4 Initial Notification and IT Incident Report

Format 3.1
IT DEVELOPMENT PLAN REPORT
Explanation:
(1) Filled with serial number.
(2) Filled with the name of the application/infrastructure to be developed. Example: "Application X", "Data Center Relocation", "Network bandwidth capacity addition". (3) Detailed explanation of the developed application/infrastructure. (4) Development category, choose one:
01 : Customer Management 10 : Reporting Information System Management 02 : Third-party Funds (checking, savings, deposits) 11 : Risk Management 03 : Lending/Financing 12 : Internal Management 04 : General Ledger (GL) 49 : Other Applications 05 : Payments 51 : Data Center/Disaster Recovery Center 06 : Digital Services 52 : Server and/or Platform 07 : Treasury 53 : Data Communication Network 08 : Trade Finance 54 : Security System 09 : AML-CFT and PPPSPM 99 : Other Infrastructure No. Bank Application/Infrastructure Name Description Development Category Type Developer ITSP Related Parties Location Planned Implementation Time Estimated Cost Note Data Center Disaster Recovery Center Investment Cost Operational Cost (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11)

(5) Fill in "new" if it is a new application/infrastructure or replacing old application/infrastructure, fill in "upgrade" for additions/developments to existing application/infrastructure. (6) Fill in "inhouse" if developed by the Bank's internal party or fill in "PPJTI" if developed by the Bank's external party. (7) Fill in "yes" if PPJTI is a related party to the Bank, "no" if PPJTI is not a related party, "-" if development is done inhouse or PPJTI has not been determined. (8) Fill in information on the city and country name of the Data Center and Disaster Recovery Center location. (9) Fill in using a quarterly period, namely Q1/Q2/Q3/Q4. (10) Fill in the estimated Investment Cost (capex) and/or Operational Cost (opex) for 1 (one) year since implementation (excluding capex depreciation costs). Costs in Rupiah currency units or other currency units accompanied by an equivalent value in Rupiah currency. (11) Fill in with, among others:

impacts of IT development, for example, the need for additional human resources.
explanation of the relationship between IT development and IT Strategic Plan (RSTI).
relationship with the plan for implementing new bank products (RPPB) in accordance with POJK regarding the implementation of Bank products.

Format 3.2
CURRENT STATUS REPORT ON INFORMATION TECHNOLOGY USAGE LIST OF DOCUMENTS AND INFORMATION IN CURRENT STATUS REPORT ON INFORMATION TECHNOLOGY USAGE No. Name of Document or Information 1 Reporter Information 2 Organization and Management
2.1 Bank Organizational Structure and Number of Bank Human Resources
2.2 IT Organizational Structure and Number of IT Human Resources
2.3 Latest IT Steering Committee Decision Letter
2.4 Minutes of IT Steering Committee Meetings for the Last 1 (one) Year
3 IT Policies, Standards, and Procedures
4 Risk Management
4.1 Implementation of Risk Management
4.2 IT Internal Audit Organizational Structure
4.3 IT Audit for the Last 1 (one) Year
5 IT Architecture
6 Application List
7 Electronic Banking Terminals
8 Data Center (DC) and Disaster Recovery Center (DRC) 9 IT Security 10 Disaster Recovery Plan (DRP) 11 IT Service Providers 12 IT Costs 13 Assessment Related to Bank Cyber Security
13.1 Working Paper on Inherent Risk Assessment Related to Cyber Security
13.2 Results of Assessment Related to Bank Cyber Security
13.3 Working Paper on Quality Assessment of Cyber Security Risk Management Implementation
13.4 Working Paper on Quality Assessment of Cyber Resilience Process Implementation
14 Results of Cyber Security Testing Based on Vulnerability Analysis 15 Self-Assessment of Digital Maturity Level
15.1 Working Paper on Quality Assessment of Digital Maturity Aspects of the Bank
15.2 Results of Assessment of Bank Digital Maturity Level
16 List of Bank Partners in Conducting Digital Service Cooperation 17 Results of Electronic System Identification

Format 3.2.1
REPORTER INFORMATION
Bank Name : ...............................................
Bank Headquarters Address : ........................
Telephone Number : ………………………………….
Contact Person Name : ............................................
Contact Person Telephone Number : ..............................
Reporting Office/Division/Section: ...........
Reporting Office/Division/Section Address: .................................
Reporting Date: …./…./………. (dd/mm/yyyy)

Format 3.2.2
ORGANIZATION AND MANAGEMENT
No.
Format
Information Description Remarks
2.1 Bank Organizational Structure and Number of Bank HR
(Attached)
2.2 IT Organizational Structure and Number of IT HR (Attached)
2.3 Latest IT Steering Committee Decision Letter (Attached)
2.4 Minutes of IT Steering Committee Meetings for the Last 1 (one)
Year
(Attached)

Format 3.2.3
INFORMATION TECHNOLOGY POLICIES, STANDARDS, AND PROCEDURES Remarks:
(1) Fill in with serial number.
(2) Fill in with Bank document version number.
(3) Fill in with document title.
(4) Fill in brief description regarding the content of the document, example: policy on selecting PPJTI when the candidate PPJTI is a related party.
(5) Fill in with one of the following categories:
300 : IT Governance (including
Organization and Management)
307 : Use of PPJTI
301 : Risk Management 308 : Provision of IT Services by Bank 302 : Development and Procurement 309 : IT Resilience and Security including cyber 303 : IT Operations 310 : Data Management 304 : Communication Network 311 : Internal Control 305 : Information Security 312 : Others 306 : Disaster Recovery Plan (6) Fill in with one of the following types:
K = Policy
S = Standard
P = Procedure
(7) Fill in the date of the last revision (dd-mm-yyyy).
No. Document
Number
Document
Title
Description Category Type Last
Revision
(1) (2) (3) (4) (5) (6) (7)

Format 3.2.4
RISK MANAGEMENT
4.1 IMPLEMENTATION OF RISK MANAGEMENT
Adequacy of policies, standards, and procedures for IT usage
..................
(Brief explanation regarding policies, standards, and procedures for IT usage) Adequacy of the process for identifying, measuring, monitoring, and controlling IT usage risk
...................
(Brief explanation regarding the identification, measurement, monitoring, and control process for IT usage risk) Internal control system for IT usage
...................
(Brief explanation regarding risk control mechanisms and results) IT Risk Rating (Low, Low-to-moderate, Moderate, Moderate-to-high, High)
...................
(Final self-assessment IT risk rating value)
4.2 IT INTERNAL AUDIT ORGANIZATIONAL STRUCTURE
4.3 IT AUDIT FOR THE LAST 1 (ONE) YEAR
Audit Period Audit Type Audit Scope
(1) (2) (3)
Remarks:
(1) Fill in the start date and end date of the audit.
(2) Fill in the type of audit: internal or external.
(3) Fill in the audit scope (example: Core banking system loan module).
(Fill in with an image of the IT Internal Audit Organizational Structure; State the number of HR in the IT Internal Audit Work Unit)

Format 3.2.5
IT ARCHITECTURE
Data Architecture
(Fill in with Data Architecture diagram)
Application Architecture
(Fill in with Application Architecture diagram) Technology Architecture (Fill in with Technology Architecture diagram) *) IT Architecture Diagram is adjusted to the Bank's business complexity. The IT architecture diagram depicts the current condition of the Bank's IT at the time of the reporting period.

Format 3.2.6
APPLICATION LIST
Remarks:
(1) Fill in with serial number.
(2) Fill in with one of the following categories:
01 : Customer Management 08 : Trade Finance
02 : Third-party Funds (checking, savings, deposits) 09 : AML-CFT and PPPSPM 03 : Lending/Financing 10 : Reporting Information System Management 04 : General Ledger (GL) 11 : Risk Management 05 : Payments 12 : Internal Management 06 : Digital Services 49 : Other Applications 07 : Treasury (3) Fill in with the application name. (4) Fill in with a brief description regarding the application's function. (5) Fill in the operating system platform. (6) Fill in the required database engine. (7) Fill in with the city and/or country of the Data Center location. (8) Fill in with the name of the DC Provider company or "self" (Bank). (9) Fill in with the city and/or country of the application Disaster Recovery Center location. No. Category Application Application Name Description Application Function Platform Database Location Backup Strategy System Owner Application Developer (inhouse/ IT Service Provider) Implementation Date (Go Live) Ownership (Rent or Buy Out) DC Provider DC DRC Provider DRC (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15)

(10) Fill in with the DRC Provider company or "self" (Bank).
(11) Fill in with:

High Availability Active - Active
High Availability Active - Passive
Backup Realtime
Backup Periodically
(12) Fill in with the business unit that manages the application.
(13) Fill in with:
"inhouse", if the application is developed by the Bank itself.
Name of PPJTI, if the application is developed by PPJTI.
(14) Fill in with the application implementation date (dd-mm-yyyy).
(15) Fill in with "Rent" or "Buy Out".

Format 3.2.7
ELECTRONIC BANKING TERMINALS
No. TPE Name TPE Type Quantity Transaction Frequency Nominal Transactions per Year Number of Users (1) (2) (3) (4) (5) (6) (7) Remarks:
(1) Fill in with serial number.
(2) Fill in with the name of the electronic banking terminal (TPE) product or platform, if any. Example: "A Bank Mobile" (3) Fill in with one of the following TPE types:

Automated Teller Machine (ATM);
Cash Deposit Machine (CDM);
Cash Recycler Machine (CRM);
Electronic Data Capture (EDC);
Phone Banking;
SMS Banking;
Internet/Mobile Banking;
Others (can be filled with: electronic money or e-wallet).
(4) Fill in with the number of TPE units.
(5) Fill in with the number of transaction frequencies from the TPE.
(6) Fill in with the nominal amount of transactions from the TPE during the 1 (one) reporting year.
(7) Fill in with the number of TPE users, if any.

Format 3.2.8
DATA CENTER (DC) AND DISASTER RECOVERY CENTER (DRC) DC/DRC 1 Remarks Function : (Fill in "DC" or "DRC") Provider :
(Fill in "self" (Bank) or provider name)
Address and/or Location:
(Fill in with the address of the DC or DRC)
DC/DRC Area Size: *)
(Fill in with the area size of the DC or DRC)
DC/DRC Certification:
(Assessment results according to certification if available/equivalent based on internal assessment) Physical Controls: *) Example:

Data Center and Disaster Recovery Center doors must always be locked and equipped
with access cards and/or biometric devices
Data Center and Disaster Recovery Center rooms must not be labeled or have signboards
so that people cannot easily recognize them
The Bank must have a log-book to record visitors entering the Data Center and
Disaster Recovery Center
Maintain the privacy of the Data Center and Disaster Recovery Center location
(Brief explanation regarding physical controls in DC/DRC) Environmental Controls: *) Example:
Uninterruptible Power Supply (UPS)
Raised floor
Air temperature and humidity control (AC,
thermometer, and hygrometer)
Smoke/fire/heat/water leak detectors
Fire suppression system
CCTV cameras
and others
....................
(Brief explanation regarding environmental controls in DC/DRC) DC/DRC – 2, 3, … Remarks Function : (Fill in "DC" or "DRC") Provider :
(Fill in "self" (Bank) or provider name)
Address and/or Location:
(Fill in with the address of the DC or DRC)
DC/DRC Area Size: *)
(Fill in with the area size of the DC or DRC)

DC/DRC Certification:
(Assessment results according to certification if available/equivalent based on internal assessment) Physical Controls: *) Example:

Data Center and Disaster Recovery Center doors must always be locked and equipped
with access cards and/or biometric devices
Data Center and Disaster Recovery Center rooms must not be labeled or have signboards
so that people cannot easily recognize them
The Bank must have a log-book to record visitors entering the Data Center and
Disaster Recovery Center
Maintain the privacy of the Data Center and Disaster Recovery Center location
(Brief explanation regarding physical controls in DC/DRC) Environmental Controls: *) Example:
Uninterruptible Power Supply (UPS)
Raised floor
Air temperature and humidity control (AC,
thermometer, and hygrometer)
Smoke/fire/heat/water leak detectors
Fire suppression system
CCTV cameras
and others
....................
(Brief explanation regarding environmental controls in DC/DRC) Remarks:
*) Only fill in if the DC/DRC is managed independently by the Bank (on premise).

Format 3.2.9
IT SECURITY
No. Asset Name Asset Type Description
(1) (2) (3) (4)
Remarks:
(1) Fill in with serial number.
(2) Fill in with the name of the IT security asset (example: antivirus "XYZ" and firewall "ABC").
(3) Fill in with the type of asset (software or hardware).
(4) Fill in with a brief description regarding the asset (such as asset function, number of licenses, asset version, and others).

Format 3.2.10
DISASTER RECOVERY PLAN (DRP)
A. General DRP Information
Type : (Fill in with general information regarding the type) Backup media location : (Fill in with the backup media location) Last DRP testing date : (Fill in with the DRP testing time) B. DRP Team Structure (Fill in with an image of the DRP Team Structure)
C. DRP Testing
DRP Testing – 1
Testing Time (Fill in with the DRP testing time) List of Bank Applications and/or Infrastructure (Fill in with the list of applications and/or infrastructure tested in the last 1 (one) year) DRP Testing Results (Fill in with a brief explanation regarding the DRP testing results) DRP Testing – 2, 3, …. Testing Time (Fill in with the DRP testing time) List of Bank Applications and/or Infrastructure (Fill in with the list of applications and/or infrastructure tested in the last 1 (one) year) DRP Testing Results (Fill in with a brief explanation regarding the DRP testing results) D. DRP Review Implementation DRP Review Implementation - 1 Review Implementation Time 1 (Fill in with the DRP review time) Review Implementation Time 2 (if any) (Fill in with the DRP review time) List of Bank Applications and/or Infrastructure (Fill in with the list of applications and/or infrastructure that were reviewed in the last 1 (one) year) Review Results (Fill in with the review results) Review Implementer (Fill in with the position and name of the officer who conducted the review) Review Follow-up (Fill in with the steps that need to be taken after the review implementation) DRP Review Implementation – 2, 3, … Review Implementation Time 1 (Fill in with the DRP review time)

Review Implementation Time 2
(if any)
(Fill in with the DRP review time)
List of Bank Applications and/or
Infrastructure
(Fill in with the list of applications and/or infrastructure that were reviewed in the last 1 (one) year) Review Results (Fill in with the review results) Review Implementer (Fill in with the position and name of the officer who conducted the review) Review Follow-up (Fill in with the steps that need to be taken after the review implementation)

Format 3.2.11
IT SERVICE PROVIDERS
A. Use of IT Service Providers by the Bank
No.
PPJTI
Name
PPJTI
Address
Related
Party
IT Services
Provided
Cooperation Start
Date
(1) (2) (3) (4) (5) (6)
B. Bank as IT Service Provider
No.
IT Service
User Name
IT Service User
Address
Related
Party
IT Services
Provided
Cooperation Start
Date
(1) (2) (3) (4) (5) (6)
Remarks:
(1) Fill in with serial number.
(2) Fill in with the name of the PPJTI or the Bank's IT service user.
(3) Fill in with the address of the PPJTI or the Bank's IT service user.
(4) Fill in with:

"Y", if the PPJTI or Bank's IT service user is a related party to
the Bank; or
"T", if the PPJTI or Bank's IT service user is not a related party
to the Bank.
(5) Fill in with the list of IT services provided by the PPJTI to the Bank or IT services provided by the Bank to the user, such as:
Data Center Management;
Disaster Recovery Center Management; and
Application service provision.
(6) Fill in with the date the cooperation began between the Bank and the PPJTI, or between the Bank and the IT service user.

Format 3.2.12
INFORMATION TECHNOLOGY COSTS
Cost Type To Related Parties *)
To Unrelated Parties *)

Charged to profit/loss
a. Capitalizable investment costs (capital expenditure/capex) b. Operational costs (operational expenditure/opex)
Charged to the balance sheet
Remarks:
(1.a) Fill in with the depreciation of investment costs (capex) charged to profit/loss.
(1.b) Fill in with the charging of operational costs (opex) to profit/loss.
(2) Fill in with additional investment costs (capex) of the current year charged to the balance sheet.
*) Costs in Rupiah currency units or other currency units accompanied by an equivalent value in Rupiah currency.

Format 3.2.13
ASSESSMENT RELATED TO BANK CYBER SECURITY
No.
Format
Name of Information/Report Remarks
13.1 Working Paper on Inherent Risk Assessment Related
to Cyber Security
(Attached)
13.2 Results of Assessment Related to Bank Cyber Security (Attached)
13.3 Working Paper on Quality Assessment of Cyber Security Risk Management
Implementation
(Attached)
13.4 Working Paper on Quality Assessment of Cyber Resilience Process
Implementation
(Attached)
Remarks:
All report formats and information on assessments related to Bank cyber security are submitted in accordance with SEOJK Cyber.

Format 3.2.14
RESULTS OF CYBER SECURITY TESTING
BASED ON VULNERABILITY ANALYSIS
A. Testing Scope Information

Types of assets tested, including their environment (development or
production)
Testing objectives and testing methods (white box, black box or
grey box)
B. Findings Information
Explanation regarding the findings and their criticality level
Summary of the impact of findings on the Bank's business continuity
C. Findings Follow-up Status
D. Other Supporting Information (Attached)

Format 3.2.15
SELF-ASSESSMENT OF DIGITAL MATURITY LEVEL
No.
Format
Name of Information/Report Remarks
15.1 Working Paper on Quality Assessment of Digital Maturity Aspects
of the Bank
(Attached)
15.2 Results of Assessment of Bank Digital Maturity Level
(Attached)
Remarks:
All report formats and information are submitted in accordance with SEOJK DMAB.

Format 3.2.16
LIST OF BANK PARTNERS
IN CONDUCTING DIGITAL SERVICE COOPERATION
No. Bank Partner Name *) Type of Digital Service *) (1) (2) (3) Remarks:
(1) Fill in with serial number.
(2) Fill in with the name of the Bank partner company.
(3) Fill in with the type of service (example: account opening, balance information, product marketing).
*) The term "Bank Partner" refers to companies that cooperate with the Bank in the implementation of digital services in accordance with POJK regarding digital services by general banks.

Format 3.2.17
RESULTS OF ELECTRONIC SYSTEM IDENTIFICATION
A. General Information
General Bank Profile
1 Bank Name : (Fill in with the Bank company name) 2 Year : (Fill in with the year of identification implementation) 3 Bank Address : (Fill in with the Bank headquarters address) 4 List of functions, services or business processes implemented : (Fill in with business activities conducted, example: channeling third-party funds, raising third-party funds, conducting payment systems) 5 Number of end users served : (Can be filled with total CIF data) 6 Affected service population : (Can be filled with total customer account data) Contact Person 7 Contact Person Name : (Fill in with the name of the employee acting as the contact person for the identification implementation) 8 Contact Person Work Unit : (Fill in with the work unit/unit of the employee who is the contact person) 9 Contact Person Telephone : a. Telephone : (Fill in with the office telephone number of the contact person) b. Mobile Telephone : (Fill in with the telephone number of the contact person)
c. Email : (Fill in with the official email address of
the contact person)
Remarks:
Information on the results of Electronic System identification is submitted in order to fulfill the provisions of legislation regarding vital information infrastructure.

B. Identification of Electronic Systems Related to Vital Information Infrastructure No. Type of Electronic System Name of Electronic System Electronic System Services List of Data Managed Dependency Relationship and Third-Party Usage Service Continuity Plan (1) (2) (3) (4) (5) (6) (7) Category of Electronic System Result of Measurement of the Vitality Level of the Electronic System Sector Affected by the Electronic System Remarks Impact Operational Impact on Data and/or Information Impact Financial Impact General Interdependency Impact (Interdependency) (8) (9) (9) (9) (9) (9) (10) (11) Remarks:
(1) Fill in with serial number.
(2) Fill in with one of the following Types of Electronic Systems:

Core Banking System
Internet banking and/or mobile banking
(3) Fill in with the Name of the Electronic System identified. Example: Core Banking System Treasury.
(4) Fill in with a brief description and service function performed by the Electronic System.
Example: Electronic System processes daily transactions and manages customer data.
(5) Fill in with the list of data types managed by the Electronic System.
Example:
Customer Data
Transaction Data
Financial Data
(6) Fill in with information on the dependency relationship of the Electronic System with third parties (if any). Information regarding dependency relationships includes among others name, cooperation description, cooperation start date, and other relevant information. Example of third party is PPJTI in the management of the core banking system. (7) Fill in with the availability of service continuity plans (i.e., BCP/BCM). Example: The Bank has policies, standards, and procedures related to the Disaster Recovery Plan that includes Electronic System X. Disaster Recovery Plan testing is conducted at least once every 1 (one) year and was last conducted in mid-2025. (8) Fill in with the category of Electronic System, in accordance with the Regulation of the Cyber and Cryptography Agency regarding the identification of vital information infrastructure (Strategic, High, or Low).

Electronic System Category Explanation
Strategic Electronic Systems that impact public interest, public services, smoothness of state administration, or national defense and security High Electronic Systems that impact the interests of specific sectors and/or regions Low Electronic Systems that do not fall into the strategic and high categories (9) Fill in with the result of measuring the potential scale of impact if there is a disturbance, failure, damage, and/or destruction of the Electronic System, in accordance with the impact scale as regulated in the appendix of the Regulation of the Cyber and Cryptography Agency regarding the identification of vital information infrastructure (Serious, Significant, Limited, or Minor), including an explanation of the determination of the impact scale. Example:
Based on the identification results, the Electronic System has a significant impact on operations because the failure of the Electronic System results in the halt of transaction services in a specific province. (10) Fill in with the Sector affected if there is a failure or disturbance, including sectors:
a. government administration; b. energy and mineral resources;
c. transportation;
d. finance; e. health; f. information and communication technology; g. food; h. defense; and
i. other sectors determined by the President.
(11) Fill in with other relevant additional information.

Format 3.3
REPORT ON IT INTERNAL AUDIT RESULTS
A. Reporter Information
Bank Name : ...............................................
Bank Headquarters Address : ........................
Telephone Number : ………………………………….
Contact Person Name : ............................................
Contact Person Telephone Number : ..............................
Reporting Office/Division/Section: ...........
Reporting Office/Division/Section Address: .................................
Reporting Date: …./…./………. (dd/mm/yyyy)
B. IT Audit Results Report *)

Attach the details of the IT audit implementation team members.
If the IT audit is conducted by an external party, attach the cooperation agreement for the
audit implementation between the Bank and the external party.)
Provide information regarding the scope of the IT audit.
Provide an explanation of the IT weaknesses found, follow-up actions for resolution, and target completion times.
Remarks:
*) Special IT audits are conducted on IT-related aspects according to needs, priorities, and the Bank's IT risk analysis results ) Information includes service type, data provider (company name, Data Center address, company address, majority owner/group owner), date and duration of the agreement, contact person at the Bank handling the IT management service, and other important information

Format 3.4.1
EARLY NOTIFICATION OF IT INCIDENT (NON-CYBER)
A. BANK INFORMATION
Bank Name : .....................................................(1)
Bank Headquarters Address : ................................
(2)
Telephone Number : ……………………………………..…...
(3)
Contact Person Name : ...........................................(4)
Contact Person Telephone Number : ..............................
(5)
Authority/Agency Recipient : ..............................
(6)
B. GENERAL INFORMATION ON IT INCIDENT (NON-CYBER)

Date and Time of IT Incident Occurrence: (7)
…./…./………. (dd/mm/yyyy), … : …. (hh:mm)
Date and Time IT Incident Was Known: (8)
…./…./………. (dd/mm/yyyy), … : …. (hh:mm)
Type of IT Incident : ……………………………. (9)
Impacted System: ……………………….…(10)
Bank's Initial Response Post-IT Incident: ................................................ (11)
Initial Assessment of IT Incident Impact: ............................................
(12)
Notes:
(1) Filled with the Bank's name.
(2) Filled with the Bank's Headquarters Address.
(3) Filled with the Bank's Headquarters telephone number.
(4) Filled with the Contact Person's name, who is responsible for reporting the IT incident to the Bank.
(5) Filled with the Contact Person's Telephone Number as per item (4).
(6) Filled with the name of the authority and/or agency other than the Financial Services Authority that also receives this early notification report (if any). (7) Filled in the event the Bank has identified the date and time of the IT incident occurrence. (8) Filled with the date and time when the Bank knew an IT Incident was occurring. (9) Filled with information regarding the type of IT incident that occurred. Example: fire at the Bank's DC/DRC. (10) Filled with information regarding the name of the system or network that experienced disruption. (11) Filled with information regarding the initial handling actions taken by the Bank after the IT incident was known. (12) Filled in the event the impact of the IT incident has been identified by the Bank (among others, impact on Bank's service products, operations, financial, and/or reputation).

Format 3.4.2
IT INCIDENT REPORT (NON-CYBER)
A. REPORTER INFORMATION
Bank Name : ................................................(1) Bank Headquarters Address : ........................ (2) Telephone Number : …………………………………..(3) Contact Person Name : .....................................(4) Contact Person Telephone Number : .......................(5) Date of Early Notification Submission: …./…./………. (dd/mm/yyyy) (6) Authority/Agency Recipient : ...................... (7) B. GENERAL INFORMATION ON IT INCIDENT

Date and Time of IT Incident Occurrence: (8)
…./…./………. (dd/mm/yyyy), … : …. (hh:mm)
Date and Time IT Incident Was Known: (9)
…./…./………. (dd/mm/yyyy), … : …. (hh:mm)
Type of IT Incident : ………………….
(10)
Impacted System: ……………….(11)
Bank's Initial Response Post-IT Incident: ............................................ (12)
C. ASSESSMENT OF IT INCIDENT IMPACT ON THE BANK
Assessment of IT Incident Impact on Availability and Operational
Bank Services…......……………………………………………………………………(13)
Assessment of IT Incident Impact on Bank's Financials
………………………………………………………………………………………………(14)
Assessment of IT Incident Impact on Bank's Reputation
………………………………………………………………………………………………(15)
Assessment of IT Incident Impact on Bank's Legal and Compliance Aspects
……….………………………………………………………………………………(16)
Assessment of IT Incident Impact on Third Parties
………..……………………………………………………………………………………(17)
Assessment of Other Impacts of the IT Incident That Can Be Identified by
the Bank………………………………………………………………………………………(18)
D. CHRONOLOGICAL INFORMATION OF IT INCIDENT(19) E. ANALYSIS OF THE CAUSE OF THE INCIDENT(20)

Notes:
(1) Filled with the Bank's name.
(2) Filled with the Bank's Headquarters Address.
(3) Filled with the Bank's Headquarters telephone number.
(4) Filled with the Contact Person's Name, who is responsible for reporting the IT incident to the Bank.
(5) Filled with the Contact Person's Telephone Number as referred to in item (4).
(6) Filled with the date of submission of the Early Notification of the IT Incident.
(7) Filled with the name of the authority and/or agency other than the Financial Services Authority that also receives this early notification report (if any). (8) Filled in the event the Bank has identified the date and time of the IT incident occurrence. (9) Filled with the date and time when the Bank knew an IT Incident was occurring. (10) Filled with information regarding the type of IT incident that occurred. Example: fire at the Bank's DC/DRC. (11) Filled with information regarding the name of the system or network that experienced disruption. (12) Filled with information regarding the initial handling actions taken by the Bank after the IT incident was known. (13) Filled in the event there is an impact on the Bank's business, including in relation to the availability and operational services of the Bank. Information must contain at least:
a. type of service and/or name of the impacted product (example: treasury services, trade finance, cash management, and digital banking services); and b. explanation of the impact that occurred (if more than 1 (one) service and/or product is impacted, the explanation is provided for all impacted services and products). (14) Filled in the event there is a financial impact from the cyber incident. Information must contain at least:
a. what is impacted (example: value or volume of transactions, withdrawals, and Bank liquidity); and b. explanation of the impact that occurred (if the incident impacts more than 1 (one) item, the explanation is provided for all impacted items). (15) Filled in the event there is an impact on the Bank's reputation from the cyber incident (example: IT incident published by media). (16) Filled in the event there is an impact on legal and compliance aspects (example: violation of statutory regulations and existence of legal claims from related parties). (17) Filled in the event there is an impact on third parties of the Bank. Information must contain at least:
a. category of third party (example: customers, service providers, and service cooperation partners); and b. explanation of the impact that occurred (if the incident impacts more than 1 (one) category of partner, the explanation is provided for all impacted partners). (18) Filled with other matters impacted by the IT Incident. (19) Filled with the chronological explanation of the IT incident occurrence, which contains:
a. Duration of the IT incident. b. IT incident escalation steps taken.
c. IT incident mitigation steps taken.
d. IT incident recovery steps taken. e. Involvement of third parties in IT incident mitigation and recovery. f. Parties receiving information related to the IT incident (stakeholders, example: authorities, service partners, and customers). g. Other supporting information. (20) Filled with the Bank's identification results regarding the cause of the IT incident, including whether there are elements causing the IT incident. (21) Filled with information that can conclude the cause, chronology, and impact of the IT incident that occurred. F. FINAL ANALYSIS

Conclusion(21)
Improvement Steps(22)
IT Incident Resolution Target Time: …………… (dd/mm/yyyy )
(23)

This copy is in accordance with the original
Head of Legal Development Directorate
Legal Department signed.
Aat Windradi
(22) Filled with information regarding the steps taken by the Bank to prevent similar IT incidents from occurring in the future.
(23) Filled in the event the IT incident has not been fully resolved at the time of submitting the report to the Financial Services Authority.
EXECUTIVE HEAD OF BANKING SUPERVISOR
FINANCIAL SERVICES AUTHORITY
REPUBLIC OF INDONESIA,
DIAN EDIANA RAE signed.

APPENDIX IV
REGULATION OF THE BOARD OF COMMISSIONERS
OF THE FINANCIAL SERVICES AUTHORITY
REPUBLIC OF INDONESIA
NUMBER 1 OF 2026
CONCERNING
INFORMATION TECHNOLOGY MANAGEMENT BY COMMERCIAL BANKS

FORMAT FOR APPLICATION FOR PERMISSION AND REALIZATION REPORT

TABLE OF CONTENTS
Format 4.1 Application Form and Documents for Permission to Locate Electronic Systems at Data Centers and/or Disaster Recovery Centers Outside the Territory of Indonesia Format 4.2 Application Form and Documents for Realization Report of Locating Electronic Systems at Data Centers and/or Disaster Recovery Centers Outside the Territory of Indonesia Format 4.3 Application Form and Documents for Permission for IT-Based Transaction Processing by IT Service Providers Outside the Territory of Indonesia Format 4.4 Application Form and Documents for Realization Report of IT-Based Transaction Processing by IT Service Providers Outside the Territory of Indonesia Format 4.5 Application Form and Documents for Permission for IT Service Provision by Banks Format 4.6 Application Form and Documents for Realization Report of IT Service Provision by Banks

4.1 Format for Application Form and Documents for Permission to Locate
Electronic Systems at Data Centers and/or Disaster Recovery Centers Outside the Territory of Indonesia APPLICATION FOR PERMISSION TO LOCATE ELECTRONIC SYSTEMS AT DATA CENTERS AND/OR DISASTER RECOVERY CENTERS OUTSIDE THE TERRITORY OF INDONESIA

Applicant Information
Bank Name : ........................................................................................
Bank Headquarters Address : .................................................................
Telephone Number : ………..……………........................................................
Contact Person Name : .............................................................................
Contact Person Telephone Number : ...............................................................
Date of Application : …/…/…. (dd/mm/yyyy)
Information and Documents related to Data Center/Disaster Recovery Center
a) Data Center Location : ………………………………………........
b) Disaster Recovery Center
Location
: ………………………………………........
………………………………………........
c) Name of Data Center and/or
Disaster Recovery Center
Provider
: ………………………………………........
………………………………………........
………………………………………........
d) Address of Data Center and/or
Disaster Recovery Center
Provider
: ………………………………………........
………………………………………........
………………………………………........
e) Summary of the Bank's analysis of the results of independent IT audits on the security systems at the Data Center/Disaster Recovery Center.* )
Information and Documents related to Electronic Systems
a) Name of Electronic System : ………………………….........................
b) Function of Electronic System : ………………………….........................
c) Summary of the results of the needs analysis conducted by the Bank in the plan to use the Electronic System. d) Summary of the results of due diligence against the IT Service Provider, including analysis of performance, reputation, and continuity of service provision. Also attach a summary of:

the Bank's analysis of the results of independent IT audits on the development of application systems offered;
the Bank's risk analysis regarding the placement of Electronic Systems
at Data Centers and/or Disaster Recovery Centers outside the territory of Indonesia, including operational, legal, and reputational risks as well as country risk analysis;
analysis of security controls by the IT Service Provider to
ensure the fulfillment of confidentiality, integrity, availability, and authenticity against the Electronic System. e) Draft agreement between the Bank and the IT Service Provider. f) Summary of measurable cost-benefit analysis, which shows that the benefits for the Bank are greater than the costs charged by the IT Service Provider to the Bank.

g) IT architecture diagram related to the Electronic System, which illustrates the current condition and after implementation.
4. Summary of the Bank's analysis regarding the adequacy of the IT Service Provider's Disaster Recovery Plan.
5. Statement letter from the Bank regarding the Bank's willingness to provide
access to internal auditors, external auditors, and/or the Financial Services Authority to obtain data and information accurately and promptly whenever needed.
6. In the event the Bank is a branch office of a bank located outside the country or a Bank owned by a foreign financial institution, the Bank attaches:
a) Statement letter from the financial regulatory authority outside the country that the IT Service Provider is under its supervision; b) Statement letter of no objection from the financial regulatory authority outside the country if the Financial Services Authority intends to conduct an examination of the Data Center and/or Disaster Recovery Center; c) Statement letter that the Bank regularly submits the results of the assessment conducted by the Bank's office outside the territory of Indonesia on the application of risk management on the IT Service Provider; and d) Results of the assessment conducted by the Bank's office outside the territory of Indonesia on the application of risk management on the IT Service Provider.
7. Bank's Plan regarding the improvement of human resources capabilities related to
the management of Electronic Systems located at Data Centers/Disaster Recovery Centers outside the territory of Indonesia.
Notes:
*) Only submitted in the event the Bank is placing an Electronic System at the DC/DRC for the first time.

4.2 Format for Application Form and Documents for Realization Report of Locating
Electronic Systems at Data Centers and/or Disaster Recovery Centers Outside the Territory of Indonesia REALIZATION REPORT OF LOCATING ELECTRONIC SYSTEMS AT DATA CENTERS AND/OR DISASTER RECOVERY CENTERS OUTSIDE THE TERRITORY OF INDONESIA

Reporter Information
Bank Name : ...................................................................................
Bank Headquarters Address : ............................................................
Telephone Number : ……………................................…………………….....
Contact Person Name : .......................................................................
Contact Person Telephone Number : .........................................................
Date of Realization : …/…/…… (dd/mm/yyyy)
Information and Documents related to Data Center/Disaster Recovery Center
a) Data Center Location : …………………………...........
b) Disaster Recovery Center Location : …………………………...........
c) Name of Data Center and/or Disaster Recovery Center Provider
: …………………………...........
…………………………...........
…………………………...........
d) Address of Data Center and/or Disaster Recovery Center Provider
: …………………………...........
…………………………...........
…………………………...........
Information and Documents related to Electronic Systems
a) Name of Electronic System : …………………………...............
b) Function of Electronic System : …………………………...............
c) Results of the latest analysis of security controls used to ensure the fulfillment of confidentiality, integrity, and availability in the management entrusted to the IT Service Provider. d) Copy of the agreement between the Bank and the Data Center and/or Disaster Recovery Center Provider. e) Description of the Bank's latest risk analysis regarding the management of Data Centers and/or Disaster Recovery Centers by the IT Service Provider outside the territory of Indonesia, including operational, legal, and reputational risks, as well as country risk analysis.
Results of post-implementation review (PIR) on the
use of the IT Service Provider's Data Center, which among others includes the results of re-evaluation regarding:
a) System performance (system performance review); b) Compliance with user requirements (user requirement); c) Problems that occurred along with solutions, escalation, or steps taken for resolution; and d) Effectiveness of the established security measures.
Results of testing on the use of the Disaster Recovery Center
managed by the IT Service Provider.
Minutes of the transfer of the Data Center and/or Disaster Recovery Center.
Latest IT architecture diagram after the management of the Data Center
and/or Disaster Recovery Center is handed over to the IT Service Provider.

4.3 Format for Application Form and Documents for Permission for IT-Based
Transaction Processing by IT Service Providers Outside the Territory of Indonesia APPLICATION FOR PERMISSION FOR PROCESSING TRANSACTIONS BASED ON INFORMATION TECHNOLOGY BY INFORMATION TECHNOLOGY SERVICE PROVIDERS OUTSIDE THE TERRITORY OF INDONESIA

Applicant Information
Bank Name : .......................................................................................
Bank Headquarters Address : ................................................................
Telephone Number : …………….............................…………………….............
Contact Person Name : .............................................................................
Contact Person Telephone Number : ..............................................................
Date of Application : …/…/…… (dd/mm/yyyy)
Description or explanation and flow chart of the Standard Operating Procedures (SOP) of the products and activities that
the management of which will be entrusted to the IT Service Provider.
Information and Documents related to Data Center/Disaster Recovery Center
a) Data Center Location : …………………………............
b) Disaster Recovery Center Location : …………………………............
Information and Documents related to Transaction Processing
a) Location of
IT-Based Transaction
Processing
: ……………………………………………… b) Name of Provider of
IT-Based Transaction
Processing
: ……………………………………………… c) Address of Provider of IT-Based Transaction Processing : ……………………………………………… d) Summary of the results of the needs analysis conducted by the Bank in the plan to use the Electronic System. e) Summary of the results of due diligence against the IT Service Provider, including analysis of performance, reputation, and continuity of service provision. Also attach a summary of:

the Bank's analysis of the results of independent IT audits on the development of application systems that will
be used to process transactions by the IT Service Provider.
the Bank's risk analysis regarding the plan to entrust
the management of IT-based transaction processing to the IT Service Provider, including operational, legal, and reputational risks, as well as country risk analysis; and
analysis of security controls by the IT Service Provider to
ensure the fulfillment of confidentiality, integrity, availability, and authenticity. f) Draft agreement between the Bank and the IT Service Provider g) Summary of measurable cost-benefit analysis, which among others includes:
benefits for the Bank are greater than the costs charged by
the IT Service Provider to the Bank; and
assessment of the adequacy and suitability of the application systems that will
be used with the Bank's needs. h) Diagram of the current and post-implementation reporting and information flow.

Summary of the Bank's analysis regarding the adequacy of the IT Service Provider's Disaster Recovery Plan.
Statement letter from the Bank regarding the Bank's willingness to provide
access to internal auditors, external auditors, and/or the Financial Services Authority to obtain data and information accurately and promptly whenever needed.
Bank's Plan regarding the application of customer protection aspects for
products whose processing is entrusted to the IT Service Provider.
Bank's Plan regarding the enhancement of the Bank's role for the development of
the Indonesian economy through the business plan.

4.4 Format for Application Form and Documents for Realization Report of IT-Based
Transaction Processing by IT Service Providers Outside the Territory of Indonesia REALIZATION REPORT OF PROCESSING TRANSACTIONS BASED ON INFORMATION TECHNOLOGY BY INFORMATION TECHNOLOGY SERVICE PROVIDERS OUTSIDE THE TERRITORY OF INDONESIA

Reporter Information
Bank Name : ...............................................................................
Bank Headquarters Address : .......................................................
Telephone Number : ……………................................…………………….
Contact Person Name : ...................................................................
Contact Person Telephone Number : .....................................................
Date of Realization : …/…/…… (dd/mm/yyyy)
Information and Documents related to Data Center/Disaster Recovery Center
a) Data Center Location : ………………………….. b) Disaster Recovery Center Location : …………………………..
Information and Documents related to Transaction Processing
a) Location of IT-Based Transaction
Processing
: …………………………..
………………………….. b) Name of Provider of IT-Based
Transaction Processing
: …………………………..
………………………….. c) Address of Provider of IT-Based Transaction Processing : …………………………..
………………………….. d) Results of the latest analysis of security controls used to ensure the fulfillment of confidentiality, integrity, and availability in the management of IT-based transaction processing entrusted to the IT Service Provider. e) Copy of the agreement between the Bank and the service provider of IT-based transaction processing management outside the territory of Indonesia. f) Description or explanation and flow chart of the Standard Operating Procedures (SOP) of the products and activities of the Bank whose management is entrusted to the IT Service Provider.
Results of post-implementation review (PIR) on the
use of the IT Service Provider in managing IT-based transaction processing, which among others includes the results of re-evaluation regarding:
a) System performance (system performance review); b) Compliance with user requirements (user requirement); c) Problems that occurred along with solutions, escalation, or steps taken for resolution; and d) Effectiveness of the established security measures.
Results of testing on the use of IT-based transaction processing management
outside the territory of Indonesia.
Minutes of the transfer of IT-based transaction processing management.
Diagram of the current reporting and information flow after
the management of IT-based transaction processing is entrusted to the IT Service Provider.

4.5 Format for Application Form and Documents for Permission for IT Service Provision
by Banks
APPLICATION FOR PERMISSION
FOR IT SERVICE PROVISION BY BANKS
A. Applicant Information
Bank Name : ..........................................................................................
Bank Headquarters Address : ...................................................................
Telephone Number : ………..……………..........................................................
Contact Person Name : .............................................................................
Contact Person Telephone Number : .................................................................
Date of Application : …/…/…… (dd/mm/yyyy)
B. Information and Documents related to IT Service Provision by Banks

Type of IT services to be provided by the Bank:
No. Type of IT Service Yes/No *)
1 Data Center
2 Disaster Recovery Center
3 Communication Network
4 Application Services
5 Others: .... (specify)
Recipients of IT services
a. Company name : .....................................................
b. Address : .....................................................
c. Brief business description : .....................................................
d. Relationship with the Bank : .....................................................
General information related to IT services to be provided by the Bank
a. Location of management
Data Center : .....................................................
Disaster Recovery Center : .....................................................
b. List of IT services in the form of application services provided by the Bank No. Type of Application Service Name of Application Service Description and Purpose of Application Service 1 Example:
Digital Mobile IM Service
…
2 Example: Employee
Remuneration System
SiRemun
…
… … … …
… … … …
If the Bank provides IT services in the form of Data Centers and/or Disaster Recovery Centers, attach an analysis of the adequacy of the capacity of the Bank's Data Centers and/or Disaster Recovery Centers (example: rooms and networks) for the Bank's business needs in the future by taking into account the capacity of Data Centers and/or Disaster Recovery Centers provided by the Bank to other parties.
Cost-benefit analysis of IT service provision that can
show that the benefits for the Bank exceed the costs of IT service provision.
Risk analysis regarding the provision of IT services containing at least
operational, reputational, legal, compliance, and strategic aspects as well as mitigation that the Bank must carry out to ensure the fulfillment of

confidentiality, integrity, availability, and authenticity regarding the provision of IT services
7. Concept of agreement between Bank and IT service users.
Description:
*) Choose one according to the planned IT service provision.

4.6 Format of Forms and Documents for Reports on IT Service Provision Realization by Banks

REPORT ON IT SERVICE PROVISION REALIZATION BY BANKS

A. Reporter Information
Bank Name : ……………….………………......
Head Office Address : ……………….………………......
Telephone Number : ……………….………………......
Contact Person Name : ……………….………………......
Contact Person Telephone Number : ……………….………………......
Reporting Date : …/…/…… (dd/mm/yyyy)

B. Realization Report

Types of IT services provided by the Bank
a. Data Center
Realization Date (dd/mm/yyyy)
Agreement Document (document number and date)
Cooperation period (dd/mm/yyyy to dd/mm/yyyy) b. Disaster Recovery Center Realization Date (dd/mm/yyyy) Agreement Document (document number and date) Cooperation period (dd/mm/yyyy to dd/mm/yyyy)
c. Communication Network
Realization Date (dd/mm/yyyy)
Agreement Document (document number and date)
Cooperation period (dd/mm/yyyy to dd/mm/yyyy) d. Application Services Realization Date (dd/mm/yyyy) Agreement Document (document number and date) Cooperation period (dd/mm/yyyy to dd/mm/yyyy) e. Other IT Service Provisions Realization Date (dd/mm/yyyy) Agreement Document (document number and date) Cooperation period (dd/mm/yyyy to dd/mm/yyyy)
IT service users
a. Company name : ……………….………………. b. Address : ……………….……………….
c. Brief business description : ……………….……………….
d. Relationship with the Bank : ……………….……………….
General information related to IT services provided by the Bank
a. Implementation location
Data Center : ……………….……………….
Disaster Recovery Center : ……………….……………….

This copy is consistent with the original
Head of Legal Development Directorate
Legal Department signed.
Aat Windradi

b. List of application services provided by the Bank:
No. Type of Application Service
Application Name
Service Description and Purpose
1 Example:
Digital Services
Mobile IM …
2 Example:
Employee Remuneration System
SiRemun ...
3 … … …
4 … … …

Agreements between the Bank and financial service institution users who have realized the use of IT service offerings.
Minutes of the provision of IT services provided by the Bank that have been used by financial service institutions.
Results of post-implementation review (PIR) regarding the provision of IT services by the Bank, which among others cover the results of review regarding:
a. System performance (system performance review); b. Compliance with user needs (user requirement);
c. Issues that occurred along with solutions, escalation, or resolution steps taken;
d. Effectiveness of established security measures; and e. Fulfillment of Service Level Agreement/SLA.

EXECUTIVE HEAD OF BANKING SUPERVISOR
FINANCIAL SERVICES AUTHORITY
REPUBLIC OF INDONESIA,
DIAN EDIANA RAE signed.

Regulation of the Board of Commissioners of the Financial Services Authority Number 1 of 2026 on Information Technology Management by Commercial Banks

Lineage: In force

Similar documents from other regulators