Implementation of Risk Management in the Use of Information Technology by Universal Banks

To:

The Board of Directors of Conventional Universal Banks; and
The Board of Directors of Sharia Universal Banks,
At their respective locations.

COPY
CIRCULAR LETTER OF THE FINANCIAL SERVICES AUTHORITY NUMBER 21/SEOJK.03/2017 CONCERNING THE IMPLEMENTATION OF RISK MANAGEMENT IN THE USE OF INFORMATION TECHNOLOGY BY UNIVERSAL BANKS

In light of the implementation of Financial Services Authority Regulation Number 38/POJK.03/2016 concerning the Implementation of Risk Management in the Use of Information Technology by Universal Banks (State Gazette of the Republic of Indonesia Year 2016 Number 267, Supplement to the State Gazette of the Republic of Indonesia Number 5963), hereinafter abbreviated as POJK MRTI, it is necessary to regulate implementation provisions regarding the implementation of risk management in the use of Information Technology by universal banks in this Circular Letter of the Financial Services Authority as follows:

I. GENERAL PROVISIONS

Guidelines for the implementation of risk management in the use of Information Technology by universal banks serve as a standard reference for the implementation of risk management in the use of Information Technology by Banks.
Banks that have had policies, standards, and procedures in the use of Information Technology and/or information technology risk management guidelines prior to the implementation of this Financial Services Authority Circular Letter must adjust and refine them with reference to Appendix I, which is an integral part of this Financial Services Authority Circular Letter.

II. GUIDELINES FOR RISK MANAGEMENT IN THE USE OF INFORMATION TECHNOLOGY

In order to implement information technology risk management to support the continuity of Bank business, particularly services to customers, Banks are required to have policies, standards, and procedures for the use of Information Technology and are required to implement such policies, standards, and procedures for the use of Information Technology consistently and continuously as regulated in Article 8 paragraph (1) of POJK MRTI.
Policies, standards, and procedures for the use of Information Technology as well as guidelines for information technology risk management refer to Appendix I, which is an integral part of this Financial Services Authority Circular Letter, and refer to Financial Services Authority Circular Letter Number 34/SEOJK.03/2016 concerning the Implementation of Risk Management for Universal Banks.
Policies, standards, and procedures for the use of Information Technology must at least cover the following aspects:
a. management; b. development and procurement;
c. Information Technology operations;
d. communication networks; e. information security; f. Disaster Recovery Plan; g. Electronic Banking Services; h. use of third-party Information Technology service providers; and
i. provision of Information Technology services by the Bank.
The aspects of policies, standards, and procedures for the use of Information Technology as referred to in item 3 must be implemented by the Bank to mitigate risks related to the conduct of Information Technology.
Banks with large business size and complexity may use additional parameters from those regulated in the guidelines as referred to in Appendix I, which is an integral part of this Financial Services Authority Circular Letter.

III. REPORTING

In implementing information technology risk management, Banks submit the following reports:
a. Current status report on the use of Information Technology with the following provisions:

The report uses the format as referred to in Appendix 2.1, which is an integral part of this Financial Services Authority Circular Letter.
The report is submitted no later than 1 (one) month after the end of the reporting year.
b. Report on the Information Technology development plan to be implemented in the next 1 (one) year with the following provisions:
The report uses the format as referred to in Appendix 2.2, which is an integral part of this Financial Services Authority Circular Letter.
The report is submitted no later than October 31 of the previous year.
The report may be amended 1 (one) time and submitted no later than June 30 of the current year.
Requests to amend the Information Technology development plan report may be submitted outside the time frame as referred to in item 3) provided that specific considerations are met and approval is obtained from the Financial Services Authority.
c. Realization report:
activities as an Information Technology service provider;
issuance of Electronic Banking Service products;
conduct of Electronic Systems located in Data Centers and/or Disaster Recovery Centers outside Indonesian territory; and
conduct of Information Technology-Based Transaction Processing to third-party service providers outside Indonesian territory;
with the following provisions:
i. The report uses the format as referred to in Appendix 2.4, which is an integral part of this Financial Services Authority Circular Letter.
ii. The report is submitted no later than 3 (three) months after implementation.
d. Incident report regarding critical events, abuse, and/or crimes in the conduct of Information Technology that can and/or have resulted in significant financial losses and/or disrupted the smoothness of Bank operations, with the following provisions:
The report uses the format as referred to in Appendix 2.5, which is an integral part of this Financial Services Authority Circular Letter.
The report is submitted immediately to the Financial Services Authority via electronic mail or telephone, followed by a written report no later than 7 (seven) working days after the critical event and/or abuse or crime is known.
e. Information Technology audit results report with the following provisions:
The report uses the format as referred to in Appendix 2.6, which is an integral part of this Financial Services Authority Circular Letter.
The report is submitted no later than 2 (two) months after the Information Technology audit is completed.

Banks that entrust the conduct of Information Technology to Information Technology service providers must still submit reports as referred to in item 1 to the Financial Services Authority.

IV. REQUEST FOR APPROVAL

Banks that have plans for activities as Information Technology service providers and/or issue Electronic Banking Service products must submit a request for approval to the Financial Services Authority no later than 2 (two) months before implementation.
Banks that conduct Electronic Systems located in Data Centers and/or Disaster Recovery Centers outside Indonesian territory as well as Banks that entrust the conduct of Information Technology-Based Transaction Processing to third-party service providers outside Indonesian territory must submit a request for approval to the Financial Services Authority no later than 3 (three) months before the implementation plan.

This copy is consistent with the original
Legal Director 1
Legal Department signed
Yuliana

The approval request in items 1 and 2 is accompanied by documents as listed in Appendix 2.3, which is an integral part of this Financial Services Authority Circular Letter.

V. CLOSING

Provisions in this Financial Services Authority Circular Letter shall take effect on the date of determination.

Determined in Jakarta on June 6, 2017
EXECUTIVE HEAD OF BANKING SUPERVISOR
FINANCIAL SERVICES AUTHORITY, signed
NELSON TAMPUBOLON

APPENDIX I
FINANCIAL SERVICES AUTHORITY CIRCULAR LETTER
NUMBER 21/SEOJK.03/2017
CONCERNING
THE IMPLEMENTATION OF RISK MANAGEMENT IN THE USE OF INFORMATION TECHNOLOGY BY UNIVERSAL BANKS

GUIDELINES FOR THE IMPLEMENTATION OF RISK MANAGEMENT IN THE USE OF INFORMATION TECHNOLOGY BY UNIVERSAL BANKS

TABLE OF CONTENTS
FOREWORD ........................................................................................4
CHAPTER I MANAGEMENT........................................................................................5
1.1. Introduction ................................................................................................. 5
1.2. Roles and Responsibilities of Management ........................................................ 5
1.2.1. Board of Directors.................................................................................................. 5
1.2.2. Board of Commissioners ...................................................................................... 6
1.2.3. IT Steering Committee....................................................................................... 6
1.2.4. Highest Official Leading the IT Work Unit........................................................ 8
1.3. Organizational Structure of the IT Work Unit............................................................ 10
1.4. Management Information System....................................................................... 11
1.5. Project Management....................................................................................... 11
1.6. IT Strategic Plan .................................................................................... 12
1.7. IT Management Policies, Standards, and Procedures ........................................ 13
1.8. IT Risk Management Process......................................................................... 14
1.8.1. Identification of Risk Types Related to IT Management ................................... 14
1.8.2. Risks Related to IT.................................................................................. 15
1.8.3. IT Risk Assessment .............................................................................. 15
1.8.4. Measurement of Risks Related to IT.............................................................. 16
1.8.5. Monitoring of Risks Related to IT............................................................. 18
1.8.6. Control of Risks Related to IT............................................................. 19
CHAPTER II DEVELOPMENT AND PROCUREMENT ..................................................21
2.1. Introduction ............................................................................................... 21
2.2. Control Steps in Development and Procurement ..................... 21
2.3. Policies, Standards, and Procedures for Development and Procurement .............. 22
2.3.1. Policies, Standards, and Procedures for Development.............................. 23
2.3.1.1. Initiation and Planning Stage .............................................. 23
2.3.1.2. User Needs Definition Stage.............................. 24
2.3.1.3. System Design Stage...................................................... 25
2.3.1.4. Programming Stage................................................................ 25
2.3.1.5. Testing Stage ........................................................................ 26
2.3.1.6. Implementation Stage ................................................................ 27
2.3.1.7. Post-Implementation Review Stage....................................... 28
2.3.1.8. Maintenance Stage ................................................................ 28
2.3.1.9. Disposal Stage................................................. 30
2.3.2. Policies, Standards, and Procedures for Procurement .................................... 30
2.3.2.1. Procurement Standards .............................................................. 31
2.3.2.2. Procurement Project Guidelines................................................. 32
2.3.2.3. Escrow Agreement ................................................................ 33
2.3.2.4. Software Purchase, Licensing, and Maintenance Contracts................................................................................... 34
2.3.2.5. Maintenance ....................................................................... 35
2.3.2.6. Warranty ................................................................................ 36
2.3.2.7. Dispute Resolution..................................................... 36
2.3.2.8. Contract Changes........................................................... 36
2.3.2.9. Security............................................................................ 36
2.3.2.10. Subcontracting to Vendors .................................................. 37
2.3.3. Policies, Standards, and Procedures for Project Management and Change Management..................................................................... 37
2.4. Risk Management Process for Development and Procurement........................... 40
2.4.1. Measurement of Risks Related to Development and Procurement................. 40
2.4.2. Control of Risks in Development and Procurement.................. 41
2.4.2.1. Risk Control in Development................................ 42
2.4.2.2. Risk Control in Procurement ...................................... 43
CHAPTER III IT OPERATIONAL ACTIVITIES ..........................................................44
3.1. Introduction ............................................................................................... 44
3.2. Policies, Standards, and Procedures Related to IT Operational Activities .............. 44
3.2.1. Policies Related to Data Centers............................................................ 45
3.2.2. IT Capacity Planning and Monitoring Policies..................... 47
3.2.3. Hardware and Software Configuration Management Policies............................................................................................... 47
3.2.4. Hardware and Software Maintenance Policies ................................ 48
3.2.5. Change Management Policies ................................................................ 49
3.2.6. Incident or Problem Handling Policies ....................................... 50
3.2.7. Database Management Policies................................................................ 51
3.2.8. Information Exchange Control Policies ................................................................ 52
3.2.9. Library Management Policies................................................................ 52
3.2.10. Hardware and Software Disposal Policies............................................................................................... 53
3.3. IT Operational Activity Risk Management Process ...................................... 53
CHAPTER IV COMMUNICATION NETWORKS................................................................56
4.1. Introduction ............................................................................................... 56
4.2. Policies, Standards, and Procedures Related to Communication Networks.................. 56
4.3. Communication Network Risk Management Process .......................................... 57
4.3.1. Risk Control............................................................................ 57
4.3.2. Risk Monitoring............................................................................. 60
CHAPTER V INFORMATION SECURITY................................................................62
5.1. Introduction ............................................................................................... 62
5.2. Policies, Standards, and Procedures Related to Information Security ............... 62
5.2.1. Information Security Policies....................................................................... 63
5.2.2. Information Security Standards................................................................ 64
5.2.3. Information Security Procedures ................................................................ 64
5.2.3.1. Asset Management Procedures....................................................... 64
5.2.3.2. Human Resources Management Procedures .......................... 65
5.2.3.3. Physical and Environmental Security Procedures .......................... 66
5.2.3.4. Access Control Procedures .................................................. 67
5.2.3.5. IT Operational Security Procedures ..................................... 69
5.2.3.6. Information Security Monitoring Procedures......................... 70
5.2.3.7. Information Security Incident Handling Procedures .. 71
5.3. Risk Management Process Related to Information Security............................. 74
5.3.1. Information Security Risk Measurement......................................... 74
5.3.2. Risk Control and Mitigation................................................................ 74
CHAPTER VI DISASTER RECOVERY PLAN.....................................................76
6.1. Introduction ............................................................................................... 76
6.2. Policies, Standards, and Procedures Related to Disaster Recovery Plan...... 76
6.2.1. Policies Related to Disaster Recovery Plan.................................. 76
6.2.2. Procedures Related to Disaster Recovery Plan ................................... 80
6.3. Testing of Disaster Recovery Plan ...................................................... 83
6.3.1. Scope of Disaster Recovery Plan Testing .................... 83
6.3.2. Disaster Recovery Plan Test Plan (Test Plan).............. 84
6.3.3. Analysis and Disaster Recovery Plan Testing Results Report .. 84
6.4. Disaster Recovery Plan Maintenance and Internal Audit...................... 84
6.4.1. Disaster Recovery Plan Maintenance ....................................... 84
6.4.2. Internal Audit ........................................................................................ 85
CHAPTER VII ELECTRONIC BANKING SERVICES .............................................86
7.1. Introduction ............................................................................................... 86
7.2. Policies, Standards, and Procedures Related to Electronic Banking Services ... 86
7.3. Electronic Banking Service Risk Management ...................................... 88
7.3.1. Measurement of Risks Related to Electronic Banking Services ................ 88
7.3.2. Control of Risks Related to Electronic Banking Services ............... 91
7.3.2.1. Risk Control for Specific Electronic Banking Services ................................................................ 96
7.3.2.2. Risk Control Related to Cross-Border Electronic Banking Services ................................................................ 98
7.3.2.3. Risk Control Related to Electronic Banking Services Conducted by IT Service Providers ................................................................ 98
7.4. Plan for Issuing New Electronic Banking Services........................... 99
7.5. Request for Approval Related to Electronic Banking Services ................ 99
7.6. Electronic Banking Service Realization ................................................... 100
7.6.1. Examination by Independent Parties................................................. 100
7.6.2. Scope of Independent Party Examination ............................... 101
CHAPTER VIII IT INTERNAL AUDIT ........................................................................103
8.1. Introduction ............................................................................................. 103
8.2. Policies, Standards, and Procedures Related to IT Audit..................................... 103
8.3. IT Audit Process........................................................................................... 105
8.4. Fulfillment of IT Internal Audit Functions ............................................................ 108
CHAPTER IX USE OF THIRD-PARTY IT SERVICE PROVIDERS ......................................109
9.1. Introduction ............................................................................................. 109
9.2. Policies, Standards, and Procedures for Use of IT Service Providers .............. 109
9.2.1. Policies for Use of IT Service Providers .......................................... 109
9.2.2. Standards for Use of IT Service Providers.............................................. 111
9.2.3. Procedures for Use of IT Service Providers ............................................ 114
9.3. Risk Management Process........................................................................... 119
9.3.1. Risk Identification ............................................................................. 119
9.3.2. Risk Measurement............................................................................ 120
9.3.3. Risk Mitigation .................................................................................. 121
9.3.4. Other Risk Controls ............................................................ 122
9.4. Internal Control and Internal Audit ........................................................ 123
9.4.1. Monitoring and Supervision of IT Service Providers ............................... 123
9.4.2. Internal Audit ...................................................................................... 123
CHAPTER X PROVISION OF IT SERVICES BY BANKS .................................................125
10.1. Introduction ........................................................................................... 125
10.2. Policies, Standards, and Procedures for Provision of IT Services............................. 125
10.2.1. Policies for Provision of IT Services by Banks........................................ 125
10.2.2. Standards for Provision of IT Services by Banks ........................................... 126
10.2.3. Procedures for Provision of IT Services by Banks.......................................... 127
10.2.4. Creation of IT Service Provision Agreements by Banks ..................... 128
10.3. Risk Management Process......................................................................... 129
10.3.1. Risk Identification ........................................................................... 129
10.3.2. Risk Measurement and Mitigation...................................................... 129

FOREWORD
Information Technology (IT) currently plays a very important role in banking activities. From initially serving only as a support for Bank operational activities, it has now become a determinant of the direction of Bank operational activities. This is reflected, among other things, by the increasing number of banking products and activities that utilize the use of IT, which is expected to improve services to customers amidst increasingly tight competition among Banks. The reliability of a Bank in managing IT also determines the Bank's success in producing information that is complete, accurate, up-to-date, timely, and relevant. Thus, the information produced can support the Bank's decision-making process and business operations. The use of IT, in addition to increasing the speed and accuracy of transactions and services to customers, also increases risks such as operational risk, reputational risk, legal risk, compliance risk, and strategic risk. Therefore, it is expected that Banks have an integrated risk management system to identify, measure, monitor, and control risks. However, given the differences in market conditions, structure, size, and complexity of Bank businesses, there is no universal risk management system for all Banks, so each Bank must build a risk management system that is appropriate to the function and organization of the Bank's risk management. This guideline constitutes the main points of implementing risk management in the use of IT that must be applied by Banks to mitigate risks related to IT operations. Banks with large business size and complexity should be able to use additional parameters from those regulated in this guideline. Banks are also expected to apply this risk management framework by paying attention to legislation, established standards, and best practices to ensure that adequate risk management has been implemented.

CHAPTER I MANAGEMENT
1.1. Introduction
IT is an important part in supporting Bank business, both for conducting transaction processes with customers and for supporting internal Bank activities. In order to minimize the occurrence of risks related to the use of IT and to protect the interests of the Bank and customers, the Bank needs to implement Information Technology governance. The success of implementing IT governance depends very much on the commitment of the Board of Directors, Board of Commissioners, and all work units in the Bank, both IT organizers and users. The implementation of IT governance is carried out through the alignment of the IT Strategic Plan with the Bank's business strategy, optimization of resource management, utilization of IT, performance measurement, and the application of effective risk management. The realization of the commitment of the Board of Directors and Board of Commissioners in the form of active supervision by the Board of Directors and Board of Commissioners over IT management as regulated in Article 2 of POJK MRTI. In this regard, it is necessary to have a policy containing the roles and responsibilities of the Board of Directors, Board of Commissioners, and top IT officials to ensure the effective implementation of IT risk management.

1.2. Roles and Responsibilities of Management
Pursuant to Article 4 of POJK MRTI, Banks are required to establish clear authorities and responsibilities of the Board of Directors, Board of Commissioners, and officials at each level of position related to the use of IT.

1.2.1. Board of Directors
In addition to the authorities and responsibilities for the Board of Directors as regulated in Article 5 of POJK MRTI, the authorities and responsibilities for the Board of Directors may also include:
a. ensuring the availability of sufficient and competent human resources (HR) according to needs; b. ensuring efforts to improve the competence of HR related to IT operations, including through adequate education or training and education programs to increase awareness of information security;
c. ensuring that the organizational structure of project management for all IT-related projects is used to the fullest extent; and
d. ensuring that the Bank has a written contract that regulates the roles, relationships, obligations, and responsibilities of all parties bound by the contract, and has the conviction that the contract is a legally binding agreement that protects the interests of the Bank, in the event the Bank uses the services of third parties.

1.2.2. Board of Commissioners
In addition to the authorities and responsibilities for the Board of Commissioners as regulated in Article 6 of POJK MRTI, the authorities and responsibilities for the Board of Commissioners may also include:
a. evaluating, directing, and monitoring risk management policies in the field of IT and the suitability of their implementation with the Bank's characteristics, complexity, and risk profile; b. providing improvement directions on the implementation of risk management policies in the field of IT;
c. conducting evaluations of planning and implementation of audits, ensuring audits are carried out with adequate frequency and scope, and monitoring follow-up on audit results related to information systems; and
d. conducting evaluations of reliable and effective security management over IT to guarantee availability, confidentiality, and accuracy of information.

1.2.3. IT Steering Committee
Pursuant to Article 7 of POJK MRTI, Banks are required to have an IT steering committee. This also applies to branches of banks located outside the country. The function of the IT steering committee can be carried out by a similar function located at the head office or regional bank office. In carrying out its duties, the IT steering committee needs to have an Information Technology steering committee charter that lists the authorities and responsibilities of the IT steering committee. To be able to carry out its duties effectively and efficiently, the IT steering committee needs to hold regular meetings to discuss matters related to IT strategy, which are documented in the form of meeting minutes. The authorities and responsibilities of the IT steering committee as regulated in Article 7 of POJK MRTI are to provide recommendations to the Board of Directors, at least related to:
a. IT Strategic Plan that is in line with the strategic plan of the Bank's business activities. In providing recommendations, the IT steering committee must consider factors of efficiency, effectiveness, and other matters, namely:

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 reach the desired state;
resources needed;
benefits to be obtained when the IT Strategic Plan is implemented; and
obstacles that may arise in the implementation of the IT Strategic Plan;
b. formulation of main IT policies, standards, and procedures, such as the main IT policy, namely IT security policy and risk management related to the use of IT in the Bank;
c. suitability between approved IT projects and the IT Strategic Plan. The IT steering committee also sets the priority status of critical IT projects that have a significant impact on Bank operational activities, such as the replacement of core banking applications, production servers, and network topology;
d. suitability between the implementation of IT projects and the agreed project plan (project charter). The IT steering committee must complete recommendations with analysis results from main IT projects so that the Board of Directors can make decisions efficiently; e. suitability between IT and the needs of the Management Information System as well as the needs of the Bank's business activities; f. effectiveness of steps in minimizing risks over the Bank's investment in the IT sector so that the Bank's investment in the IT sector contributes to achieving the Bank's business objectives; g. monitoring of IT performance and efforts to improve IT performance, such as detecting IT infrastructure obsolescence and measuring the effectiveness and efficiency of implementing IT security policies; h. efforts to resolve various IT-related problems that cannot be resolved effectively, efficiently, and in a timely manner by the user and organizer work units; and
i. adequacy and allocation of 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 operations, the IT steering committee must ensure that the Bank has the necessary policies and procedures.

1.2.4. Top Official Leading the IT Work Unit
In Article 7 of POJK MRTI, it is regulated that one of the members of the IT steering committee is the top official leading the IT work unit. Considering the complexity of the Bank's business, this position can be held by the IT Director or the head of the IT work unit. The main authorities and responsibilities of the top official leading the IT work unit include at least:
a. formulating IT policies, plans, and budgets; b. coordinating the development of Bank IT according to the established strategic plan;
c. implementing all IT policies, standards, and procedures as well as plans established by the Board of Directors;
d. providing support for IT services to IT user work units to achieve business targets responsively and in a timely manner; e. ensuring that every information owned by IT user work units receives good protection against all disturbances that can cause losses due to leaks of data or important information; 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 development or modification of IT systems; h. reporting to the Board of Directors regarding periodic IT implementation reports. If necessary, it can also propose actions to overcome 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 implementation of Service Level Agreements (SLA) between IT work units and user work units or IT service providers;
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 HR in both IT operations and the application of risk management, and guaranteeing the maintenance of HR 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 field of IT, in the event the top official who directly supervises IT is a director. If the top official is not a director, supervision can be carried out by the director who supervises both fields;
m. being responsible for the preparation and implementation of IT architecture and other strategic plans that significantly affect Bank capital, in the event the top official is the IT Director. The IT Director must ensure that the organizational structure of project management for all IT-related projects is used to the fullest extent. If there is no official filling the position of IT Director, this becomes the responsibility of the director who supervises the IT work unit, for example, if the IT work unit is under the operational director, then this function becomes the responsibility of the operational director; and n. ensuring that written contracts between the Bank and IT service providers cover matters regulated for the use of IT service providers.

1.3. Organizational Structure of IT Work Unit
The Bank needs to have an organizational structure that is appropriate to the needs of IT operations and use, paying at least attention to:
a. the organizational structure specifically describes the lines of authority, reporting, and responsibility for each IT function owned, including the person designated as a replacement; b. an organizational structure that does not open opportunities for anyone independently to commit and/or hide errors or deviations in the implementation of duties and can disable system security facilities;
c. the principle of segregation of duties and responsibilities to prevent someone from having responsibility for different and critical functions, such that errors are not easily detected, for example, appointing different employees as the administrator of information security and the person responsible for IT development with employees carrying out IT operational activities;
d. other forms of supervision or compensating controls to prevent errors related to IT operations, for banks with relatively small business scale or branches in remote areas that cannot implement adequate segregation of duties and responsibilities (segregation of incompatible duties) either wholly or partially. In determining the form of compensating controls to be applied, the Bank needs to pay attention to data ownership, transaction authorization responsibility, and data access rights, for example, compensating controls include audit trails, reconciliation, exception reporting, transaction logs, supervisory review, and independent review. Even if compensating controls are applied, IT operations must still be based on the principle of prudence; e. personnel placement considers HR competence, including knowledge and expertise, appropriate to the position or duties; f. division of responsibilities and setting of targets are well formulated among the risk management function and the functional fields of IT operations.

1.4. Management Information System
In Article 7 of POJK MRTI, it is regulated that the IT steering committee is responsible for providing recommendations to the Board of Directors, among others regarding the suitability between IT and the needs of the Management Information System (MIS) as well as the needs of the Bank's business activities, so that the Bank needs to ensure the availability of an MIS that can generate the information needed to support the role and function of management effectively. In addition, the MIS owned by the Bank must be able to:
a. facilitate the management of Bank business operations including services to customers; b. record and collect information objectively;
c. distribute data or information to various work units appropriately in terms of information type, quality and quantity of information, as well as frequency and time of report delivery required;
d. improve the effectiveness and efficiency of communication in the Bank; e. help the Bank improve compliance with legislation regulations; and f. support the performance assessment process of all work units. In order to ensure the effectiveness of the MIS, the IT work unit must establish policies, procedures, and database management controls and report generation.

1.5. Project Management
In Article 11 of POJK MRTI, it is regulated that Banks are required to take control steps to produce systems and data that maintain confidentiality and integrity and support the achievement of Bank objectives, which includes the application of project management in system development. Banks that conduct important and large-scale IT development and procurement require an organization in the form of project management. This is to ensure that the IT system handed over by the IT work unit to the IT user work unit has been developed with a good structure, accommodates user needs, and is in accordance with the IT systems owned by the Bank. The project management team administers the progress of each project and helps coordinate between project implementers and prospective IT system users in each project, and reports it to the IT steering committee. The form of project management in the Bank's organization can be a permanent work unit or ad hoc, adjusted to the complexity and size of the Bank.

1.6. IT Strategic Plan
In Article 9 of POJK MRTI, Banks are required to have an IT Strategic Plan that supports the strategic plan of the Bank's business activities and is included in the Bank's business plan.
The IT Strategic Plan is embodied in a document that describes the Bank's IT vision and mission, supporting strategies, and main principles that serve as guidelines in the use of IT. The preparation process is carried out by the IT work unit, IT user work unit, and IT steering committee. a. The IT Strategic Plan document includes among others:

targets for Bank business development;
technology standards used;
legislative regulations that underlie, including those regarding Bank secrecy, security, transparency of product information, and use of customer personal data;
application needs plan for new products and activities as well as development of existing products and activities;
costs related to plan implementation;
processes needed for efficiency;
customer service and technology performance quality;
analysis of the Bank's IT resource capabilities;
optimal IT infrastructure for the future;
ability to adapt and integrate with new technology developments; and
ability to adapt to the macroeconomic development climate in Indonesia.
b. In preparing the IT Strategic Plan, the Bank must pay attention to:
alignment of direction with the Bank's overall strategic plan;
alignment of direction with the strategy and activities of each business unit, market conditions, demographic structure, and customer segmentation;
management's understanding of the role of IT in supporting the implementation of existing and planned Bank business activities;
management's understanding of the relationship between IT resources currently used and planned with the strategy and work plan of IT user work units;
analysis of direct and indirect benefits to be obtained compared to costs to be incurred for technology usage;
need for new investment in the technology field; and
HR needs plan.

1.7. IT Management Policies, Standards, and Procedures
Based on Article 8 of POJK MRTI, Banks are required to have and apply IT usage policies, standards, and procedures, and are required to conduct periodic review and updating of the aforementioned policies, standards, and procedures. In addition, in Article 8 of POJK MRTI, Banks are also required to establish the review and updating timeframe for policies, standards, and procedures in writing. Example: Bank "X" establishes a review and updating timeframe for policies every 5 (five) years, standards every 2 (two) years, and procedures every year. a. Policy A policy is a regulation or principle that describes the intent, commitment, or management plan for a specific issue stated formally by management, and becomes the working foundation of the organization. Policies for each aspect in this IT regulation will be explained in subsequent chapters. Example: IT risk management policy, information security policy, and IT HR usage policy. b. Standard A standard is a set of technical rules that must be complied with by the organization in order to apply a framework and IT governance (can be from internal or external). Standards establish specific requirements or measures that can be used as a benchmark for the Bank in conducting IT operations. Example:

internal standards such as desktop application standards, computer configuration standards, and document numbering standards.
external standards such as International Organization for Standardization (ISO) and Indonesian National Standards (SNI).
c. Procedure
A procedure is a sequence of activities in an IT operation process involving one or several IT work units in the Bank.
Example: document control procedures, record control, and internal audit.

1.8. IT Risk Management Process
1.8.1. Identification of Risk Types Related to IT Management
In conducting IT risk identification and assessment, management must first ensure the existence of risk awareness across all lines of the Bank, namely:
a. risk awareness from the Board of Directors and executive officials; b. clear understanding of the Bank's risk appetite;
c. understanding of legislation regulations related to IT;
d. transparency and integration of responsibilities regarding significant risks from every aspect related to IT operations.
To ensure the above, the Bank can run a risk awareness program for all Bank employees and management or run other methods that can increase users' awareness of existing risks.

1.8.2. IT-Related Risks
Banks must have an integrated or unified risk management approach to be able to identify, measure, monitor, and control risks effectively. Risks related to IT operations must be reviewed together with other risks owned by the Bank to determine the Bank's overall risk profile. The main risks related to IT operations include operational risk, compliance risk, legal risk, reputational risk, and strategic risk.

1.8.3. IT Risk Assessment
IT risk assessment by Banks needs to be carried out continuously as a cycle and includes at least 4 (four) important steps as follows:
a. Collection of data or documents on IT-related activities that have the potential to cause or increase risks, from ongoing or upcoming activities including but not limited to:

critical IT assets, in order to identify access points and deviations from confidential customer information;
results of strategic business plan reviews, specifically reviews of potential risk assessments;
results of due diligence and monitoring of IT service provider performance;
results of reviews of reports or complaints submitted by customers and/or IT users to call centers and/or help desks;
results of self-assessments conducted by all work units regarding controls carried out related to IT; and
audit findings related to IT operations and use.
b. Risk analysis related to the potential impact of each risk, such as fraud in programming, computer viruses,

system failure, natural disasters, and errors in selecting the technology used.
c. Setting control priorities and mitigation steps based on the results of the Bank's overall risk assessment. The Bank must create a risk ranking based on the likelihood of occurrence and the magnitude of the impact that can be caused, as well as risk mitigation that can be carried out to reduce the exposure to such risks.
d. Monitoring control and mitigation activities that have been carried out on risks identified in the previous risk assessment period, which includes among others: follow-up improvement plans, clarity of accountability and responsibility, reporting systems, and quality control, including other forms of supervision or compensating controls.

1.8.4. Measurement of IT-Related Risks
Banks need to pay attention to the significance of the impact of risks identified by the Bank on the Bank's condition and the frequency of risk occurrence. The methods used by the Bank may 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 occurrence can be explained narratively or by assigning a rating. An example of a simple qualitative measurement method is the use of a checklist or subjective risk rating such as High, Medium, or Low. So that identified and assessed or measured risks can be monitored by management, the Bank needs to have risk documentation, often referred to as a risk register. Examples of creating a risk register must include at least:
a. designation of assets, processes, products, or events containing risk; b. measurement or ranking of likelihood and impact (inherent risk assessment);
c. steps to handle potential risks (potential risk treatment), such as Accept, Control, Avoid, or Transfer (ACAT).

In documenting the handling of potential risks (potential risk treatment), the Bank needs to pay attention to among others: management's risk appetite, facilities that can be used as preventive or corrective controls, and the adequacy of the risk mitigation plan with the Bank's financial conditions. Documentation of handling potential risks must be reviewed periodically. Steps to handle potential risks that the Bank can take are as follows:

Accept: Management decides to accept the risk if the magnitude of impact and the level of tendency are still within the organization's tolerance limits.
Examples:
a) Setting criteria for accepting risks related to risk evaluation and handling, such as a final risk value of "Low". b) Setting a final risk value of "Medium" or "High", but it has been decided to be accepted by management and a system procedure is made to monitor such risks, for example, by providing additional capital according to the magnitude of the potential risk.
Control: The organization decides to reduce the impact or likelihood of the risk.
Example: installing a firewall on a Personal Computer (PC) to prevent unauthorized access.
Avoid: The organization decides not to carry out an activity or chooses another 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 due to 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 that contain the risk of fire; and d. measurement or ranking of likelihood and impact after ACAT (residual risk assessment).

1.8.5. Monitoring of IT-Related Risks
Banks must monitor IT risks by evaluating the adequacy, sufficiency, and effectiveness of IT service performance. a. Matters that can be covered in the evaluation include among others:

audit results and related studies;
feedback received;
policies, standards, and procedures and their implementation;
status of preventive or corrective actions related to risks faced by the Bank;
weaknesses and threats, both existing and potential;
measurement results of the effectiveness of IT service provision;
follow-up on previous evaluation results;
changes in conditions affecting IT service provision; and
recommendations for improvement or refinement.
b. Follow-up on evaluation results can be formulated in the form of decisions or actions to improve the effectiveness of IT service provision, including among others:
updating risk profiles, risk measurement, and risk handling plans;
refining IT policies, standards, and procedures;
fulfilling human resource needs;
setting 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.

1.8.6. Control of IT-Related Risks
Management must apply adequate control practices as part of the overall IT risk mitigation strategy, paying attention to at least:
a. risk assessment results; b. risk handling criteria and recommendations for the form of risk handling;
c. laws and regulations and legal requirements or other contractual requirements;
d. control practices including among others:

implementation of policies, standards, and procedures, and organizational structure including workflow;
effective internal controls that can mitigate risks in IT processes. The scope and quality of internal controls are the key to the risk management process, so management must identify specific internal control requirements needed in each policy and procedure implemented;
setting policies, standards, and procedures for information security management systems required by the Bank to secure assets related to IT service provision and usage, including data or information;
evaluation of review and testing results of the Disaster Recovery Plan (DRP) for each critical operational part;
setting policies and procedures regarding the use of IT service providers. The Board of Directors must have a comprehensive understanding of risks related to the use of IT service providers for part or all of IT operations;
evaluating the ability of IT service providers to maintain security levels at least equal to or stricter than those applied by the Bank's internal parties in terms of data confidentiality, integrity, and information availability. Strict supervision and monitoring must be carried out because the Bank's management responsibility does not disappear or decrease by outsourcing IT operations to IT service providers; and
the use of insurance as an effort to complement the mitigation of potential losses in IT service provision.
The risks that need to be insured are residual risks. The Bank must periodically review the needs, scope, and value of insurance coverage.

CHAPTER II DEVELOPMENT AND PROCUREMENT

2.1. Introduction
IT development and procurement, which is part of the Bank's IT management, begins with the identification and analysis of IT needs to the stages of IT implementation and maintenance.
IT development and procurement can be in the form of internal software development or the purchase of software, hardware, and the use of system development services from other parties.
The Bank must have adequate risk management against the IT development and procurement process, in order to minimize various risks or losses caused by errors (error), fraud (fraud), data manipulation, system abuse, or inaccuracy of developed service functions. Risk management against the development and procurement process includes among others: policies, standards, procedures, and processes for identifying and measuring risks against the process.

2.2. Control Steps in Development and Procurement
In carrying out IT development and procurement, the Bank is required to carry out control steps to produce systems and data that maintain confidentiality and integrity and support the achievement of the Bank's objectives as regulated in Article 11 of the MRTI POJK. In addition to the control steps as regulated in Article 11 of the MRTI POJK, control steps can also include:
a. ensuring that the developed system meets user needs; b. ensuring the compatibility of one system with others so that they can still function properly (interoperability and compatibility);
c. having source code for software developed specifically for the respective Bank (proprietary) so that the source code can be accessed when needed for audit and investigation purposes.
d. identifying, measuring, and controlling risks that may arise related to IT development and procurement adequately; e. determining the risk appetite and risk exposure that can be accepted by the Bank related to IT development and procurement; f. having system development procedures in emergency situations; and g. ensuring the separation of development and operational environments, including separating human resources responsible for the development process from human resources carrying out the Bank's operational activities.

2.3. Policies, Standards, and Procedures for Development and Procurement
The Bank is required to have policies, standards, and procedures for IT development and procurement as regulated in Article 8 of the MRTI POJK. The IT development and procurement process must always be under the control of the IT work unit and managed by project management. Project management can be in the form of a work team whose members consist of at least members from the IT work unit and the IT user work unit, tasked with ensuring that the system has been developed with a good structure and has accommodated user needs. If changes occur during the development and procurement process, such as changes in user requirements or changes in supporting technology, the change management procedure must be designed, executed, and documented well. Policies, standards, and procedures for development and procurement must pay attention to the following matters:
a. The IT development stages include at least:

identification and analysis of user needs;
definition of user needs;
system design;
programming;
testing;
implementation;
post-implementation review;
maintenance; and
disposal.

b. The IT procurement process includes among others:

procurement standards;
procurement project guidelines;
escrow agreement;
software purchase, license, and maintenance contracts;
maintenance;
warranty;
dispute resolution;
contract changes;
security; and
subcontracting to other parties.
c. Policies, standards, and procedures that the Bank needs to have in project management and change management.

2.3.1. Policies, Standards, and Procedures for Development

2.3.1.1. Initiation and Planning Stage
The initiation stage consists of steps including among others:
a. preparation of a proposal containing the identification of user needs to add, refine, or improve a system, the expected goals and benefits, and how the system to be developed can support the Bank's business strategy; b. evaluation by management;
c. principle approval for the development of a new system or system changes;
d. project feasibility study, which includes among others: the Bank's business considerations, functional needs, project implementation schedule, factors affecting the project, and cost-benefit analysis; e. management approval of the feasibility study document; and f. signing of the feasibility study document by all relevant parties. After development approval is obtained at the initiation stage, the Bank conducts planning for more detailed identification of specific activities and resources needed to complete the project. This planning stage results in a project plan that must serve as a reference in project implementation and must be updated according to project developments.

2.3.1.2. User Requirements Definition Stage
Based on the feasibility study document approved in writing by management, the project manager can form a team to prepare detailed user requirements definitions as the basis for starting application system development. The user requirements definition stage consists of:
a. requirements collection, which is the process of collecting information, either through interviews, research, or by filling out specific document forms or forms, regarding the goals of system development, desired output, the system's ability to accommodate business process needs and system working mechanisms, and system usage procedures; b. requirements analysis, which is the process of understanding problems and needs to determine solutions that can be developed. At this stage, a general estimate of the time and cost of development for each requirement and its compliance with laws and regulations are determined. The results of requirements analysis are used to produce business process flows, including business process flow, use cases modeling, and data flow diagrams, which can clarify the understanding of needs and solutions, both for users and system developers;
c. requirements specification, which is the process of describing the functional system to be developed, process or procedure specifications, and existing systems, both in terms of supporting software and hardware as well as Database (Database) design. Requirements specifications must be complete, comprehensive, testable, consistent, clear, and detail the input, process, and output requirements needed; and
d. requirements management, which is the process of identifying, controlling, and storing every change to requirements during development, carried out by the project team.

2.3.1.3. System Design Stage
This stage converts the identified information needs, functions, and infrastructure during the initiation and planning stages into design specifications or designs that serve as the basis for system development. At the design stage, an application control standard is needed, including policies and procedures related to user activities and integrated controls in the system to be developed. This stage is necessary to increase system security, integrity, and reliability by ensuring that authorized input, process, and output information is accurate, complete, and secure. The Bank needs to pay attention to the adequacy of the design with the existing IT architecture so that integration and continuity between systems can be maintained.

2.3.1.4. Programming Stage
In this stage, design specifications are converted into executable programs. The Bank must create policies, standards, and procedures for programming. In addition, the Bank must update the migration plan, implementation, end-user and operator training, and maintenance manual documents. a. Programming Standards Programming standards explain among others the responsibilities of system programmers. The project manager must understand the entire programming process to ensure that programmer responsibilities are appropriate, including among others:

limiting access to data, programs, utilities, and systems outside the programmer's responsibility. Library management controls can be used to manage such access; and
version control is a method that systematically stores the chronology of improved program copies and is one of the documents in development management.

b. Documentation

The Bank must manage and maintain detailed documents for each system, whether developed internally or products or software purchased or developed by other parties, including:
a) detailed description of the application; b) programming documentation consisting of source code, downloadable documents, and displays of the developed system; c) format standards for various aspects used related to the system such as Database (Database), display formats, and information; d) naming standards; and e) guidelines for operators and end-user guidelines for running system functions in detail, comprehensively, and clearly.
Documentation must be able to identify development standardization, such as system narratives, system flows, special system coding, and internal controls within the application document itself.
In the event that products or software are purchased or developed by other parties, management must ensure that reviews have been conducted previously, both internally and by independent parties, that the product or software documentation has met the Bank's minimum documentation standards.

2.3.1.5. Testing Stage
The Bank must carry out several series of tests to ensure the accuracy and functionality of the system according to user needs and the relationship of the system 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 among others:
a. unit test, which is a test carried out by the developer on the functionality of each unit or sub-module of the system that has been completed; b. system integration test (SIT), which is a test carried out by the developer on the overall functionality of the system after being integrated into a complete whole;
c. stress test, which is a durability test carried out by the developer on the system's ability to handle processes or transactions on a large scale or quantity; and
d. user acceptance test (UAT), which is the final test carried out by end-users on the system that has been completed in order to test the overall functionality of the system, whether it meets the user's needs at the user requirements definition stage before deciding that implementation can be carried out. UAT by end-users can only be carried out after the developer provides a report on the results of the SIT testing. At this stage, internal audit can also participate in testing while maintaining a high level of independence if internal audit needs to verify the availability, sufficiency, 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.

2.3.1.6. Implementation Stage
At the implementation stage, the Bank must carry out among others: notifying the implementation schedule, installing the approved system into the operational environment, and training users.
Other matters that must be paid attention to include among others:
a. checking program integrity by implementing adequate controls for 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 migrated data in the new system;
d. the possibility of implementing a parallel run between the old and new systems, until it is certain that the data in the new system is accurate and reliable; e. The Bank must ensure data integrity in terms of the accuracy and reliability of the Database (Database), including data stored in it; f. direct data and reference fixes (patching data) during implementation must be avoided as it can affect data integrity in the Database (Database) on the production server; g. storing source code and Database (Database) from the old system; h. anticipating weaknesses in operating systems, developed systems, Database (Database), 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.

2.3.1.7. Post-Implementation Review Stage
Management must conduct a post-implementation review at the end of the project to determine that all activities in the project have been carried out and the project goals have been achieved.
Management must analyze the effectiveness of project management activities by comparing among others: plans and actual costs, benefits obtained, and project schedule accuracy. The results of the analysis must be documented and reported to management.

2.3.1.8. Maintenance Stage
The Bank must establish maintenance methodologies appropriate to the characteristics and risks of each existing system project.
Maintenance is implemented as a guarantee for users to continue running the developed system according to current functional and operational work needs. The maintenance stage pays attention to aspects including among others:

a. Library
To ensure the availability of programs used, the Bank must have a library to store programs. In addition, the Bank must also store information and/or documents in the form of data and programs related to servers or production machines originating from development and/or testing.

b. Conversion
In the event of a merger, consolidation, or acquisition of the Bank that requires the integration of systems used by the Banks involved in the merger, consolidation, or acquisition, a conversion process must be carried out. In this process, modifications or major changes to existing systems and the development of new systems are performed if necessary. In this conversion process, structured processes such as project management and the system development lifecycle must still be applied. Given the complexity of the systems in each Bank involved in the merger, consolidation, or acquisition, a comprehensive analysis of the impact of conversion on Bank operations, particularly transaction processing, is required. To ensure the conversion process runs effectively, the Bank must anticipate increased demand for balancing, reconciliation, exception handling, user and customer support, problem resolution, network connectivity, and administrative systems.

c. Documentation Maintenance
Documentation standards must identify the main documents and detailed documents that have been approved and comply with the required format. The documentation must contain all changes that have occurred in the system, whether from software, hardware, and networks, as well as configurations in accordance with the determined standards. System-related documentation can only be accessed by Bank personnel who are authorized and/or have the authority to administer such documentation. The Bank must have a special storage location for documentation, both in hardcopy and softcopy form, including locations to be used for emergency conditions.

2.3.1.9. Disposal Stage
Every piece of software developed that is no longer used in operational activities and, based on management considerations, is believed to no longer be needed and will not be maintained, will enter the final stage, namely the disposal stage. This is done to ensure that the most accurate and up-to-date systems are used in operational activities and to prevent misuse by unauthorized parties.

2.3.2. Procurement Policies, Standards, and Procedures
In the event that systems are purchased from third parties through a procurement process, attention must also be paid to the suitability of specifications with needs, impact on existing systems, after-sales technical support, the company's financial condition, documentation completeness, escrow agreements, and training. In the system procurement process, the Bank must also ensure that:
a. the procurement of hardware and software has gone through a feasibility study of the procurement project, obtained management approval, has user need definitions, has adequate system controls and security, and has product testing and implementation; and b. 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 proofing include:

concepts from vendors that have been built in the form of prototypes have passed the testing stage by a small group of operational users covering several types of roles (business roles);
concept proofing can be done technically on all aspects of technology involved in the application (steel thread);
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
implementation in a smaller scope can be preceded by a pilot project with more limited end targets. 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 in the event of system failure.

2.3.2.1. Procurement Standards
Procurement standards must be applied to ensure that purchased products meet functional needs, security criteria, and reliability. The main document that initiates the procurement project is the Request For Proposal (RFP) which must at least contain functional needs, security, and operational needs accurately, clearly, and in detail. a. In system procurement, the project manager must carry out several important things:

thoroughly review the suitability of vendors, contracts, licenses, and products obtained against existing systems;
compare offers with the requirements in the project and among each other;
examine the financial condition of the vendor and its commitment to service; and
seek the opinion of legal advisors before the contract is signed by management.
b. Regarding the procurement of hardware, the Bank ensures that the hardware used must:
meet aspects of interconnectivity and compatibility with the systems used;
obtain a fitness certificate from the Ministry of Communication and Information Technology of the Republic of Indonesia;
have technical support, maintenance, and after-sales service from the seller or vendor;
have supporting references from other users that the hardware functions according to its specifications;
have a guarantee of spare part availability for at least 3 (three) years;
have a guarantee of clarity regarding the condition of the hardware; and
have a guarantee of freedom from product defects.

2.3.2.2. Procurement Project Guidelines
Procurement projects must pay attention to at least:
a. procurement projects begin with a project plan submission to management; b. there are procedures to facilitate the request process and ensure that management reviews all requests;
c. requests must be based on the Bank's business needs to:

obtain a product, whether in the form of software or hardware,
identify desired system features, and
describe information needs, network interfaces, and hardware and software components;
d. The Bank must prepare a feasibility study to determine the Bank's software procurement needs, whether those that can be modified according to needs or ready-made (off-the-shelf); e. approval from all relevant parties regarding the feasibility study must be documented as the basis for creating need definitions as explained in sub-section 2.3.1.2; f. after the Bank receives offers, the Bank must analyze and compare offers from vendors against the needs established by the Bank. Vendor proposals must clearly discuss all Bank needs and identify other issues that can be applied; g. The Bank must have procedures to ensure that the offer review process has been carried out correctly. The Bank then conducts a selection process that results in a list of potential vendors; h. management must re-examine the financial stability and service commitment of the selected vendor; and
i. The Bank determines the product and vendor and negotiates the contract. The legal unit or legal advisor must review the contract before it is signed. The contract must also contain clauses related to the maintenance of software and hardware for a certain period, as a guarantee that the software and hardware in question can function according to the Bank's needs.

2.3.2.3. Escrow Agreement
In the event that core applications are made by vendors and source code is not provided to the Bank because the application is also used by other parties (non-proprietary), the Bank must protect its interests in maintaining the continuity of the Bank's business. To mitigate the risk of vendor support stopping, the Bank must consider whether it is necessary to have a written agreement in the form of an escrow agreement for applications or software considered important by the Bank. The use of escrow agreements considers among other things the vendor's reputation and how many software users there are both within and outside the territory of Indonesia. In an escrow agreement, there is an independent third party appointed to store the source code. The Bank must ensure at least once in 1 (one) year that the third party stores the latest version of the source code. The chosen storage agent must ensure the number and date of the version of the source code stored and ensure the vendor regarding the integrity of the source code.

2.3.2.4. Software Purchase, License, and Maintenance Contracts
a. Software Licenses – General
The Bank must ensure that the license contains:

a written explanation that the use of the software is exclusive or not;
information and the number of Bank personnel who can use the software;
restrictions on the location of use. If the Bank wants a location license for users not limited to a certain location, it must be ensured that this is possible within the contract;
a list of other related entities that can use the software, such as subsidiaries or sister companies of the Bank;
information regarding software development in-house or outsourcing by vendors or consultants, and the purchase of software accompanied by source code, or only as a right to use or rent with restrictions on time or certain features; and
an escrow agreement between the vendor in Indonesia and the vendor outside the territory of Indonesia if the license of the software used by the Bank with a vendor in Indonesia is a right-to-use license that allows modification based on parameters, while the source code of the software is with a vendor outside the territory of Indonesia who does not have a direct contract with the Bank.
b. Standards for Software Development Specifications and Performance In procuring software, the Bank must make a contract agreement with the service provider for development that contains standards for program specifications expected by the Bank in accordance with user needs, including:
expected performance and functionality of the software;
infrastructure requirements needed to run the software;
identification and functional specifications where operational software will work and identification of milestones of functionality that must be met by the vendor during the development process;
arrangements for permission to modify specifications and performance standards during the development process;
identification of testing needs to determine compliance with software performance standards;
actions that must be taken by the vendor if the software fails during testing;
security and reliability guarantees; and
the use of software for the public refers to relevant regulations and legislation.

2.3.2.5. Maintenance
The Bank needs to pay attention to and ensure that license agreements or development agreements contain agreements regarding matters necessary for software maintenance such as documentation, modification, updates, and conversion. Agreements include among other things that:
a. the vendor provides comprehensive training to Bank personnel responsible for software maintenance; b. the vendor provides software documentation, including system documentation and technical usage instructions;
c. the implementation and cost of software updates and modifications;
d. the possibility of the Bank accessing source code if the vendor can no longer provide services or there is a modification need that cannot be done by the vendor; and e. the possibility of the vendor helping the data conversion process during system replacement in the future in the simplest standard format such as text format. If necessary, these agreements can be included in a separate maintenance agreement.

2.3.2.6. Warranty
The Bank needs to conduct research to ensure there is a guarantee that the software license from the vendor:
a. does not violate the intellectual property rights of others worldwide; b. does not contain secret codes, undisclosed restrictions, or automatic restrictions in the agreement;
c. functions according to specifications and the vendor's liability limits must be stated in the event of problems;
d. maintenance is carried out by the vendor during the agreed period; and e. remains valid in the event of merger, consolidation, takeover, or change of ownership either at the Bank or the vendor.

2.3.2.7. Dispute Resolution
The Bank must include a dispute resolution clause in the license agreement. Understanding of this clause will increase the Bank's ability to resolve problems in the best way and allow for the continuation of software development during the dispute resolution period.

2.3.2.8. Agreement Changes
The Bank must ensure that the software license clearly states that the vendor cannot modify the agreement without the approval of both parties.

2.3.2.9. Security
The Bank must establish security control criteria for IT that will become the performance standard of security features in license agreements and software development agreements. These standards must ensure that the developed software is consistent with the overall security program existing in the Bank. License and development agreements include among other things:

the vendor's ongoing responsibility to protect the security and confidentiality of the Bank's resources and data;
prohibition for the vendor to use or disclose information owned by the Bank without the Bank's approval;
guarantee from the vendor that the software does not contain back doors that allow unauthorized access to the Bank's systems and data; and
an explicit statement that the vendor will not use features that could cause the software to function poorly.

2.3.2.10. Subcontracting to Vendors
The Bank must establish clauses in the development agreement prohibiting the vendor from assigning contracts to third parties without the Bank's approval. If there are conditions where part of the software development must be subcontracted, there must be written approval from the Bank. In granting subcontract approval, the Bank must consider the level of difficulty and availability of experts in the software development as well as the security of the Bank's data. In addition, the Bank must ensure there is a clause stating that the vendor is responsible for the software even if it is designed or developed by other parties.

2.3.3. Project Management and Change Management Policies, Standards, and Procedures
a. Project management needs to pay attention to among other things:

The Bank must conduct a feasibility study to know the costs and benefits of IT development and procurement, as well as to determine the use of internal resources or outsourcing to vendors;
The Bank must clearly specify relevant security requirements before new systems are developed or purchased. These security requirements must be in accordance with the Bank's overall information security architecture;
The Bank must plan well to ensure that project objectives are achieved;
The Bank must perform environmental separation classification for development, testing, and production, including access restrictions to each part of the environment;
The Bank must ensure adequate training and clarity of system usage instructions prepared as part of the contract between the Bank and the vendor;
for systems supported or maintained by vendors, there must be adequate software selection analysis to ensure user needs and business processes are met;
there is a written agreement between the Bank and the vendor;
The Bank must apply maintenance management for all development and procurement processes that have been implemented;
all deliverables at each stage of project management must be well documented; and
The Bank must have a formal project plan including:
a) project identification, sponsor, and project manager; b) project objectives, background information, and development strategy; c) description of tasks and main responsibilities of each personnel in project management; d) procedures for collecting and disseminating information; e) criteria for acceptable target results for each development stage; f) security issues and controls that must be considered; g) procedures to ensure that the project manager correctly assesses, monitors, and manages internal and external risks throughout the development cycle; h) cut-off date for transferring the use of application systems from the old to the latest version resulting from development or changes; i) development standards to be used for project supervision, system control, and quality control; j) types and levels of documentation that must be produced by each personnel at each stage of the project; k) project stage schedule and activities to be completed in each stage; l) initial budget estimate of the total project costs; m) testing plan that identifies testing needs based on type, procedures, and testing schedule; and n) training plan that identifies training needs and schedules so that Bank employees can use and maintain applications post-implementation. b. The change management process covers at least:
review before modification and authorization;
testing before modification in a separate testing environment;
data and source code backup procedures before modification;
documentation consisting of:
a) explanation of the modification, b) reasons for the application or rejection of the proposed modification, c) name of the individual making the modification, d) copy of the modified source code, e) date and time the modification was made, and f) evaluation after modification; and
documentation that must be made during the modification process consisting of:
a) priority information, b) identification of systems, Databases, and affected units, c) name of the individual responsible for making changes, d) resource needs, e) cost prediction, f) predicted completion date, g) predicted implementation date, h) consideration of potential security and reliability of system modifications, i) testing needs, j) implementation procedures, k) estimated downtime during implementation, l) backup procedures, m) documentation updates, including program designs and scripts, network topology, user manuals, and contingency plans, n) modification acceptance documentation from all related units, including users, technology, quality assurance, security, audit, and o) post-implementation audit documentation accompanied by a comparison between expectations and results.

2.4. Development and Procurement Risk Management Process

2.4.1. Risk Measurement Related to Development and Procurement
The measurement of risk levels in the IT development and procurement process depends on related factors including:
a. suitability with business strategic plans and applicable regulations; b. changes in system or process scope;
c. separation of development, testing, and operational environments, including access arrangements for developers, testers, and users;
d. plans for application systems to be obtained through package purchase without modification, package purchase with modification, internal development, or by third parties; e. scope and level of criticality of the system or the number of affected business units; f. complexity of the processing type of the application to be developed (batch, real-time, client or server, parallel distributed); g. volume and value of transactions from the application systems to be developed; h. classification and sensitivity of data from the system to be developed;
i. impact on data (read, download, upload, update, or alter);
j. level of vendor experience and capability, if the system is purchased or developed by third parties; k. adequacy of the number and capability of personnel included in the development team; l) suitability of the chosen platform and application with the Bank's architecture; m) dependency of the developed system on existing systems; n) mismatch of the number of users with the initial development plan or changes in organizational structure during the development process; o) changes in regulations; p) existence of new risks or risks that may arise from technology being developed or technology obsolescence; q) existence of audit weaknesses or weaknesses found in self-assessment; and r) mismatch of development implementation with target completion times.

2.4.2. Risk Control in Development and Procurement
At each stage of IT development and procurement, the Bank must mitigate identified and measured risks with several control methods established in policies,

standards, and procedures for the development and procurement of Bank IT.
After mitigation, the Bank must monitor controlled risks and residual risk because every disruption that can affect the IT development and procurement plans and processes can ultimately impact the Bank's operational activities.

2.4.2.1. Risk Control in Development
In order to control risks related to IT development, the Bank must ensure that system development has been carried out in accordance with policies, standards, and procedures for each stage of development. This is done by considering:
a. the system development plan is in accordance with user needs and the Bank's business policy direction; b. the developed system design covers user needs at the initiation and planning stages and is in accordance with application control standards involving internal audit participation.

Based on their purpose, controls are divided into preventive, detective, or corrective controls. Controls that must be performed include at least:

Input Control
At least covers checking the validity or correctness of data, data range, parameters, and data duplication that is input;
Process Control
Ensures the process works accurately and can store or reject information. Process controls that can be performed automatically by the system include at least error reporting, transaction logs, sequence checking, and file backup; and
Output Control
Ensures the system manages information securely and distributes processed information correctly and deletes information that has passed its retention period;
c. programming results are built based on design specifications with a documented test plan to facilitate the tracing of application system changes;
d. the execution of a series of tests by defining the scope of test scenarios, evaluating test results, making system improvements until approval of the test result report is obtained; e. the implementation of the new system can run with the old system through installation preparation, file migration, data conversion, technical instruction documents, and training; and f. the implementation results of the running system are good continuously with periodic reviews of the effectiveness of maintenance.

2.4.2.2. Risk Control in Procurement
In order to control risks in procurement, the Bank must create vendor selection criteria and conduct a review of vendor capabilities, including financial conditions, support levels, and security controls, before determining the choice of products or services from the vendor. The Bank must review the licensing agreement to ensure the rights and responsibilities of each party are clear and fair. The Bank's legal advisor must confirm that performance guarantees, access to source code, copyrights, and software or data security are clearly regulated before management signs the agreement. Matters that need attention are:
a. ensuring the procurement process is in accordance with the Bank's policies, standards, and procedures and applicable regulations regarding procurement; and b. carrying out all legal obligations adequately.

CHAPTER III IT OPERATIONAL ACTIVITIES

3.1. Introduction
IT development enables Banks to carry out increasingly complex operational activities. IT operations are not only concentrated in Data Centers but also in other activities related to the use of integrated applications, diverse communication media, internet connections, and various computer platforms. Meanwhile, input and output access can be performed by many users from various locations. Similarly, processing can be performed in various distant but interrelated locations, either in real-time online, online, or offline. Therefore, adequate controls over IT operations are needed so that the Bank can minimize the risk of disruption to the confidentiality, integrity, and availability of information. Adequate regulations over IT operational activities are very important to ensure that information in the system is complete, accurate, up-to-date, integrity is maintained, and reliable, as well as free from errors, fraud, manipulation, misuse, and data destruction.

3.2. Policies, Standards, and Procedures related to IT Operational Activities
Pursuant to Article 12 of POJK MRTI, the Bank is required to ensure the continuity and stability of IT operations and mitigate risks that have the potential to disrupt the Bank's operational activities. The Bank must have a policy covering every aspect of IT operations and adjusted to the complexity of the Bank's IT operations. IT operational aspects include, among others, Data Centers, capacity planning and monitoring, hardware and software configuration management, and Database management. Procedures contain responsibilities, accountability, delegation of authority, and guidelines for performers of operational activities. In addition, management must establish hardware and software standards used in the Bank's IT operational, testing, and development environment.

3.2.1. Policies related to Data Centers
In Article 22 of POJK MRTI, Data Centers and Disaster Recovery Centers must guarantee the continuity of the Bank's business. a. 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:

Task scheduling
The Bank has and executes a schedule of all tasks that must be run in the operational IT Data Center effectively and safely from unauthorized changes;
Task operation
Granting command line access to IT operators must be limited according to authority in the task operation functions that have been determined;
Output distribution
Information produced by the system (output), in softcopy or hardcopy form, can be sensitive or confidential information. Procedures that the Bank must have include determining the information to be produced, distributing output both physically and logically, and disposal of output that is no longer needed. These procedures are necessary to avoid the opening of confidential information and increased costs due to unnecessary output, as well as to ensure output security;
Backup processes both onsite and offsite, restore, download, and upload for Databases;
Monitoring of hardware and software; and
Enabling audit trails.
b. Physical Access Control of Data Centers
Physical access to Data Centers must be limited and well controlled. Data Center doors must always be locked and equipped with access cards and/or biometric devices. Data Center rooms must not be labeled or have signage boards so that people cannot easily recognize them. The Bank must have a log-book to record guests entering the Data Center.
c. Environmental Control of Data Centers
IT processing environmental conditions that do not meet standards can cause disruptions to IT operations so that management must at least:
supervise and monitor Data Center environmental factors, 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;
ensure the availability of sufficient, stable power sources, and the availability of alternative power sources to anticipate the failure of 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 disruption in one of the power sources to maintain power supply in accordance with equipment needs;
ensure the Data Center has fire and smoke detectors as well as 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 consider safety for equipment and operating personnel in the Data Center;
use raised floors to secure cabling systems and avoid grounding effects in Data Centers; and
inventory supporting Data Center devices including UPS and power control, fire detection and extinguisher, air conditioning, thermometers, and hygrometers.

3.2.2. IT Capacity Planning and Monitoring Policies
The Bank needs to have IT capacity planning and monitoring policies and procedures to ensure that the hardware and software used by the Bank are in accordance with business operational needs and anticipate the Bank's business development. Without good IT capacity planning, the Bank may face risks of shortage or even waste of IT resources. IT capacity planning must be prepared for a sufficiently long period and always updated to accommodate existing changes.

3.2.3. Hardware and Software Configuration Management Policies
The Bank must establish procedures regarding:
a. the process of installing hardware and software; b. parameter settings (hardening) of hardware and software; and
c. inventory and updating of information on hardware, software, network infrastructure, storage media, and other supporting devices present in the Data Center.
Inventorying includes:

Hardware
Hardware inventory must be carried out comprehensively, including inventory of hardware owned by other parties but located at the Bank. Important information that must be covered in hardware inventory includes vendor name and model, purchase and installation dates, processor capacity, main memory, storage capacity, operating system, function, and location.
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, among others, 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.
Network Infrastructure
Network infrastructure is an important aspect of Bank operations so that management must document network configurations completely. Information that must be covered includes:
a) network diagrams; b) identification of all internal and external Bank connections; c) list and capacity of network equipment such as switches, routers, hubs, gateways, and firewalls; d) identification of telecommunications vendors; e) network expansion and configuration change plans; and f) overview of network security systems.
Storage Media
Information required in storage media inventory includes type and capacity, storage location both onsite and offsite, type and classification of data stored, source system, as well as frequency and retention period of backups.

3.2.4. Hardware and Software Maintenance Policies
a. Hardware Maintenance
Periodic preventive maintenance of IT equipment is necessary to minimize equipment operational failures and to detect potential problems early. For this reason, the Bank needs to have maintenance agreements with vendors to ensure the availability of vendor maintenance support. Maintenance is based on established schedules, documented in a log-book, and reviewed periodically.

b. Hardware and Software Performance Monitoring Monitoring of hardware and software is carried out daily to ensure that all devices operate as they should.
For example, servers remain on, Database (Database) and server utility capacities do not exceed limits, and supporting facilities function properly.

3.2.5. Change Management Policies
Change management is a procedure that regulates the addition, replacement, or deletion of objects in the operational environment. The objects referred to can be data, programs, menus, applications, computer devices, network devices, and processes. The Bank must have change management policies, standards, and procedures that include at least requests, analysis, change approval, and change installation, including the transfer of hardware and software from the testing environment to the operational environment. Change management must consider:
a. Change Control
Interdependence between applications used in various work units requires integrated IT organization. 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 consider operational continuity in the operational environment, supervision, and information system security arrangements. Minimum standards regulated must include risks, testing, authorization and approval, implementation time, validation after installation, and back-out or recovery. b. Patch management In change management, the Bank must have complete documentation about the installation of patches performed. In addition, the Bank must ensure that the Bank uses the most appropriate latest 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 versions used.
c. 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 that need to be passed in performing data migration start from strategic planning, project management, change management, testing, contingency plans, backup, vendor management, and post-implementation review.

3.2.6. Incident or Problem Handling Policies
Good incident or problem handling procedures are needed by the Bank to face financial, operational, and reputational risks from arising problems. Incident or problem handling procedures must cover hardware, operating systems, application systems, network devices, and security equipment. The Bank must maintain the necessary facilities to handle problems, including:
a. 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. The Bank will face risks if it does not have adequate helpdesk procedures to ensure that users have obtained solutions to the problems they face. Matters that need attention in the helpdesk function are:

Availability of complete problem documentation
Problem documentation must include user data, problem explanation, impact on the system (platform, application, or others), priority code, current resolution status, party responsible for resolution, root cause (if identified), resolution time target, and comment fields to record user contact and other relevant information.
Helpdesk system
The Bank needs to use a system that can provide helpdesk staff with alternative solutions for common problems. The Bank periodically updates the system with information obtained from vendors and from helpdesk staff experience. b. Power User Management Power users are user IDs with very broad authority. In order to handle problems, the Bank establishes power user handling procedures so that their use is not abused. These procedures include, among others:
determination of parties having power user access rights including the application of dual custody (splitting passwords among more than 1 (one) person);
power user password storage procedures;
power user ID break procedures in emergencies;
power user password replacement procedures after use; and
documentation of power user use in the form of minutes.

3.2.7. Database Management Policies
Failure in managing and securing 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 supervision. Databases storing confidential information require stricter controls compared to Databases storing non-sensitive information. For this reason, the Bank has a Database Administrator (DBA) function responsible for managing the Bank's Databases. Procedures owned by the Bank related to Databases are access, maintenance, problem handling, and Database administration.

3.2.8. Information Exchange Control Policies
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:
a. requests and provision of information by internal and external parties; and b. sending information through various media, such as hardcopy, tape, disk, email, post, and internet.
In large Banks with high IT complexity, management 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 data traffic in and out.

3.2.9. Library Management Policies
Library managers are responsible for inventorying and storing all software and data stored in various media, including tapes and disks. In addition, library 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:
a. securing access to data in the library; b. handling data storage media (for Databases and audit journals);
c. retention period of data storage media;
d. testing of data storage media; and e. entry and exit of data storage media from and to the library.
In making policies, standards, and procedures for the library, the Bank must consider 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 a disaster or other disruptions.

3.2.10. Hardware and Software Disposal Policies
Disposal includes the deletion of software, hardware, and data that are no longer used or whose retention period has expired. Old source code versions that are no longer used must be stored with clear information regarding the date, time, and other information when replaced with the latest source code versions. Activities carried out include, among others:
a. moving data from the production system to backup media with mechanisms in accordance with procedures, including testing and backup procedures; b. storing system documentation as preparation if needed to reinstall a system to a production server;
c. managing data archives according to retention periods; and
d. destroying data whose retention period has expired.

3.3. IT Operational Activity Risk Management Process
Risk management of IT operational activities must consider:
a. Incidents or activities that can disrupt operations, including:

technology investment errors including incorrect implementation, vendor failures, incorrect definition of business needs, incompatibility with existing systems, or software obsolescence, including the loss of vendor support for hardware and software used by the Bank;
system development and implementation problems including inadequate project management, costs and time exceeding limits, programming errors, failure to integrate or migrate from existing systems, or errors in a system to meet user needs;
system capacity problems such as shortages in capacity planning, insufficient capacity to accommodate system flexibility, and/or insufficient software to accommodate business development;
system failures including on networks, interfaces, hardware, software, or internal communication failures; and
violations of system security including violations of external and internal security, fraud in programming, or computer viruses.
b. The level of IT operational risk depending on related factors, including:
compliance with business strategic plans and applicable regulations;
changes in system or process scope;
system access location (internal or external, including internet, dial-up, or WAN);
application acquisition including through purchase of unmodified packages, purchase of modified packages, and/or internal development by third parties;
scope and level of criticality of the system or the number of affected business units;
complexity of application processing types (batch, real-time, client or server, or parallel distributed);
volume and value of transactions from the system;
classification and sensitivity of data processed or used;
impact on data (read, download, upload, update, or alter);

the experience and competence of IT managers;
the adequacy of the number and competence of operational staff;
the diversity of platforms, applications, and delivery channels;
the number of users and customers;
changes in regulations;
the existence of new risks or risks that may arise from technology currently under development or technology obsolescence; and
the existence of audit weaknesses or weaknesses found in self-assessment.

CHAPTER IV COMMUNICATION NETWORKS
4.1. Introduction
The development of communication network technology has changed the Bank's business approach to be without time and place boundaries. Banks can provide banking services in real-time online from all offices and other delivery channels, such as; Automated Teller Machine (ATM), internet banking, mobile banking, and Electronic Data Capture (EDC), whether owned by the Bank or by third-party IT service providers. Communication networks encompass hardware, software, and transmission media used to transmit information in the form of data, voice, images, and video. The operation of communication networks is highly influenced by IT changes, both systems and infrastructure, and is vulnerable to disruption and misuse. Therefore, the Bank needs to ensure that network integrity is maintained by implementing good network management policies, standards, and procedures, maximizing network performance, designing networks that are resistant to disruption, clearly defining network services, and implementing necessary security measures.

4.2. Policies, Standards, and Procedures Related to Communication Networks
In Article 13 of POJK MRTI, Banks are required to provide communication networks that meet the principles of confidentiality, integrity, and availability. To fulfill this obligation, Banks 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 goal of communication network management to be organized by the Bank, for example, regarding the application of encryption on communication networks. Communication network standards are a number of parameters set by the Bank to meet communication network policies, for example, the use of Secure Socket Layer (SSL) on the Session layer. Communication network procedures are a series of technical steps to be taken by the Bank to meet communication network standards. Policies, standards, and procedures that need to be established must at least cover:
a. performance measurement and network capacity planning; b. communication network security (network access control, including remote access);
c. change management (setting, configuration, and testing);
d. network management, network logging, and network monitoring; e. use of 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 regularly if the communication network used by the Bank is organized by a third-party IT service provider.

4.3. Communication Network Risk Management Process
4.3.1. Risk Control
a. The use of communication network technology provides various conveniences and benefits for the Bank and customers; however, risks that may arise must be considered, including:

loss of data/information;
loss of data/information integrity;
incomplete data/information transmitted;
loss of information confidentiality;
unavailability of communication networks due to disruption or disaster; and
loss/damage of communication network equipment.
b. In controlling risks on communication networks, the Bank must pay attention to the following:
Communication Network Design
Communication networks must be designed to be efficient but also dynamic to anticipate future development. At this stage, several things need to be considered, namely:
a) determination of communication network topology; b) communication network capacity planning; c) selection of communication network media; d) backup of hardware, alternative routing, or alternative providers; e) physical and logical security:
i. placement of network equipment in locations safe from natural disruptions and access by unauthorized persons; and
ii. arrangement of network device system parameters.
f) availability of audit trails, at least for changes to parameter settings and network communication device access rights, as well as the use of such access rights.
Access Control
Access control on communication networks is very important and must be considered because communication networks are the main gateway to enter the Bank's information system. If not managed well, information security is threatened. In implementing access control, there are several things that the Bank must pay attention to, namely:
a) access to communication networks by users is based on business needs while considering information security aspects; b) separating communication networks based on segments, both physically and logically, for example, separation between development and operational environments; c) if physical separation cannot be done, the Bank must separate communication networks logically and monitor security access on the communication network; d) decisions to connect to communication networks outside the Bank must comply with security requirements and be formally approved by management before implementation; e) implementing controls that can limit unauthorized or unexpected network traffic; f) communication network device configuration must be well arranged. Functions or services that are not needed must be disabled; g) use of communication network security devices, such as firewalls, Intrusion Detection System (IDS), and Intrusion Prevention System (IPS); h) use of additional communication network monitoring devices (network management system) while considering security; and i) periodic testing of communication network security, for example, with penetration testing.
Operation and Maintenance of Communication Networks
Operation and maintenance of communication networks must at least pay attention to:
a) personnel operating the communication network must be clearly appointed by management, have sufficient knowledge and skills, and be given adequate tasks and authority to perform their functions; b) the Bank must have an incident response plan for communication network disruptions and attacks; c) the Bank must have backup facilities for communication network hardware or software, including tested restart/recovery mechanisms. Backup facilities should have different risks than main devices, such as using different service providers; and d) patches and releases must always be updated after internal testing to ensure that weaknesses have been fixed.
Documentation
To be able to control communication network management activities, the Bank must have complete and up-to-date communication network documentation, including:
a) policies, standards, procedures, and baselines regarding communication networks; b) detailed communication network diagrams; c) list and specifications of communication network software and hardware; d) list of problems and their handling; e) communication network monitoring reports; f) communication network capacity planning reports; g) agreements and SLAs with third-party IT service providers for communication network facilities; h) communication network testing documents; i) communication network implementation documents; j) communication network change documents accompanied by reasons for changes; and k) list of users and their authorities.

4.3.2. Risk Monitoring
Monitoring of risks that may arise in communication networks used by the Bank includes the following:
a. available audit trails must be monitored regularly to detect deviations early; b. communication network performance is measured periodically based on availability and response time levels;
c. the Bank must monitor capacity used and required for business development plans compared to installed capacity;
d. the Bank must monitor and follow up on intrusions or attacks against communication networks; and e. the Bank must periodically review user access grants to ensure that granted access is still appropriate for tasks and authorities. In addition, a review of Bank communication network users who have access to communication networks outside the Bank is necessary.

CHAPTER V INFORMATION SECURITY
5.1. Introduction
Information is a very important asset for the Bank, whether information related to customers, finances, reports, or other information. Leaks, damage, inaccuracy, unavailability, or other disruptions to such information can cause adverse effects, both financially and non-financially, for the Bank. The aforementioned effects are not limited to the Bank but also to customers. Given the importance of information, information must be protected or secured by all Bank personnel. Information security covers not only security of all related IT aspects and components such as software, hardware, networks, support equipment (e.g., power supply, air conditioning), and human resources (including qualifications and skills) but also information in a broader sense.

5.2. Policies, Standards, and Procedures Related to Information Security
In accordance with Article 16 of POJK MRTI, Banks are required to ensure that information security is implemented effectively by paying attention to at least:
a. information security aimed at maintaining the confidentiality, integrity, and availability of managed information effectively and efficiently while considering compliance with regulations; b. information security conducted on technology, human resources, and process aspects in the use of IT;
c. information security applied based on the results of risk assessment on information owned by the Bank; and
d. the availability of incident management management in information security.
In addition to these obligations, Banks also implement 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 making improvements. Furthermore, Banks need to consider the implementation of international standards in the field of information security such as International Organization for Standardization (ISO), International Electrotechnical Commission (IEC), Control Objective for Information and Related Technology (COBIT), Information Technology Infrastructure Library (ITIL), and national standards such as Indonesian National Standard (SNI), while considering the Bank's business goals, policies, size, and complexity of business, which include among others diversity in transaction types, products, or services and office networks, as well as supporting technology used.

5.2.1. Information Security Policy
Bank management must establish policies and have a high commitment to information security. Such policies must be consistent with risk appetite and communicated regularly to all Bank employees and relevant external parties. In addition, periodic policy evaluation is necessary, and whenever there are significant changes. Information security policies must cover at least:
a. information security objectives which at least include asset management, human resources, physical security, logical security, IT operational security, information security incident handling, and information security in system development; b. management's commitment to information security in line with business strategy and goals;
c. framework for establishing controls through the implementation of the Bank's risk management;
d. compliance with internal regulations and statutory regulations, including the Law on Information and Electronic Transactions (UU ITE) and Government Regulation on the Organization of Electronic Systems and Transactions (PP PSTE); e. training and increasing awareness of the importance of information security (security awareness program); f. analysis of the impact of information security on business continuity; g. duties and responsibilities of parties in information security; h. sanctions for violations of information security policies; and i) documents or other regulations supporting information security policies.

5.2.2. Information Security Standards
Bank management must establish information security standards in accordance with information security policies, among others by referring to statutory regulations and best practices. Information security standards are:
a. a basis for implementing and assessing compliance with regulations related to information security; and b. a reference for drafting information security procedures.
Examples of information security standards include:

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

5.2.3. Information Security Procedures
5.2.3.1. Asset Management Procedures
Asset management procedures cover at least:
a. Bank assets related to information must be identified, owners or persons in charge must be determined, and recorded so that they can be properly protected; b. assets related to information can be in the form of data (hardcopy or softcopy), software, hardware, networks, support equipment, for example, power supply and air conditioning, and human resources including qualifications and skills;
c. the regulation of information and asset use must be identified, documented, and implemented. All Bank employees and third parties must comply with such regulations, such as regulations on the use of e-mail, internet, mobile devices, teleworking, and others; and
d. information must be classified so that adequate security can be implemented according to its classification. Examples of such classification are "confidential" information (e.g., customer deposit data and customer personal data), "internal" (e.g., regulations regarding Bank employee salaries), and "general" (e.g., information about banking products offered to the public). Classification can be made based on value, level of confidentiality, law or regulations, and level of importance to the Bank.

5.2.3.2. Human Resource Management Procedures
Human resource management procedures cover at least:
a. the Bank must implement adequate controls before employing IT employees (permanent, contract, or casual), consultants, including employees of IT service providers in positions with high vulnerability or significant 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, including Bank employees, consultants, casual employees, and employees of IT service providers who have access to information, must understand their responsibilities regarding information security;
c. the roles and responsibilities of human resources, including Bank employees, consultants, casual employees, and employees of IT service providers who have access to information, must be defined and based on the level of need for information access, and documented in accordance with information security policies;
d. agreements with Bank employees, consultants, casual employees, and employees of IT service providers must contain provisions regarding IT security in accordance with the Bank's information security policy. For example, there needs to be a clause stating that they must maintain the confidentiality of information obtained according to information classification; e. in addition to agreements between the Bank and IT service provider companies, all employees of the IT service provider company assigned to the Bank must sign a statement of confidentiality (non-disclosure statement), including confidentiality of information for customer data protection purposes; f. training and/or socialization about information security must be provided to Bank employees, consultants, casual employees, and employees of IT service providers. Training and/or socialization are provided according to the roles and responsibilities of employees and IT service providers; g. the Bank must establish sanctions for violations committed by human resources against information security policies; 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 employees of IT service providers caused by job changes or completion of employment or agreements.

5.2.3.3. Physical and Environmental Security Procedures
Physical and environmental security procedures cover 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 dividers, 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. support facilities such as air conditioning, power supply, and fire alarms must ensure capacity and availability to support the operation of information processing facilities;
d. assets owned by IT service providers, such as servers and switching tools, must be clearly identified and given adequate protection, for example, by implementing sufficient security, dual control, or placing them separately from Bank assets; and e. periodic maintenance and inspection of information processing facilities and support facilities in accordance with established procedures.

5.2.3.4. Access Control Procedures
Access control procedures cover 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 "what you know" (including PIN and password), "what you have" (including mobile phones, magnetic cards with chips, and tokens), "something you are" (including biometrics such as retina and fingerprints);
c. the Bank must have formal written procedures approved by management regarding user administration, including registration, modification, and deletion of users, both for internal and external Bank users, such as vendors or IT service providers;
d. access grants refer to the principle of business need-based access with minimal access; e. the Bank must establish control procedures through the issuance of initial passwords or PINs to users, considering among others:

initial passwords or PINs must be changed upon first login;
passwords or PINs are provided securely, for example, through double-layered carbon paper so that only authorized parties know them;
initial passwords or PINs are unique for each user and not easily guessed;
user-id owners, especially Bank employees, casual employees, and employees of IT service providers, must sign a responsibility statement or user-id and password or PIN usage agreement when receiving user-ids and initial passwords or PINs; and
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 default user-ids from the system must be replaced.
f. the Bank must require users to:
maintain the confidentiality of passwords or PINs;
avoid writing passwords or PINs on paper and other places without adequate security;
choose high-quality passwords or PINs, namely:
a) adequate password or PIN length so that it is not easily guessed; b) easy to remember and consist of at least 2 (two) types of character combinations (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 easily guessed by software (to avoid brute force attacks), for example, words like 'pass', 'password', 'adm', '123', or common dictionary words;
change passwords or PINs periodically; and
avoid using the same passwords or PINs

repeatedly;

g. The Bank must deactivate access rights when user-IDs are not used for a certain period, set the maximum number of password or PIN failures (failed login attempts), and deactivate the user after reaching the maximum number of password or PIN failures;

h. The Bank must conduct periodic reviews by a work unit not involved in the operational control of access, regarding user access rights to ensure that access rights correspond to the authority granted;

i. the operating system, application system, Database, utility, and other devices owned by the Bank can assist in the implementation of password or PIN security, for example:

forcing users to change their password or PIN after a certain period and rejecting if the user enters the same password or PIN as previously used when changing the password or PIN;
storing passwords or PINs securely (encrypted);
disconnecting or terminating user access if there is no response for a certain period (session time-out); and
deactivating or deleting user access rights if the user does not log-on for more than a certain period (expiration interval), for example due to leave, rotation, and transfer; and

j. Banks using file sharing must set access restrictions at least through the use of passwords or PINs and the arrangement of authorized parties to access.

5.2.3.5. IT Operational Security Procedures

IT operational security procedures must at least include:

a. The Bank must maintain records of the antivirus versions and software used and conduct routine monitoring of information regarding patches, upgrades, or other issues relevant to the version used, as well as perform evaluation, testing, and installation thereof;

b. The Bank must determine the type of log (e.g., administrator log, user log, or system log) and the data to be entered into the log, the storage period taking into account applicable regulations, to assist in future investigations and monitoring of access controls;

c. The Bank must conduct periodic reviews of audit trails or logs based on risk analysis results at the network, operating system, Database, or application levels;

d. Audit trails or logs must be protected against interference and unauthorized access;

e. The time indicators of all electronic systems of the Bank must be synchronized with an accurate time indicator source agreed upon;

f. The Bank must conduct periodic reviews of IT operational services provided by IT service providers. The review period must be established in the cooperation agreement between the Bank and the IT service provider; and

g. The Bank must apply physical media controls in transit, to protect media against unauthorized access, misuse, or damage during transportation outside the physical boundaries of the Bank.

5.2.3.6. Information Security Monitoring Procedures

The Bank must conduct monitoring to detect attempts threatening information security using methods determined based on risk or the criticality level of the Bank's information or IT assets. Monitoring can be conducted in real-time to provide alerts when suspicious activities occur, such as brute force attacks against administrator passwords or attempts to access servers on unusual ports, or can be conducted periodically, for example at the end of the day, based on risk levels.

5.2.3.7. Information Security Incident Handling Procedures

Matters that the Bank must consider in handling information security incidents include the following.

a. The Bank must identify the types of information security incidents, for example, users accessing a system that is not permitted or other known vulnerabilities.

b. Bank employees, honorary employees, and employees of IT service providers must report every time they know, discover, or see indications or potential incidents in information security as per letter a.

c. The Bank should consider forming 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 determine matters related to reporting information security incidents as follows:

the work unit or personnel to be contacted if Bank employees, honorary employees, or IT service providers know of an information security incident (Point of Contact/PoC);
the reporting mechanism that can be used to report information security incidents by personnel who know of the incident;
the verification mechanism by the PoC to ensure that the reported information security incident corresponds to the state of the system both before and after the reporter submits evidence of the information security incident; and
the assessment mechanism by the PoC to determine the correspondence of the report with the type of information security incident reported by the reporter. In the event that the PoC has determined that the report is classified as an information security incident, the PoC must immediately submit the report to the TRIPI.

e. The Bank must determine matters related to handling information security incidents as follows:

personnel who are members of the TRIPI, including their duties and responsibilities;
guidelines for assessing the validity of incident reports, including the classification of information security incidents reported by the PoC;
guidelines for handling information security incidents to be carried out by the TRIPI. Examples of incident classification are as follows:

a) Denial of Service (DoS);

b) physical and logical access by unauthorized parties to Electronic Systems;

c) spread of malicious code (e.g., viruses, worms, and trojan horses);

d) violation of information security policies in the use of IT resources by Bank employees, honorary employees, or IT service providers (e.g., using office email for spamming purposes); and

e) verification methods by the TRIPI to ensure that the reported information security incident reported by the PoC is true and falls under events classified as information security incidents. In the event that the reported information security incident is indeed an information security incident, the TRIPI must follow up on the information security incident according to the applicable information security incident handling guidelines;

TRIPI guidelines for handling information security incidents according to their type, covering steps including:

a) documenting all information regarding information security incidents;

b) identifying IT systems affected by information security incidents;

c) isolating IT systems identified as affected by information security incidents;

d) collecting all information stored in IT systems identified as affected by information security incidents. In the event that such information will be used as digital evidence, the collection and preservation of information must be done using forensically sound digital methods;

e) implementing solutions for information security incidents according to their type, with prior management approval;

f) in the event that the TRIPI identifies that the information security incident cannot be controlled, escalation to management must be done to activate crisis handling procedures; and

g) preparation of a complete report on information security incident handling activities to be submitted to management, both while the handling is still in progress and after the solution is implemented and the information security incident status is closed; and

updating the information security incident handling guidelines using lessons learned from previous information security incident handling activities.

f. The Bank must maintain complete documentation of an information security incident.

g. The Bank periodically reviews information security incident handling guidelines to ensure that the guidelines are relevant to the current state of the Bank's IT systems.

h. The Bank may consider providing incentives to Bank employees, honorary employees, and employees of IT service providers 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.

5.3. Risk Management Process Related to Information Security

5.3.1. Information Security Risk Measurement

The Bank conducts measurement of the tendency or probability of information security-related risks (threats exploiting weaknesses) for each asset and the magnitude of loss due to the loss of confidentiality, integrity, and availability of assets that may occur, in order to know the magnitude of potential risks that must be faced.

Each work unit in the Bank must be able to determine the possibility of threats, attacks, and vulnerabilities for each identified asset used by each work unit and the possibility of loss due to the loss of confidentiality, integrity, and availability of the assets owned.

This process must be conducted by the Bank because risk identification and measurement can show potential failures or weaknesses in the information security process that can affect the success of the Bank's business, so that the Bank can take appropriate handling of potential risks.

5.3.2. Risk Control and Mitigation

Based on the results of risk measurement, the Bank must determine the form of risk handling and control to be applied to minimize the risks faced by the Bank. The Bank can analyze the weaknesses of the applied control forms and recommend security control forms to be implemented.

Internal controls are also carried out to ensure that information security controls have been implemented, are adequate, and operate effectively in accordance with applicable information security policies, standards, and procedures. Evaluation and improvement of information security policies, standards, procedures, and systems must always be done systematically, including by conducting monitoring of:

a. developments of new techniques or methods threatening the Bank's information security system;

b. information security performance reports to identify threat trends or weaknesses in security controls;

c. follow-up on the handling of information security attacks or incidents against the Bank; and

d. the effectiveness of the implementation of information security policies, standards, procedures, and controls.

CHAPTER VI DISASTER RECOVERY PLAN

6.1 Introduction

Banking activities cannot avoid disruptions or damage caused by nature and/or humans, such as earthquakes, bombs, fires, floods, power failures, technical errors, human negligence, labor strikes, riots, and so on. Disruptions or damage that occur not only impact the Bank's technological capabilities but also impact the Bank's business operational activities, especially customer service. If not handled specifically, the Bank will face risks such as operational risk and reputational risk, which impact the decline in customer confidence in the Bank.

To minimize these risks, the Bank must have a Disaster Recovery Plan, which is an integrated and comprehensive management process to ensure that the Bank's operational activities can continue to function even in the event of disruptions or disasters, in order to protect the interests of stakeholders. The Disaster Recovery Plan emphasizes the technological aspect, focusing on data recovery (data recovery or restoration plan) and the functioning of critical IT application systems and infrastructure.

6.2. Policies, Standards, and Procedures Related to Disaster Recovery Plans

6.2.1. Policies Related to Disaster Recovery Plans

a. Formation of Disaster Recovery Plan Working Team

The Bank must have policies related to the Disaster Recovery Plan that support the effectiveness of the implementation of the Disaster Recovery Plan when needed.

The Bank needs to form an organization or working team to coordinate the implementation of the Disaster Recovery Plan, consisting of:

coordinator;
team members 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.

The roles of the working team responsible for the Disaster Recovery Plan must at least include:

i. being fully responsible for the effectiveness of the implementation of the Disaster Recovery Plan, including ensuring that awareness programs for the Disaster Recovery Plan are applied;

ii. deciding on disaster conditions and their recovery;

iii. determining the recovery scenarios to be used in the event of disruptions or disasters based on priority scales for activities, functions, and services considered critical;

iv. reviewing reports regarding each stage in the testing and implementation of the Disaster Recovery Plan; and

v. conducting communication to internal and external parties of the Bank in the event of major operational disruptions.

b. Principles of Disaster Recovery Plan Formulation

In formulating policies, strategies, and procedures to be applied to handle disaster conditions, the Bank must ensure the implementation of the following principles.

The Disaster Recovery Plan is formulated based on adequate business impact analysis and risk assessment.
The Disaster Recovery Plan is flexible to respond to various threat and disruption scenarios and unforeseen disasters originating from internal and/or external conditions.
The Disaster Recovery Plan is specific, containing certain conditions and actions required immediately to address those conditions.
Testing and updating of the Disaster Recovery Plan must be conducted periodically at least once (1) in one (1) year.
The Disaster Recovery Plan and the results of Disaster Recovery Plan testing must be reviewed periodically, at least once (1) in one (1) year.

c. Business Impact Analysis (Business Impact Analysis)

The effectiveness of a Disaster Recovery Plan depends on management's ability to identify the criticality level of various work processes or activities in the Bank before the Disaster Recovery Plan is formulated or reviewed. Thus, business impact analysis is the basis for formulating the entire Disaster Recovery Plan. Matters to be analyzed in business impact analysis include:

the criticality level of each business process and interdependence between business processes and the required priority scale;
the level of dependence on service providers, both IT and non-IT;
the period during which the Bank can operate without systems or facilities that are disrupted and/or the tolerance for the recovery time of such systems or facilities until they function again;
the minimum number of personnel, data, system completeness, and facilities required for business to operate (minimum resources requirement);
the potential impact of non-specific and uncontrollable events on business processes and customer service;
the impact of disruptions and/or disasters on all work units and business functions, not just data processing;
the estimated maximum tolerable downtime, tolerance level for data loss and business process interruption, and the impact of downtime on financial losses;
communication channels required for recovery to proceed; and
legal impact 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 formulated 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 impact) such as penalties due to late interest payments or employee overtime costs, but also those that cannot be clearly measured (intangible impact) 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 the Bank's important (critical) activities and their impact on the Bank's business continuity. Risk assessment must at least cover the following matters:

conducting analysis of the impact of disruptions or disasters on the Bank, customers, and the financial industry;
conducting gap analysis by comparing current conditions with steps or scenarios that should be applied; and
ranking potential business disruptions based on the level of damage (severity) and likelihood of occurrence (likelihood).

e. Formulation of 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, among others:

securing important Bank assets;
minimizing risks due to disasters, for example by limiting financial losses, legal risks, and reputational risks;
ensuring Bank operations continue;
ensuring continuous service availability to customers; and
preparing alternatives so that critical business functions can continue to operate to maintain Bank operational continuity.

The Disaster Recovery Plan consists of policies, strategies, and procedures necessary to ensure the continuity of business processes in the event of 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 capacity and technology level. Each chosen strategy should be accompanied by analysis or reasons underlying it and must be supported by appropriate systems and procedures.

6.2.2. Procedures Related to Disaster Recovery Plans

a. Types of Disaster Recovery Plan Procedures

The types of procedures in the Disaster Recovery Plan include, among others:

emergency response procedures (immediate steps) to control crises during disruptions and/or disasters, limit loss impacts, and determine whether to declare a state of disruption and/or disaster;
system recovery procedures that allow Bank operational activities to return to normal conditions; and
data synchronization procedures used to ensure consistency between production machine data and data at the backup site, as well as to ensure that all business processing results during the recovery period have been entered into the system.

b. Components of Disaster Recovery Plan Procedures

Each Disaster Recovery Plan procedure must at least include the following components:

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

technology

The procedures formulated must take into account the technology components owned by the Bank such as hardware, software, communication facilities, up to equipment for processing operational activities in each business function.

In addition, matters related to data files and vital records also need to be considered, such as the existence of a Disaster Recovery Center and documentation of systems and data backups.

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 an IT service provider. In the operation of the Disaster Recovery Center, the Bank must consider the following matters:

The Disaster Recovery Center should be placed in a location separate from the Data Center location, considering geographical factors:

a) the geographical scope of a disruption or disaster and its impact on the city or region where the Disaster Recovery Center location is located; and

b) risk analysis related to the Disaster Recovery Center location (such as not being located in earthquake-prone, flood-prone, or lightning-prone areas) and connected to communication and electrical infrastructure that

different from the Data Center, as well as other facilities required for the continued operation of a system;
2) the vulnerability conditions of the selected 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 Documentation, Systems, and Data
Banks must ensure the availability of effective backups of important business information, software, and related system and user documentation for each critical business function process. Matters to be considered in backup documentation, systems, and data include:

the aforementioned backups must be stored at a location other than the Data Center (off-site). Every change and modification must be documented and copies must also be updated;
backup media must be stored in a secure environment at the off-site location with adequate system security standards;
full system backups must be performed periodically. If fundamental system changes occur, full system backups must be performed as soon as possible;
all backup media must use standard labeling to identify usage, date, and retention schedule;
backup media must be tested periodically to ensure they can be used when needed (emergency situations); and
Banks must have procedures for the disposal of backup media.
e. Communication Facilities
Banks must ensure that alternative communication routes available in the Bank's operational area can be used during disruptions and/or disasters, both within the internal environment and with external parties to the Bank.

6.3. Disaster Recovery Plan Testing
Disaster Recovery Plan testing is necessary to ensure that the Disaster Recovery Plan can be implemented well during disruptions and/or disasters. Tests are conducted on the Disaster Recovery Plan at least once (1) in one (1) year for all critical systems or applications according to the results of the business impact analysis and representing all critical infrastructure, involving IT users. If the Bank uses IT service providers in its operational activities, the tests conducted must also involve such external parties. In the event the Bank makes very fundamental changes to its IT systems, applications, or infrastructure (for example, changes to the core banking system), the Disaster Recovery Plan must be tested no later than 6 (six) months after the aforementioned system changes are implemented.

6.3.1. Scope of Disaster Recovery Plan Testing
Management 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. recovery procedures for important (critical) data; and
c. the return of the Bank's operational activities and Data Center to the original business unit and Data Center locations.
Conducted tests must be documented systematically and evaluated to ensure the effectiveness and success of the testing. In the event weaknesses are found during testing, the Disaster Recovery Plan needs to be improved.

6.3.2. Disaster Recovery Plan Test Scenarios (Test Plan)
Banks must have test scenarios for each test to be conducted, and these scenarios must be reviewed for adequacy. The implementation of these scenarios must not disrupt the Bank's operational activities. The results of the tests are expected to detect weaknesses in existing procedures for the purpose of improving the Disaster Recovery Plan. In this regard, the Bank needs to validate the assumptions used in the test scenarios, including regarding:
a. the criticality of the business process functions or systems being tested; b. transaction volume; and
c. the Disaster Recovery Plan strategy chosen by the Bank.

6.3.3. Analysis and Reporting of Disaster Recovery Plan Test Results
The results of testing and analysis of any problems found during testing must be reported to the Board of Directors. Reported matters include:
a. assessment of the achievement of testing objectives; b. assessment of the validity of data processing testing;
c. corrective actions to address problems that occurred;
d. description of the gap between the Disaster Recovery Plan and test results, along with proposed changes; and e. recommendations for subsequent testing.
In the event test results fail, the Bank must review the causes of failure or problems that occurred and conduct re-testing.

6.4. Disaster Recovery Plan Maintenance and Internal Audit

6.4.1. Disaster Recovery Plan Maintenance
Banks must ensure that the Disaster Recovery Plan can be used at all times, including by storing copies of the Disaster Recovery Plan document at an alternate site, increasing the understanding of all parties in the Bank as well as IT service providers regarding the importance of the Disaster Recovery Plan, and actively participating in the implementation of the Disaster Recovery Plan.

In addition, each work unit must periodically conduct a self-assessment of the adequacy of the business impact analysis with changes that have occurred in operational activities, whether conducted by the Bank itself or by IT service providers. Banks must update the Disaster Recovery Plan to ensure its suitability with external and internal conditions. In updating, matters 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 revised Disaster Recovery Plan must be documented and distributed to IT work units.

6.4.2. Internal Audit
Internal Auditors must conduct examinations regarding:
a. the adequacy of the Disaster Recovery Plan with the Bank's risk management policies; b. the Disaster Recovery Plan covers critical activities based on the business impact analysis conducted by the Bank;
c. the adequacy of the Disaster Recovery Plan to control and mitigate risks established in the risk assessment;
d. the adequacy of the Disaster Recovery Plan testing procedures; e. the effectiveness of the implementation of Disaster Recovery Plan testing; and f. the currency of the Disaster Recovery Plan in accordance with the development of the Bank's operational activities and the results of the latest testing. Internal auditors must communicate the examination results and provide recommendations to the Board of Directors. The Board of Directors should review the audit report results and plan for improvements or corrections.

CHAPTER VII ELECTRONIC BANKING SERVICES

7.1. Introduction
Rapid IT development supports Banks in improving services to customers safely, comfortably, and effectively, including obtaining information, communicating, and conducting banking transactions via electronic media, known as Electronic Banking Services. Examples of Electronic Banking Services include Automated Teller Machines (ATM), Cash Deposit Machines (CDM), phone banking, Short Message Services (SMS) banking, Electronic Data Capture (EDC), Point of Sales (POS), internet banking, and mobile banking. The use of Electronic Banking Services has the potential to increase risks, including operational risk, legal risk, and reputational risk. Therefore, the provision of Electronic Banking Services must adhere to the principle of prudence, security principles, and adequate customer protection, and be aligned with the Bank's business strategy.

7.2. Policies, Standards, and Procedures Related to Electronic Banking Services
Pursuant to Article 28 of the MRTI POJK, the application for approval of Electronic Banking Services submitted by a Bank must be accompanied by evidence of readiness to provide Electronic Banking Services, including policies, systems, procedures, and authority in the issuance of Electronic Banking Service products. Matters to be considered include the following. a. Written policies, systems, and procedures for each Electronic Banking Service issued must at least contain:

written policies and procedures (standard operating procedures) for Electronic Banking Service products and activities;
responsibilities and authorities in the management of Electronic Banking Service products and activities;
accounting information systems for Electronic Banking Service products and activities, including their connection with the Bank's overall accounting information system; and
procedures for the identification, measurement, monitoring, and control of various risks inherent in Electronic Banking Service products and activities.
b. Each of the aforementioned written policies, systems, and procedures must meet the principle of data security control for customer data and Electronic Banking Service transactions, namely:
confidentiality principle
The Bank ensures that the methods and procedures used can protect the confidentiality of customer data;
integrity principle
The Bank ensures that the methods and procedures used can guarantee that the data used is accurate, reliable, consistent, and proven true, thereby avoiding errors, fraud, manipulation, misuse, and data destruction;
availability principle
The Bank ensures the availability of services and Electronic Systems used to generate customer data continuously;
authentication principle
The Bank must be able to test the authenticity of customer identity to ensure that information delivered and/or financial transactions are conducted by the entitled customer;
non-repudiation principle
The Bank must formulate, establish, and implement procedures that can ensure that transactions conducted by customers cannot be repudiated and can be accounted for;
authorization control principle in systems, Databases, and applications
The Bank ensures among others:
a) control over access rights and appropriate authorization for systems, Databases, and applications used in IT implementation; and

b) all confidential information and data of IT implementation can only be accessed by parties that have authorization and must be maintained securely and protected from the possibility of being known or modified by unauthorized parties;
7) segregation of duties and responsibilities principle
The Bank ensures there is a separation of duties and responsibilities related to systems, Databases, and applications used in IT implementation to ensure the implementation of check and balance functions, for example, there is a separation of duties between the party that initiates or inputs data and the party responsible for verifying and/or authorizing the correctness of that data; and
8) maintenance of audit trails principle
The Bank ensures the availability and maintenance of transaction logs in accordance with data retention policies and statutory regulations, so that clear audit trails exist to help prove, resolve disputes, and detect intrusion attempts on Electronic Systems. The Bank must analyze and evaluate audit trail functions periodically. In establishing security controls on Electronic Banking Services, besides paying attention to service security for customers, the Bank must also pay attention to the security and rights and obligations of other parties related to and/or cooperating with the Bank in providing Electronic Banking Services, specifically regarding the management, use, and storage of Electronic Banking Service customer data.

7.3. Electronic Banking Service Risk Management

7.3.1. Measurement of Risks Related to Electronic Banking Services
Measurement is conducted on potential losses (loss events) occurring in each type of Electronic Banking Service. To monitor the magnitude and trend of risks from each type of Electronic Banking Service, the Bank must create a Database containing historical loss data (loss event database) for each type of Electronic Banking Service. Types of risks related to Electronic Banking Services are as follows. a. General risks, including:

operational risk, which is a risk arising from or originating from fraud, errors in processes, system disruptions, or unexpected activities that cause the Bank's inability to provide products or services and cause losses to the Bank and customers. Operational risk may also include risks related to transactions that may arise from inadequate implementation of security control principles;
credit risk, which is a risk that arises when the Bank provides credit via electronic media, for example, credit card products;
legal and compliance risk arising from:
a) non-compliance with laws and/or regulations from supervisory authorities; b) differences with laws in other countries in the event of cross-border transactions; c) non-compliance with statutory regulations regarding customer data confidentiality and statutory regulations regarding product information transparency; and d) limitations of statutory regulations as the legal basis for Electronic Banking Service transactions;
strategic risk, which is a risk that may arise from:
a) inconsistency with the Bank's business objectives or plans; b) inadequate investment planning in Electronic Banking Services can cause suboptimal return on investment obtained compared to costs incurred; and c) suboptimal relationship management with IT service providers;
reputational risk, which is a risk arising from the possibility of decreased or lost customer trust because service level delivery to customers is not maintained, such as delays or unavailability of Electronic Banking Services, slow response to customer complaints, system insecurity, and system disruptions;
market risk, which is a risk that arises when the Bank creates products with features that allow transaction execution exposed to changes in interest rates, changes in exchange rates, for example, in internet banking transfer services from the customer's IDR account to a foreign currency destination account abroad; and
liquidity risk, which is a risk that arises when the Bank does not limit the amount that corporate customers can transfer via internet banking.
b. Specific risks, including:
operational risk that may arise from Electronic Banking Service transactions, including fraud, eavesdropping, errors, damage, or system failure;
risks that may arise from cross-border Electronic Banking Service transactions, including legal risk given that transactions cross different legal jurisdictions. This risk arises because there are differences in statutory regulations between the two legal jurisdictions, such as consumer protection, bank and customer personal data confidentiality, reporting requirements, and anti-money laundering and counter-terrorism financing;
risks in the provision of internet banking include:
a) customers obtaining incorrect or inaccurate information via the internet;

b) theft of financial data from the Bank's Database via informational and communicative internet banking that is not isolated; c) threats or attacks such as defacing, cybersquatting, denial of service, network interception, man-in-the-middle attacks, and viruses; d) identity theft, such as phishing, key logging, spoofing, and cybersquatting; and e) transactions conducted by unauthorized parties or fraud occurring;
4) security threats on products using wireless technology, such as mobile banking, include communication eavesdropping because not all mobile banking transactions are encrypted, denial of service attacks, viruses, worms, trojans, and SIM card cloning; and
5) security threats on phone banking products that are vulnerable to eavesdropping.

7.3.2. Control of Risks Related to Electronic Banking Services
In the context of risk control, the Bank must mitigate general and specific risks that may occur in Electronic Banking Services by paying attention to the principle of data security control for customer data and Electronic Banking Service transactions, including by:
a. taking adequate steps to test the authenticity (authentication) of identity and authority (authorization) of customers conducting transactions via Electronic Banking Services; b. having written policies and procedures to ensure that the Bank is able to test the authenticity of customer identity and authority;
c. using various methods to test authenticity based on the Bank's risk management assessment of Electronic Banking Services, sensitivity, and the value of stored data. In using authenticity testing methods,
the Bank pays attention to the following matters:

applying at least a combination of 2 (two) authentication factors (two-factor authentication), namely “what you know” (such as PIN or password), “what you have” (such as electronic identity, magnetic stripe cards with chips, tokens, or digital signatures), and/or “something you are” (including biometrics such as retina or fingerprints);
minimum character requirements for PINs. Specifically for PINs used in payment instruments using cards, mobile banking, and internet banking, the PIN length must consist of at least 6 (six) digit characters;
the existence of a maximum limit for incorrect PIN entry to hinder unauthorized access attempts;
the Bank must ensure the application of the prudence principle in the use of authenticity testing methods, including:
a) the creation, validation, and encryption of PINs and other authenticity testing methods must use methods believed to be secure. Specifically for encryption methods used on card-based payment instruments, PIN encryption methods must at least use the Triple Data Encryption Standard (Triple DES) method based on card and/or chip standards that meet standards; b) the authenticity testing Database providing access to customer accounts in Electronic Banking Services is protected from disruption and destruction; c) every addition, deletion, or change to the Database and authenticity testing has been properly authorized by the competent party; d) specifically for Electronic Banking Services using cards, the function of PIN creation and delivery must be separate from the function of card creation and delivery;

e) specifically for Electronic Banking Services using cards, card functionality and security must be tested using card and chip standards that meet standards; f) there are appropriate control mechanisms for the Electronic Banking Service system so that unknown third parties cannot replace known customers; and g) there is a policy stating that if there are indications of data theft related to customer authentication aspects, the Bank must replace the aforementioned customer authentication data as soon as possible;
5) the Bank must formulate and establish procedures to ensure that transactions cannot be repudiated by customers (non-repudiation) so that transactions can be accounted for, including among others:
a) the Electronic Banking Service system has been designed to eliminate the possibility of transactions being conducted accidentally by entitled users; b) all parties conducting transactions have been tested for authenticity; c) financial transaction data is protected from the possibility of alteration and every alteration can be detected. The recording process for financial transactions must be designed as well as possible to prevent unauthorized alteration attempts. Every attempt at unauthorized alteration must be recorded and become the attention of the Bank's management; and d) the application of methods to ensure the fulfillment of the non-repudiation principle, such as digital signatures and Public Key Infrastructure (PKI). Keys used for encryption purposes must be maintained securely so that no one knows the complete combination of keys;

d. ensuring the separation of duties and responsibilities related to the use of systems, Databases, and Electronic Banking Service applications. The Bank must ensure the existence of dual control and separation of duties to ensure the implementation of check and balance functions. The Bank needs to ensure there is a separation of duties between the party that initiates or inputs data and the party responsible for verifying the correctness of that data. For example, in a banking application, every addition or change to the Database performed by a data entry operator will be effective as long as it is approved by a supervisor; e. ensuring the existence of control over authorization and access rights (privileges) that are appropriate for systems, Databases, and Electronic Banking Service applications. All confidential Bank archives and data can only be accessed by parties that have authority and authorization. Confidential Bank data must be maintained securely and protected from the possibility of being known or modified by unauthorized parties; f. ensuring methods and procedures are applied to protect the integrity of data, records, and information related to Electronic Banking Service transactions by paying attention to the following matters:

the Bank must apply appropriate methods and techniques to reduce external threats such as virus attacks and malicious transactions, including:
a) software – providing virus scanning and anti-virus for all entry points and each computer; b) software to detect intrusions (intrusion detection system); and c) penetration testing of internal and external networks periodically at least once (1) in one (1) year;
the Bank must conduct integrity testing of Electronic Banking Service transaction data; and
The Bank must implement controls to ensure that all transactions are executed correctly;

g. ensuring the availability of a clear audit trail mechanism for all Electronic Banking Services transactions, which includes the following:

The Bank must maintain transaction logs based on the Bank's data retention policy in accordance with applicable laws and regulations to provide a clear audit trail and assist in dispute resolution. Required transaction data must include at least customer data, account number, type, time, location, and transaction amount;
The Bank must notify customers when a transaction has been successfully completed. If a transaction is rejected, it must be documented and there must be follow-up procedures; and
The Bank must ensure the availability of audit trail functions to detect attempts and/or occurrences of intrusion, which must be reviewed or evaluated periodically. If the processing system and audit trail are the responsibility of a third party, the audit trail process must comply with standards established by the Bank. The Bank must have sufficient authority to access the audit trails maintained by such third parties;

h. detecting and monitoring unauthorized or unusual transactions, for example through Intrusion Detection Systems (IDS) and fraud detection. Subsequently, the Bank must have procedures for handling detected problems or crimes;

i. implementing steps to protect the confidentiality of Electronic Banking Service information. Security procedures are adjusted according to the sensitivity level of the information;

j. having standards and controls over the use and protection of data if the IT service provider has access to such data;

k. having a Disaster Recovery Plan, including an effective contingency plan, to ensure the continuity of Electronic Banking Service systems and services; and

l. developing a quick and accurate incident response plan to manage, address, and minimize the impact of an incident, fraud, system failure (internal and external), which could hinder the provision of Electronic Banking Service systems and services.

7.3.2.1. Risk Controls for Specific Electronic Banking Services

a. In providing Electronic Banking Services, for example, at ATMs and internet banking, the Bank must also pay attention to customer comfort and ease of use of the facilities, including the effectiveness of the Electronic Banking Service display menu, particularly in making desired message selections to avoid errors and losses in transactions.

In order to enhance security, the Bank may establish requirements or impose transaction restrictions through Electronic Banking Services to ensure transaction security and reliability, for example, by requiring customers to register third-party accounts that are the destination of transfers in mobile banking or by limiting transaction amounts via ATMs and internet banking.

b. In organizing Electronic Banking Services that provide physical facilities such as ATMs, the Bank must implement physical security controls over the equipment and rooms used against the dangers of theft, destruction, and other criminal acts by unauthorized parties. The Bank must conduct routine monitoring to ensure security and comfort for customers using Electronic Banking Services.

c. The Bank must ensure security over the data transmission aspect between Electronic Fund Transfer (EFT) terminals and the host computer, against risks of transmission errors, network disturbances, access by irresponsible parties, and others. Security includes controls over the equipment used, monitoring of Controller (Host-Front End) software access, and monitoring of the quality and accuracy of network device and transmission channel performance.

d. Point of Sales (POS) or Electronic Data Capture (EDC) allows for the electronic transfer of funds from customer accounts to acquirer or merchant accounts for transaction payments. Transactions are conducted through POS Terminals located in shopping centers or supermarkets, generally using a card payment instrument. POS provision can be done independently by the issuing Bank, financial acquirer, technical acquirer, and switching companies. POS Terminal providers must always enhance physical security around the POS Terminal location and the POS Terminal itself, for example, by using POS Terminals that minimize the possibility of eavesdropping, both on the POS Terminal itself and in the communication network.

e. For Banks providing mobile banking services, the Bank must ensure transaction security, including:

using a SIM Toolkit with end-to-end encryption features from the mobile phone to the mobile banking server, to protect data transmission on mobile banking; and
performing mutual authentication, meaning the Bank and the customer can perform an authentication process with a digital certificate or personal authentication message, to help the customer ensure that the party transacting with the customer is the correct party.

f. In providing phone banking IT services, the Bank must ensure transaction security through the following:

the service is not used for transactions with high value or risk;
all conversations via Interactive Voice Response (IVR) are recorded, including the customer's phone number, transaction details, and others;
the service uses reliable and secure authentication methods; and
the use of customer authentication methods such as PIN and password for financial transactions.

7.3.2.2. Risk Controls Related to Cross-Border Electronic Banking Services

In organizing cross-border Electronic Banking Services, the Bank must, among other things, pay attention to:

a. building an effective risk management program for cross-border Electronic Banking Service activities. Before the Bank introduces cross-border Electronic Banking Service products and services, Bank management should conduct appropriate risk assessment and due diligence to ensure that the Bank manages existing risks appropriately. In addition to paying attention to legal aspects and applicable laws and regulations in Indonesia, the Bank needs to pay attention to legal aspects and regulations in the country where the Bank will offer cross-border Electronic Banking Services; and

b. sufficient disclosure on the website or other information allowing prospective customers to know the Bank's identity, home country, Bank's supervisory authority, and permits obtained by the Bank, before establishing a business relationship with the Bank.

7.3.2.3. Risk Controls Related to Electronic Banking Services Organized by IT Service Providers

In cases where the organization of Electronic Banking Services systems is carried out by IT service providers, such as switching companies and Internet Service Providers (ISP), the Bank must establish and implement comprehensive and continuous supervision and due diligence procedures to manage the Bank's relationship with such IT service providers. To this end, the Bank must create a written agreement with the IT service provider related to Electronic Banking Services that details rights and obligations, security aspects, and monitors the performance of the IT service provider according to the SLA.

7.4. Plan for Issuance of New Electronic Banking Services

The term "new Electronic Banking Service product" refers to a new product whose characteristics differ from existing products at the Bank and/or adds or increases certain risk exposures at the Bank, such as internet banking and mobile banking for depositors.

Thus, if the Bank only adds service types to existing Electronic Banking Service products and the added risk is not significant, for example, adding payment facilities through Electronic Banking Services that previously only handled credit card payments to now handling electricity or telephone payments, such payment service additions are not classified as new products and therefore do not need to be reported.

However, if the Bank adds services, for example, from previously only handling Rupiah transactions to now adding foreign currency transactions, the Bank must report such new products because, based on risk analysis, such transactions can increase market risk, legal risk, and other risks.

In cases where IT used to organize Electronic Banking Services is carried out by IT service providers, the regulations regarding the use of IT service providers also apply.

7.5. Application for Approval Related to Electronic Banking Services

Applications for approval for the issuance of Electronic Banking Services do not apply to Electronic Banking Service products regulated specifically in regulations regarding product approval requirements.

In addition to proof of readiness and supporting documents for organizing Electronic Banking Services as regulated in Article 28 of the POJK MRTI, the Bank is also required to complete the Electronic Banking Service approval application with the results of a business analysis regarding projections for the new product for the next 1 (one) year, containing at least:

a. existing market potential; b. target market segments;
c. business competition analysis;
d. target customers to be achieved; e. cooperation plans with other parties; and f. target revenue to be achieved.

7.6. Realization of Electronic Banking Services

7.6.1. Examination by Independent Parties

The Electronic Banking Service realization report must be supplemented with a post-implementation review by an independent party. An independent party is a party not involved in the design and development of application systems, nor in decision-making for implementation.

The results of the examination by the independent party are intended to provide an opinion on the product characteristics and the adequacy of IT system security related to the product, as well as compliance with applicable laws and regulations and/or best practices meeting international standards such as ISO, IEC, COBIT, and ITIL.

Examination results from independent parties outside the Bank, such as public accounting firms or information technology security consulting companies, are required for Electronic Banking Service products issued by the Bank for the first time, such as transactional internet banking and transactional SMS banking. Whereas for adding features to existing Electronic Banking Service products at the Bank, which can add or increase the Bank's risk exposure, an internal party may be used to conduct an independent review.

Examples:
a. adding a feature for inter-account fund transfers via ATM that was previously not possible for customers; b. adding a feature for inter-bank transfers via ATM that was previously not possible for customers.

The Bank needs to ensure that external parties have competence and understanding of the product to be reviewed, particularly in IT security aspects. In cases where the Bank uses an internal party to conduct an independent review, the Bank must submit a description of the duties and responsibilities of such parties and their position within the organizational structure of the Electronic Banking Service development project.

7.6.2. Scope of Independent Party Examination

The Bank must ensure that the report submitted by the independent party regarding the Bank's IT readiness for planned Electronic Banking Service activities includes the examination period, scope, examination methods, findings, recommendations, management's response to findings, and completion targets. The scope of the examination includes:

a. active management supervision; b. adequacy of policies and procedures for securing Electronic Banking Service systems to ensure the fulfillment of confidentiality, integrity, availability, and non-repudiation principles in every Electronic Banking Service transaction;
c. adequacy of implementation and monitoring of Electronic Banking Service system security prepared by the Bank, including:

implementation of system security, infrastructure (servers, firewalls, and routers), and Electronic Banking Service system networks;
security to detect unusual transactions;
maintenance and review of transaction audit log trails;
adequate physical security for computer devices and communication devices related to Electronic Banking Services;
security for the Bank's internal network so that it is protected from attacks originating from external sources; and
security for data and Databases (Database) of Electronic Banking Service transactions;

d. handling of specific conditions, including fraud; e. Disaster Recovery Plan and emergency response procedures (incident response management); f. use of IT service providers as organizers of Electronic Banking Services; g. review of risk analysis for new Electronic Banking Service products, covering at least strategic risk, security risk, legal risk, and reputational risk; and h. customer education and protection programs, including caution in account opening and in conducting transactions through Electronic Banking Services.

CHAPTER VIII INTERNAL IT AUDIT

8.1. Introduction

An effective Internal Control System (SPI) is an important component in Bank management and serves as the foundation for healthy and safe Bank operations. An effective SPI, among other things, can help Bank management 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 organization of IT, the Bank must implement SPI effectively across all aspects of IT usage. Internal IT Audit, as part of SPI, is necessary to conduct independent and objective evaluations of IT organization to improve the efficiency and effectiveness of risk management, internal controls, and good governance. The IT Audit referred to includes audits of Data Centers, Disaster Recovery Centers, applications, and/or Technology-Based Transaction Processing.

8.2. Policies, Standards, and Procedures Related to IT Audit

In accordance with Article 18 of the POJK MRTI, the implementation of the internal IT audit function pays attention to compliance with regulations regarding standards for the implementation of the internal audit function.

In order to ensure the implementation of internal IT audits, the Bank must ensure the availability of audit trails for all IT organization activities for supervision, law enforcement, dispute resolution, verification, testing, and other examinations.

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

In order to conduct IT audits, the Bank must have policies, standards, and procedures covering:

a. IT Audit Policy must at least include:

the purpose and background of the need for IT audits;
a statement of independence from 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 access, information, personnel, systems, and other matters necessary to ensure 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 provision and responses by the auditee;
a statement that every Bank activity must fall within the scope of the Bank's IT audit;
violations of IT audit policies; and
periodic review at least 1 (one) time in 3 (three) years of the IT audit function as part of the overall internal audit function by an independent party.

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

Audit Working Plan (AWP);
audit working papers including audit results or findings;
Audit Results Report (LHA); and
monitoring of follow-up on audit results.

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

management;
development and procurement;
IT operations;
communication networks;
information security;
Disaster Recovery Plan;
Electronic Banking Services;
use of IT service providers;
provision of IT services by the Bank; and
business applications such as core banking systems, credit cards, treasury, remittance, and trade finance.

Examination steps are adjusted according to each object and scope of examination.

8.3. IT Audit Process

a. IT Audit Planning

The Bank must have an IT audit plan covering the frequency and schedule of IT audits. In conducting risk assessment, internal IT audit must at least perform the following:

identify IT assets in the form of data, applications, operating systems, technology, facilities, and personnel;
identify activities and business processes using IT; and
identify the level of IT risk impact on Bank operations and consider priority scales based on risk levels.

The IT audit plan must receive approval from the President Director or Director.

b. IT Audit Execution

The execution of IT audits aims to:

a) ensure that policies, standards, and procedures for IT organization are applied 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 applied in IT organization; e) provide improvement recommendations to address deficiencies in IT organization; and f) ensure IT organization compliance with applicable laws and regulations.

In implementing the annual IT audit plan, the audit working plan must be prepared for each audit assignment, covering at least:

a) audit objectives, schedule, number of auditors, budget, and reporting; b) audit scope according to risk assessment results; and c) division of tasks and responsibilities of auditors.

In performing duties, IT auditors must pay attention to the confidentiality of data and information obtained. IT audit execution must use standard examination working papers and be well documented. IT auditors may request data or information for the purpose of performing duties, both in hardcopy and softcopy form, including Databases (Database) from applications.
IT auditors must uphold the code of ethics (ethics) in performing duties, as follows:

a) integrity

work with honesty, diligence, and responsibility;
comply with regulations and make disclosures in accordance with regulations;
not engage in illegal activities; and
respect and play a role in supporting Bank objectives;

b) objectivity

not participate in activities that can affect the objectivity of audit task execution;
not accept anything that can affect audit task execution and work according to expertise; and
disclose facts as found during audit task execution;

c) confidentiality

be careful in using data or information and protect data or information obtained during audit task execution; and
not use data or information obtained for personal interests or contrary to law; and

d) competence

have adequate knowledge;
perform audit tasks according to standards established by the Bank; and
continuously strive to improve abilities to enhance audit quality.

Statements regarding IT auditor ethics can be formulated in the form of a written statement signed by each Bank IT auditor personnel, including sanctions if the individual violates such ethics.

c. Reporting

In accordance with Article 30 of the POJK MRTI, the Bank is required to report IT audit results no later than 2 (two) months after the audit is completed. The IT LHA is prepared based on a standard report format. The report serves as a tool for management to help assess the quality of IT controls. The IT LHA must be submitted to the audited work unit. In addition, the report must be submitted promptly to the Director and the Board of Commissioners or audit committee, with a copy to the director overseeing the compliance function. Key points of IT audit results are also submitted to the Financial Services Authority (OJK).

d. Follow-up Monitoring

The auditee must respond to the examination results. If findings require follow-up, the auditee must provide commitment and completion time targets. Subsequently, the IT auditor must periodically monitor the auditee's implementation of commitments regarding examination results and verify the improvements made.

The IT auditor must maintain documentation of such follow-up results. The follow-up report on examination results is submitted to the Director and the Board of Commissioners or audit committee, with a copy to the director overseeing the compliance function.

Changes to the plan and realization of follow-up, as well as completion targets for follow-up, must be submitted to the IT auditor and approved by the Director and the Board of Commissioners or audit committee, with a copy to the director overseeing the compliance function.

8.4. Fulfillment of Internal IT Audit Function

In cases where there are limitations in the capabilities of the internal audit work unit, the internal IT audit function can be carried out by external auditors. The use of external auditors to perform the internal audit function over IT does not reduce the responsibility of the internal audit work unit leadership. In addition, the use of external auditors must consider the size and complexity of the Bank's business and pay attention to applicable laws and regulations regarding external auditors, and its implementation is carried out according to the Bank's IT audit standards and procedures.

The implementation of the internal IT audit function by external auditors still pays attention to competence (including 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 that IT audit functions run effectively.

CHAPTER IX USE OF THIRD-PARTY IT SERVICE PROVIDERS

9.1 Introduction
In order to increase the effectiveness and efficiency of achieving strategic objectives, Banks are permitted to use third-party IT service providers. This is in accordance with Article 20 of the POJK on MRTI which regulates that IT implementation can be carried out by the Bank itself and/or third-party IT service providers. The term "using third-party IT service providers" refers to the use of services from other parties in carrying out IT activities that may cause the Bank to have dependence on the services provided continuously or for a certain period. The use of third-party IT service providers can affect the Bank's risks, including operational, compliance, legal, and reputational risks. These risks can arise, among others, due to the failure of the IT service provider to provide services, legal violations, or the inability to comply with laws and regulations. The Financial Services Authority (OJK) has the authority to supervise all IT implementation activities carried out by the Bank itself or by third-party IT service providers. Therefore, Bank examinations and supervision must not be hindered by the transfer of the Bank's operational functions to third-party IT service providers.

9.2. Policies, Standards, and Procedures for the Use of IT Service Providers
In the event that the Bank's IT implementation is carried out by third-party IT service providers, the Bank must comply with the provisions regulated in Article 20 of the POJK on MRTI, and must have policies, standards, and procedures for the use of IT service providers.

9.2.1. Policy on the Use of IT Service Providers
The Bank must have a policy regarding the implementation of IT to third parties that at least regulates:
a. Principles of using IT service providers

The Bank remains responsible for IT services implemented by third-party IT service providers;
the use of IT service providers does not hinder the supervision process by the Financial Services Authority;
decisions to use IT service providers must align with the Bank's IT strategic plan;
every use of IT service providers must be stipulated in a written agreement;
the use of IT service providers must provide greater benefits compared to the costs incurred by the Bank; and
the use of IT service providers must be based on an arm's length principle relationship, in the event that the IT service provider is a related party to the Bank.
b. Policy statement from management
Decisions to use IT service providers must generally consider efficiency and risk factors. Therefore, the use of IT service providers must meet the principles of using IT service providers as referred to in letter a. In addition, in:
the use of IT service providers must receive management approval;
the selection of IT service providers must go through a due diligence process;
the selection of IT service providers for IT services must go through a selection process from several providers; and
the IT service provider agreement must allow for termination clauses according to the agreement period or before the agreement period ends.
c. Roles and responsibilities of parties related to the use of IT service providers
As part of policy implementation, every role must be allocated to designated Bank management, with responsibilities:
ensuring that IT service providers meet needs and align with the Bank's strategic plan;
ensuring the Bank has the expertise to supervise IT service providers;
evaluating potential IT service providers based on the scope and services to be implemented;
ensuring there is a maintenance agreement with IT service providers in the event of IT procurement cooperation;
monitoring and conducting periodic risk assessments against services implemented by IT service providers; and
ensuring that the Financial Services Authority is given access to conduct examinations against services implemented by IT service providers.

9.2.2. Standards for the Use of IT Service Providers
The Bank must have standards regarding the implementation of IT to third parties that at least covers:
a. standards for selecting IT service providers in accordance with the complexity of IT services required by the Bank; b. standards for managing IT service providers in accordance with regulations and adequate governance; and
c. standards for the content of cooperation agreements with IT service providers, including:

scope of work or services;
costs and duration of the cooperation agreement;
rights and obligations of the Bank and the IT service provider;
guarantees of data security and confidentiality, especially customer data. Data can only be accessed by the data owner (the Bank);
service level guarantees (SLA), containing performance standards such as agreed service levels and performance targets;
SLAs remain valid in the event of ownership changes in both the Bank and the IT service provider;
reports on the monitoring results of IT service provider performance related to SLAs;
risk limits borne by the Bank and the IT service provider, including:
a) risk of changes in the scope of the agreement; b) changes in the business scope and organization of the IT service provider's company; c) changes in legal and regulatory aspects; and d) legal aspects including copyrights, patents, and logos or trademarks;
written approval from the Bank in the event that the IT service provider transfers part of its activities (subcontracting) to subcontractors. In addition, subcontractors must have adequate IT implementation standards;
availability of communication facilities connected to the internet network and security against access and data transmission to and from the Data Center and/or Disaster Recovery Center;
clear arrangements regarding data backup, policies in contingency situations threatening the Bank's operational continuity, protection of the Bank's data (record protection) including hardware, software, and equipment, to ensure the continuity of IT implementation;
arrangements regarding security in the transmission of source documents required from and to the Data Center and/or Disaster Recovery Center. The responsible party should be protected by adequate insurance;
willingness to be audited by the Bank's internal auditors, the Financial Services Authority, and/or external parties designated by the Bank or by the Financial Services Authority, and the availability of information for examination purposes, including access rights, both logically and physically, to data managed by the IT service provider;
the IT service provider must provide technical documents to the Bank related to the services performed by the IT service provider, including IT process flows and Database structures;
the IT service provider must report every critical incident that could cause financial losses and/or disrupt the Bank's operational smoothness;
specifically for the implementation of Data Centers, Disaster Recovery Centers, and IT-based Transaction Processing, the IT service provider must submit the latest audited financial reports to the Bank annually. IT service providers submit the results of IT audits conducted by independent auditors periodically regarding the implementation of Data Centers, Disaster Recovery Centers, and/or IT-based Transaction Processing to the Financial Services Authority through the relevant Bank;
the IT service provider's responsibility to provide human resources with qualifications and competencies appropriate to the services provided to ensure the Bank's operations remain guaranteed;
human resource training plans, including the number of personnel trained, the form of training, and the costs required. The IT service provider must transfer knowledge to the Bank, so that there are personnel in the Bank's IT work units who understand the IT used by the Bank, especially regarding IT process flows and Database structures of the systems provided by the respective IT service provider;
ownership and licenses;
guarantees from the IT service provider that the provision of services will still be given to the Bank for a certain period after implementation;
changes, termination, or cancellation of agreements, including in the event that the Financial Services Authority orders the Bank to stop the provision of IT services before the end of the agreement period;
sanctions and penalties for unclear reasons for agreement cancellation and violations of agreement content;
compliance with laws and regulations in Indonesia;
system security standards to be met by the IT service provider;
service level standards to be met by the IT service provider;
standards for monitoring reports on IT service provider performance; and
standards for document storage agreements (escrow agreements).

9.2.3. Procedures for the Use of IT Service Providers
The Bank must have procedures for the use of IT service providers, namely IT service provider selection procedures that at least cover:
a. Needs Definition
Needs definition must at least consider:

Defining business needs for the use of third-party IT service providers must be done before the Bank decides to use third-party IT service providers, including:
a) specific identification of functions or activities whose implementation will be handed over to the IT service provider; b) risk assessment processes that may arise from handing over the implementation of such functions or activities; and c) establishing the basis to be used to identify adequate control measurements.
The needs definition stage above must produce a document containing a detailed description of the Bank's desires for the services to be performed by the IT service provider. The content of the document includes the following components:
a) scope and characteristics of the services and technology used and 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 IT service provider 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 the system provided by the IT service provider; f) duration, termination, and minimum content of the agreement; and g) agreement protection against obligations such as limitation of liability and compensation as well as insurance. In the event that the implementation of defined activities or functions is considered to be carried out by a related party to the Bank, the Bank's management must ensure that the preparations made are no different if it were to be carried out by an unrelated party to the Bank. b. Request for Proposal from IT Service Providers The IT service provider selection process begins with a request for proposal from the IT service provider. 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, detailed service costs, work measurement and control, security, and business continuity. The Bank must be able to ensure the IT service provider's policies related to the audit interests of the Bank's IT implementation for access by internal auditors, external auditors, and the Financial Services Authority. Thus, data and information required from IT implementation can still be obtained accurately and on time whenever needed, even if IT is not implemented by the Bank itself.
c. Due Diligence of IT Service Providers
Due diligence needs to be conducted to assess reputation, technical capabilities, operational capabilities, financial conditions, development plans, and the ability to follow IT innovations in the market, so that the Bank gains assurance that the IT service provider can meet the Bank's needs. During due diligence, the Bank must consider, among others:
existence and history of the IT service provider's company;
qualifications, background, and reputation of the owners of the IT service provider's company;
other companies using the same services from the IT service provider as references;
ability and effectiveness of service provision, including after-sales support;
technology and system architecture;
internal control environment, security history, and audit scope;
compliance with laws and regulations;
trust and success in relationships with subcontractors;
maintenance guarantees;
ability to provide disaster recovery and business continuity;
implementation of risk management;
reports on independent examination results; and
financial conditions including 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 pay attention to changes or developments that have occurred during the period since the last due diligence using the latest information. d. Determination of IT Service Providers In determining IT service providers, the Bank must consider, among others:
The Bank must periodically evaluate the implementation of risk management by the IT service provider to ensure that the use of third-party IT service providers does not reduce the Bank's responsibility in implementing risk management;
The Bank must ensure that the reports required to monitor the performance of IT service providers are adequate;
The Bank must conduct cost-benefit analysis for each alternative to be selected;
The Bank must ensure that IT service providers can submit the latest audit results of IT conducted by independent parties, especially for the implementation of Data Centers and/or Disaster Recovery Centers;
The Bank can obtain information from various sources including annual reports of IT service providers in order to monitor and evaluate the reliability of IT service providers periodically, both regarding performance, IT service provider reputation, and continuity of service provision;
The Bank must ensure that access to the Database can be done by the Financial Services Authority at any time for both current and past data; and
The Bank must apply the "arm's length principle" with IT service providers, including related parties to the Bank. The Bank must conduct a selection process and document it.
e. Creation of Cooperation Agreements with IT Service Providers After selecting an IT service provider company, management creates a written agreement with the IT service provider in accordance with the Bank's agreement standards. In drafting the agreement, the Bank must consider the following:
agreement content in accordance with the Bank's agreement standards;
through a discussion process with the legal work unit; and
considering the existence of special clauses for terminating the agreement before the end of the agreement if the IT service provider is in breach.
f. Special Clauses
Special clauses consider, among others, as follows:
Agreements made between the Bank and IT service providers must include special clauses regarding the possibility of changing, making new agreements, or taking over activities implemented by the IT service provider or terminating the agreement before the end of the agreement. This includes at the request of the Financial Services Authority if necessary, considering that implementation by the IT service provider may interfere with the implementation of the Financial Services Authority's duties.
The Bank is able to measure the risk and efficiency of IT implementation handed over to third-party IT service providers so that the Bank can know early if there are conditions:
a) deterioration of IT service performance by the IT service provider that can have a significant impact on the Bank's business activities; b) the solvency level of the IT service provider is inadequate, in the process of liquidation, or declared bankrupt by the court; c) there are violations of regulations regarding Bank secrecy and customer personal data; and/or d) there are conditions that cause the Bank to be unable to provide data required for effective supervision by the Financial Services Authority.
In the event that the Bank finds matters as referred to in number 2), the Bank must do the following:
a) report to the Financial Services Authority at the latest 3 (three) working days after the Bank becomes aware of the above conditions; b) decide on follow-up actions to be taken to address the problems, including stopping the use of IT services if necessary; and c) report to the Financial Services Authority immediately after the Bank stops using IT services before the end of the agreement period.
To maintain the Bank's business continuity in the event that the use of IT services is stopped before the end of the agreement, the Bank must have a tested and adequate follow-up plan (contingency plan) in force majeure situations.
g. Use of IT Service Providers Outside Indonesia Banks planning to use IT service providers outside Indonesia must not hinder supervision or examination by the Financial Services Authority. Similarly to the use of domestic IT service providers, the use of foreign IT services or those located outside Indonesia must go through the same procedures, namely starting from due diligence, selection of IT service providers, creation of agreements, and supervision, but because it involves differences in jurisdiction, there are other requirements that must be considered by the Bank. The use of third-party IT service providers outside Indonesia must first obtain approval from the Financial Services Authority.

9.3. Risk Management Process

9.3.1. Risk Identification
Risk identification must at least consider the following. a. The use of other third-party IT service providers in implementing the Bank's IT can contribute to several types of risks, namely:

operational risk, which is the inability of the IT service provider to fulfill the agreement;
legal risk, which is legal uncertainty over disputes with the IT service provider, third parties, and/or customer claims over the misuse of customer data by the IT service provider;
reputational risk, which is customer dissatisfaction due to the IT service provider's inability to meet SLAs;
strategic risk, which is the mismatch of IT used by the Bank with the Bank's strategic objectives and plans made to achieve those objectives;
compliance risk, which is the Bank's inability to comply with regulations; and
country risk – conditions in foreign countries that can affect the IT service provider's ability to meet service standards.
b. In conducting risk identification, measurement, monitoring, and control, the Bank must consider:
related to activities and functions implemented by the IT service provider, including the sensitivity of data accessed, protected, or controlled by the IT service provider, transaction volume, and the level of importance of such activities and functions to the Bank's business;
related to the IT service provider such as financial conditions, workforce competence, management and workforce turnover, the IT service provider's experience, and professionalism; and
related to the technology used, including reliability, security, availability, and timeliness, as well as the ability to follow technological developments and changes in regulations.

9.3.2. Risk Measurement
After risks are identified, the Bank must measure these risks to determine the level of risk faced. The measurement of risk from the use of IT service providers must be integrated with the measurement of other IT-related risks using the same risk measurement approach. The results of measuring the risk of using IT service providers must produce a risk level which subsequently becomes one of the parameters for the overall IT risk assessment of the Bank.

9.3.3. 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 the risk level. The risk mitigation actions taken by the Bank must be effective in controlling risks. a. Examples of risk mitigation actions that the Bank can take include implementing controls to reduce the likelihood of risk occurrence, such as:

adequate IT service provider agreements;
periodic monitoring of provider performance; and
selection of reliable IT service providers.
b. Other risk mitigation actions include reducing the impact of losses if identified risks occur, such as insurance and Disaster Recovery Plans.
c. The Bank must ensure that the risk of dependence on third-party IT service providers can be mitigated so that the Bank remains able to conduct its business if the IT service provider breaches the agreement, terminates the relationship, or is in the process of liquidation. Mitigation risks that can be done include:
ensuring that the IT service provider has a Disaster Recovery Plan in accordance with the type, scope, and complexity of activities or services provided;
actively obtaining guarantees of the IT service provider's Disaster Recovery Plan readiness, such as periodic testing of the Disaster Recovery Plan;
having a source code escrow agreement, if the Bank does not have the source code

from the application program organized by the IT service provider; and
4) provision of guarantees from the IT service provider to the Bank that the continuity of the application is supported by software development officials in the event that the source code is not owned by the IT service provider.
d. In order to guarantee the function and effectiveness of the Disaster Recovery Plan, the Bank must compile and conduct periodic, comprehensive testing of the Disaster Recovery Plan, covering significant matters based on the type, scope, and complexity of activities or operations conducted by the IT service provider. In addition, the IT service provider must conduct Disaster Recovery Plan testing on its own side for IT systems or facilities as well as transaction processing conducted without involving the Bank. The results of the Disaster Recovery Plan testing by the IT service provider are used by the Bank to update the Bank's Disaster Recovery Plan.

9.3.4. Other Risk Controls
Although both the Bank and the IT service provider use sophisticated systems, deviations are still possible, such as human error, weak procedure implementation, and employee theft. The Bank must ensure the existence of security controls to mitigate risks, covering the following:
a. the IT service provider must conduct background research on its employees; b. ensuring that the obligation of the IT service provider to implement security controls over all IT facilities used, data processed, and information generated is included in the agreement;
c. ensuring that the IT service provider understands and can meet the level of security required by the Bank for each type of data based on data confidentiality sensitivity; and

d. ensuring that the costs incurred for each security measure are commensurate with the required level of security and consistent with the risk tolerance level established by the Bank.

9.4. Internal Control and Internal Audit
9.4.1. Monitoring and Supervision of IT Service Providers
In the event that the Bank's IT operations are conducted by an IT service provider, the Bank must still have an IT work unit and a top official leading the IT work unit.
The Bank must have a monitoring program to ensure that the IT service provider has carried out work or provided services in accordance with the agreement. Resources to support this program may vary depending on the criticality and complexity of the systems, processes, and services performed by the IT service provider. The Bank must conduct reviews before and after the IT service provider's work to ensure that the Bank's risk management policies, standards, and procedures have been implemented effectively. Furthermore, performance reviews and SLA achievement are conducted periodically and documented in the form of reports. Monitoring must be conducted against the IT service provider's examination results reports.

9.4.2. Internal Audit
The Bank carries out audit functions against the IT service provider periodically, either conducted by the Bank's internal audit or an external audit party appointed by the Bank. The scope of the audit corresponds to the scope of services as stated in the agreement. Areas audited include:
a. IT systems; b. data security;
c. internal control framework; and
d. Disaster Recovery Plan.
The Bank must ensure that the Financial Services Authority or other parties assigned by the Financial Services Authority have the right of access to the IT service provider to obtain records and transaction documents, as well as Bank information stored or processed by the IT service provider, and the right of access to reports and audit findings regarding the IT service provider related to IT services.

CHAPTER X PROVISION OF INFORMATION TECHNOLOGY SERVICES BY BANKS
10.1. Introduction
In conducting IT operations, the Bank requires adequate IT infrastructure. The provision of such infrastructure can be done by the Bank itself, or by an IT service provider. In the event that the Bank provides IT infrastructure independently, there is a possibility that the infrastructure is not fully utilized (idle), thus becoming inefficient. Therefore, in order to improve efficiency, the Bank can act as an IT service provider. The Bank can provide IT services to Financial Service Institutions (FSIs) under the supervision of the Financial Services Authority and/or other financial service institutions outside the territory of Indonesia. IT services that can be provided by the Bank are limited to the provision of Data Centers and/or Disaster Recovery Centers, including communication networks. However, in order to support financial inclusion and/or improve the efficiency of business conglomerates, the Bank can provide IT services in the form of application provision to other Banks with the approval of the Financial Services Authority.

10.2. Policies, Standards, and Procedures for IT Service Provision
In providing IT services, the Bank must meet the provisions as regulated in Article 25 of the POJK MRTI, and must have policies, standards, and procedures for IT service provision.

10.2.1. Bank's IT Service Provision Policy
The Bank must have a policy regarding IT service provision by the Bank, which at least regulates:
a. Principles of IT service provision

meeting the requirements for providing Information Technology services does not become one of the Bank's main activities;
meeting the principle of prudence;
considering cost and benefit analysis;
meeting statutory regulations; and
meeting the principle of arm's length cooperation.

In addition to meeting the above IT service provision principles, the Bank must also ensure that IT service provision by the Bank does not disrupt the Bank's operations. b. Management policy statement The decision to provide IT services must essentially consider efficiency and risk factors. Therefore, IT service provision must meet the principles of IT service provision as stated in letter a and must:

obtain management approval;
have an IT service provision agreement that allows for termination clauses in accordance with the agreement term or before the agreement expires;
establish the roles and responsibilities of parties related to IT service provision; and
evaluate prospective service recipients based on, among others, financial condition and reputation.

10.2.2. Bank's IT Service Provision Standards
Bank IT service provision standards must at least cover:
a. standards for work agreement content with the IT service recipient; b. term of the IT service provision agreement;
c. rights and obligations of the Bank and the IT service recipient;
d. guarantees of security and data confidentiality, especially customer data. Data can only be accessed by the data owner. Specifically, to maintain the confidentiality of Bank data as an application user, the Bank as an IT service provider must separate at least tables and/or Databases (Database) adjusted to the Bank's application architecture as an IT service provider; e. SLA service level guarantees, containing performance standards such as agreed service levels and performance targets; f. SLAs remain valid in the event of ownership changes for both the Bank and the IT service recipient; g. risk limits borne by the Bank and the IT service recipient, including:

risk of changes in the scope of the agreement;
changes in legal and regulatory aspects; and
legal aspects including copyright, patents, and logos or trademarks;
h. clear regulations regarding protection of Bank data (record protection) including supporting infrastructure such as hardware, equipment, and software, to ensure the continuity of IT operations;
i. ownership and copyright (license) in the event of IT service provision in the form of applications;
j. 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; k. sanctions and penalties for unclear reasons for agreement cancellation and violation of agreement content;
l. compliance with Indonesian statutory regulations; and
m. system security standards that must be met.

10.2.3. Bank's IT Service Provision Procedures
The Bank must have procedures for IT service provision by the Bank, namely procedures for defining the IT service recipient's needs.
The definition of the IT service recipient's business needs for IT service provision by the Bank must be conducted before the Bank decides to provide IT services, including:
a. risk assessment processes arising from IT service provision by the Bank; and b. establishment of the basis to be used to identify adequate risk control measurements.
The above need definition stage must produce a document containing a detailed description covering at least:

scope and characteristics of the services and technology used;
term, termination, and minimum content of the agreement;
and
agreement protection against obligations such as limitation of liability, indemnification, and insurance.

10.2.4. Preparation of IT Service Provision Agreements by the Bank
After the definition of the IT service recipient's business needs for IT service provision by the Bank, subsequently in drafting the agreement, the Bank must consider the following:
a. through a discussion process with the legal work unit; and b. considering the existence of special clauses for terminating the agreement before its expiration if the IT service recipient breaches the contract. Special clauses consider, among others, the following:

Inclusion of special clauses regarding the possibility of changing, creating a new agreement, or terminating the agreement before its expiration.
The Bank is able to measure the risk and efficiency of the IT service provision conducted so that the Bank can know early if there are conditions:
a) deterioration of the Bank's condition due to IT service provision, thereby having a significant impact on the Bank's business activities; b) deterioration of the IT service recipient's condition due to IT service provision, thereby having a significant impact on the Bank's business activities; c) the IT service recipient's solvency level is inadequate, in the process of moving towards liquidity, or declared bankrupt by the court; and/or d) violations of statutory regulations regarding customer personal data confidentiality.
In the event that the Bank finds matters as referred to in item 2), the Bank must do the following:
a) report to the Financial Services Authority no later than 3 (three) working days after the Bank becomes aware of the above conditions; b) decide on follow-up actions to be taken to address the problems, including stopping IT service provision if necessary; and c) report to the Financial Services Authority immediately after the Bank stops providing IT services before the end of the agreement term.

10.3. Risk Management Process
10.3.1. Risk Identification
Risk identification must at least consider the following. a. IT service provision by the Bank can contribute to several types of risks, as follows:

operational risk, namely the Bank's inability to provide IT services in accordance with the agreement;
legal risk, namely legal uncertainty over disputes with the IT service recipient;
reputational risk, namely the IT service recipient's dissatisfaction due to the Bank's inability to meet SLAs; and
compliance risk, namely the Bank's inability to meet statutory regulations.
b. In conducting risk identification, measurement, monitoring, and control, the Bank must consider:
IT service provision activities and functions, including data sensitivity accessed, protected, or controlled by the Bank;
IT service recipients, such as the financial condition and reputation of the IT service recipient; and
technology used, including reliability, security, availability, and timeliness, as well as the ability to follow technological developments and changes in statutory regulations.

10.3.2. Risk Measurement and Mitigation
After risks are identified, the Bank must measure these risks to determine the level of risk faced. The measurement of IT service provision risks must be integrated with the measurement of other IT-related risks using the same risk measurement approach. From the results of risk measurement, the Bank knows the level of risk faced. Subsequently, the Bank must establish risk mitigation strategies in accordance with the risk level. The risk mitigation actions taken by the Bank must be effective in controlling risks. Examples of risk mitigation in IT service provision:

The Bank must have adequate IT service provision agreements and monitor IT service provision periodically.
The Bank is able to reduce the impact of losses if identified risks occur.

Determined in Jakarta on June 6, 2017
EXECUTIVE HEAD OF BANKING SUPERVISOR
FINANCIAL SERVICES AUTHORITY, sd
NELSON TAMPUBOLON

APPENDIX II
CIRCULAR LETTER OF THE FINANCIAL SERVICES AUTHORITY NUMBER 21 /SEOJK.03/2017 REGARDING IMPLEMENTATION OF RISK MANAGEMENT IN THE USE OF INFORMATION TECHNOLOGY BY GENERAL BANKS

FORMAT FOR REPORTING THE IMPLEMENTATION OF RISK MANAGEMENT IN THE USE OF INFORMATION TECHNOLOGY BY GENERAL BANKS

TABLE OF CONTENTS
Appendix 2.1 CURRENT CONDITION REPORT ON INFORMATION TECHNOLOGY USAGE
Appendix 2.2 INFORMATION TECHNOLOGY DEVELOPMENT PLAN REPORT
Appendix 2.3 APPLICATION FOR APPROVAL
Appendix 2.4 INFORMATION TECHNOLOGY REALIZATION REPORT
Appendix 2.5 INCIDENT REPORT REGARDING CRITICAL EVENTS, MISUSE, AND/OR CRIMES IN THE CONDUCT OF INFORMATION TECHNOLOGY
Appendix 2.6 INFORMATION TECHNOLOGY AUDIT RESULTS REPORT

Appendix 2.1
CURRENT CONDITION REPORT ON
INFORMATION TECHNOLOGY USAGE
Bank Name: ..........................................
Bank Headquarters Address: ...................
Telephone Number: ..........................................
Person in Charge: .....................
Department/Division/Section of Person in Charge:
..............................................................
Address of Person in Charge: ...................
Telephone Number: ...........................................
Report Date: .......................................

LIST OF CURRENT CONDITION REPORTS ON
INFORMATION TECHNOLOGY USAGE
2.1.1 Bank Vision and Mission
2.1.2 Organization and Management
2.1.2.1 Bank Organizational Structure and Number of Bank Human Resources
2.1.2.2 Information Technology Organizational Structure and Number of IT Human Resources
2.1.2.3 Latest Information Technology Steering Committee (ITSC) Decision Letter
2.1.2.4 Minutes of ITSC Meetings for the Last 1 (One) Year
2.1.2.5 Information Technology Strategic Plan (ITSP) Document
2.1.3 Risk Management*)
2.1.3.1 Implementation of Risk Management
2.1.3.2 IT Internal Audit Organizational Structure
2.1.3.3 IT Audit for the Last 1 (One) Year
2.1.4 Information Technology Policies, Standards, and Procedures
2.1.5 Application Architecture
2.1.6 Application List
2.1.7 Reporting Process Flow
2.1.8 Delivery Channel
2.1.9 Communication Network
2.1.10 Data Center (DC) and Disaster Recovery Center (DRC)
2.1.11 Information Technology Security
2.1.12 Disaster Recovery Plan (DRP)
2.1.13 Information Technology Service Providers
2.1.14 Information Technology Costs
*) Risk Management is operational risk management related to information technology that can disrupt the smooth operation of the Bank.

Appendix 2.1.1
BANK VISION AND MISSION
Bank Vision
Bank Mission
IT policy directions implemented over the last 1 (one) year to support the Bank's vision and mission:

Appendix 2.1.2
ORGANIZATION AND MANAGEMENT
No.
Appendix Description Remarks
2.1.2.1 Bank Organizational Structure (attached)
Number of Bank HR (fill in number)
2.1.2.2 IT Organizational Structure (attached)
Number of IT HR
(fill in number)
2.1.2.3 Latest IT Steering Committee (ITSC) Decision Letter (attached)
2.1.2.4 ITSC Meeting Minutes for the Last 1 (One) Year (attached)
2.1.2.5 IT Strategic Plan (ITSP) Document (attached)

Appendix 2.1.3
RISK MANAGEMENT
No.
Appendix Description Remarks
2.1.3.1 Implementation of Risk Management (attached)
2.1.3.2 IT Audit Organizational Structure (attached)
2.1.3.3 IT Audit for the Last 1 (One) Year (attached)

Appendix 2.1.3.1
IMPLEMENTATION OF RISK MANAGEMENT *)
Adequacy of policies, standards, and procedures for IT usage
........
(Brief explanation regarding IT usage policies, standards, and procedures) Adequacy of the identification, measurement, monitoring, and control processes for IT usage risk
........
(Brief explanation regarding the identification, measurement, monitoring, and control processes 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)
*) Risk Management is operational risk management related to Information Technology that can disrupt the smooth operation of the Bank.

Appendix 2.1.3.2
IT INTERNAL AUDIT ORGANIZATIONAL STRUCTURE
(Filled with an image of the IT Internal Audit Organizational Structure; State the number of HR in the IT Internal Audit Work Unit)

Appendix 2.1.3.3
INFORMATION TECHNOLOGY AUDIT FOR THE LAST 1 (ONE) YEAR Audit Period Type of Audit Scope of Audit (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 scope of audit (example: Core banking system loan module)

Appendix 2.1.4
INFORMATION TECHNOLOGY POLICIES, STANDARDS, AND PROCEDURES No. Document Number Document Title Description Category Type Last Revision (1) (2) (3) (4) (5) (6) (7) Remarks:
(1) Fill in with serial number
(2) Fill in with Bank version document number
(3)
Complete with document title
(4) Fill in brief description regarding the document (5) Fill in with one of the categories:
301: Management 306: Disaster Recovery Plan
302: Development and Procurement 307: Electronic Banking Services 303: IT Operations 308: Use of IT Service Providers 304: Communication Network 309: IT Service Provision by Bank 305: Information Security (6) Fill in with one of the types:
K = Policy
S = Standard
P = Procedure
(7) Fill in the last revision date (DD-MM-YYYY)

Appendix 2.1.5
APPLICATION ARCHITECTURE
Application Architecture
(Filled with an image of the Application Architecture)

Appendix 2.1.6
APPLICATION LIST
No.
Category
Application
Application Name
Functional Description
Application Platform Database
Backup Location
Real Time
System
Owner
Application Developer
(Inhouse/Third-Party
IT Service Provider)
Implementation Date
(Go Live)
Ownership
(Rent or Buy Out)
Data Center
DC Organizer
DRC Organizer
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) 1 Example: 03 LOS Process loan applications "aaa" "bbb" Jakarta Self Jakarta Medan self Y xxxxx inhouse xx-xx-xxxx Rent 2 Example: 01 PN2 Core banking at Branch Office in WIT "aaa" "ccc" Sentul Self Sentul self Y xxxxx inhouse xx-xx-xxxx Buy Out Remarks:
(1) Fill in with serial number (3) Fill in with application name (15) Fill in "Rent" or "Buy Out" (2) Fill in with one of the categories:
(4) Fill in with brief description regarding the function application 01 : Customer Management (5) Fill in operating system platform 02 : Third-party funds (checking, savings, deposits) (6) Fill in the database engine used 03 : Lending/Financing (7) Fill in with city and country of Data Center location (Data Center/DC) 04 : General Ledger (GL) (8) Fill in with the name of the DC organizer company or "self" (Bank) 05 : Payments (9) Fill in city and country of Disaster Recovery Center location (Disaster Recovery Center/DRC) application 06 : Electronic Banking Services (10) Fill in DRC organizer company or "self" (Bank) 07 : Treasury (11) Fill in: - "Y" If backup is done in real time 08 : Trade Finance (Trade finance)

"T" If backup is not done
in real time

09 : Anti-Money Laundering and
Prevention of Terrorist Financing (AML and CFT) (12) Fill in the business unit managing the application 10 : Reporting information system management (13) Fill in: - "Inhouse", if the application is developed by the Bank 11 : Risk management - Name of Third-Party IT Service Provider (PPJ TI), if the application is developed by PPJ TI 12 : Internal management (14) Fill in with the application implementation date (DD-MM-YYYY)

Appendix 2.1.7
REPORTING PROCESS FLOW
No.
Type
Report
Application
Data Source
Data Processing
Application
Data Processor
Used
Processing Unit
Responsible Unit
(1) (2) (3) (4) (5) (6) (7)
Remarks:
(1) Fill in with serial number
(2) Fill in the name of the report that is the target (example: General Bank Monthly Report/LBU Form 01, Monetary Stability and Financial System Report/LSMK, Financial Information Services System/SLIK) (3) Fill in the name of the application from the report data source (example: Core banking system CASA module) (4) Fill in: - "Manual", if data processing into reports is done manually

"Automatic", if data processing into reports is done
using an application
(5) Fill in the name of the application used if data processing in column (4) is done automatically (6) Fill in the business unit performing data processing (7) Fill in the unit responsible for the report

Appendix 2.1.8
DELIVERY CHANNEL
Delivery Channel Description Quantity
Branch Number of Branch Offices
Number of Sub-Branch Offices
Number of Cash Offices
Number of Financial Service Agents
Without Office In the Context of
Financial Inclusion (Laku Pandai)
ATM Number of Cash ATMs:

Cash Withdrawal
Cash Deposit
Cash Withdrawal and Deposit
Number of Non-Cash ATMs
EDC Number of EDC Machines
Transaction Frequency
Debit Transaction Nominal per Year
Phone Banking Number of Users
Transaction Frequency
Debit Transaction Nominal per Year
Internet Banking Number of Users
Transaction Frequency
Debit Transaction Nominal per Year
Mobile Banking Number of Users
Transaction Frequency
Debit Transaction Nominal per Year
Others*) (Specify) Number of Users
Transaction Frequency
Debit Transaction Nominal per Year
*) Examples:

SMS Banking
Electronic money
E-wallet

Appendix 2.1.9
COMMUNICATION NETWORK
COMMUNICATION NETWORK TOPOLOGY
(Filled with an image of the Communication Network Topology)

Appendix 2.1.10

DATA CENTER (DC) / DISASTER RECOVERY CENTER (DRC)

DC/DRC 1

Description	Details
Function	(DC or DRC)
Provider
Address
DC/DRC Area Size
DC/DRC Certification	(Assessment results according to certification if available/equivalent based on internal assessment)
Physical Controls	(Brief explanation regarding physical controls at the DC/DRC)
Environmental Controls	- Uninterruptible Power Supply (UPS)<br>- Raised floor<br>- Air temperature and humidity control (AC, thermometer, and hygrometer)<br>- Smoke/fire/heat/water leak detectors<br>- Fire suppression system<br>- CCTV cameras<br>- And others<br><br>(Brief explanation regarding environmental controls at the DC/DRC)

DC/DRC 2, 3, …

Description	Details
Function	(DC or DRC)
Provider
Address
DC/DRC Area Size
DC/DRC Certification	(Assessment results according to certification if available/equivalent based on internal assessment)
Physical Controls	(Brief explanation regarding physical controls at the DC/DRC)
Environmental Controls	- Uninterruptible Power Supply (UPS)<br>- Raised floor<br>- Air temperature and humidity control (AC, thermometer, and hygrometer)<br>- Smoke/fire/heat/water leak detectors<br>- Fire suppression system<br>- CCTV cameras<br>- And others<br><br>(Brief explanation regarding environmental controls at the DC/DRC)

Appendix 2.1.11

INFORMATION TECHNOLOGY SECURITY

No.	Asset Name	Asset Type	Description
(1)	(2)	(3)	(4)

Notes:
(1) Filled with sequential number
(2) Filled with asset name for IT security (e.g., antivirus “XYZ” and firewall “ABC”) (3) Filled with asset type (software or hardware) (4) Filled with brief description regarding the asset (such as asset function, license quantity, asset version, and others)

Appendix 2.1.12

DISASTER RECOVERY PLAN (DRP)

General DRP Information

Type (Filled with general information regarding the type)
Backup Media Location (Filled with backup media location)
Last DRP Testing Date (Filled with DRP testing time)

DRP Team Structure
(Filled with DRP Team Structure image)

DRP Testing – 1

Testing Time (Filled with DRP testing time)
List of Bank Applications and/or Infrastructure (Filled with list of applications and/or infrastructure tested in the last 1 (one) year)
DRP Testing Results (Filled with brief explanation regarding DRP testing results)

DRP Testing – 2, 3, …

Testing Time (Filled with DRP testing time)
List of Bank Applications and/or Infrastructure (Filled with list of applications and/or infrastructure tested in the last 1 (one) year)
DRP Testing Results (Filled with brief explanation regarding DRP testing results)

DRP Review Implementation - 1

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

DRP Review Implementation – 2, 3, ...

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

Appendix 2.1.13

INFORMATION TECHNOLOGY SERVICE PROVIDERS

13.1 Management of IT Service Provider Usage

No.	Name of Service Provider	Address of IT Service Provider	Related Party	Services Provided
(1)	(2)	(3)	(4)	(5)

Notes:
(1) Filled with sequential number
(2) Filled with IT SP name
(3) Filled with IT SP address
(4) Filled: - “Y”, if IT SP is a related party to the Bank

“T”, if IT SP is not a related party to the Bank
(5) Filled with list of services provided by IT SP to the Bank, which may include application support or infrastructure (Example: maintenance of core banking system server and supporting application “ABC”)

13.2 Bank as IT Service Provider

No.	Service User Name	Address of IT Service User	Related Party	Services Provided
(1)	(2)	(3)	(4)	(5)

Notes:
(1) Filled with sequential number
(2) Filled with IT Service User name
(3) Filled with IT Service User address
(4) Filled: - “Y” If User is a related party to the Bank

“T” If User is not a related party to the Bank
(5) Filled: - Data Center Management
Disaster Recovery Center Management
Application service provision
Others (as regulated in the OJK regarding the implementation of risk management in the use of information technology by commercial banks)

Appendix 2.1.14

INFORMATION TECHNOLOGY COSTS

Cost Type	To Related Parties *)	To Unrelated Parties *)
1. Charged to Profit/Loss
a. Capitalizable capital expenditure (Capex)
b. Operational expenditure (Opex)
2. Charged to Balance Sheet

Notes:
(1.a) Filled with Capex depreciation charged to profit/loss (1.b) Filled with Opex charged to profit/loss (2) Filled with current year Capex additions to the balance sheet *) Costs in Rupiah currency unit or other currency unit accompanied by equivalent value in Rupiah

Appendix 2.2

REPORT ON IT DEVELOPMENT PLAN

No.	Bank Application/Infrastructure Name	Description	Category	Development Type	Developer	IT Service Provider	Related Party	Location	Planned Implementation Time	Estimated Cost


(1)	(2)	(3)	(4)	(5)	(6)	(7)	(8)	(9)	(10)	(11)
		DC	DRC	Capex	Opex

Notes:
(1) Filled with sequential number
(2) Filled with name of application/infrastructure to be developed, example: "Application X", "Data Center Relocation", "Network bandwidth capacity addition" (3) Detailed explanation of application/infrastructure to be developed (4) Development category, choose one:
01: Customer Management
02: Third-Party Funds (Current Accounts, Savings, Deposits) 03: Lending/Financing 04: General Ledger (GL) 05: Payments 06: Electronic Banking Services 07: Treasury 08: Trade Finance 09: AML and CFT 10: Reporting Information System Management 11: Risk Management 12: Internal Management 49: Other Applications 51: DC/DRC 52: Server and/or Platform 53: Data Communication Network 54: Security System 99: Other Infrastructure

(5) Filled "new" if new application/infrastructure or replacing old application/infrastructure, filled "upgrade" for addition/development of existing application/infrastructure (6) Filled "inhouse" if developed internally by the Bank or filled “IT SP” if developed by external party to the Bank (7) Filled "yes" if IT SP is a related party to the Bank, "no" if IT SP is not a related party, "-" if development is done inhouse or IT SP has not been determined (8) Filled with city and country name of DC and DRC location (9) Filled using quarterly period i.e. Q1/Q2/Q3/Q4 (10) Filled with estimated Capex and/or Opex for 1 (one) year since implementation (excluding Capex depreciation). Costs in Rupiah currency unit or other currency unit accompanied by equivalent value in Rupiah (11) Filled:

IT development impacts, e.g., need for additional human resources
Explanation of IT development linkage with IT plan in the Bank's Business Plan

Note: This IT Development Plan Report does not eliminate the Bank's obligation to submit reports and requests for approval as regulated in Article 24 and Article 32 of the OJK MRTI.

Appendix 2.3

REQUEST FOR APPROVAL

Bank Name: ......................................
Bank Headquarters Address: ...............
Telephone Number: .................................
Reporter Name: ..................................
Reporter Office/Division/Section: ..........
Reporter Address: ................................
Telephone Number: .................................
Report Date: ..............................

Appendix 2.3.1

REQUEST FOR APPROVAL

PLAN FOR PROVIDING INFORMATION TECHNOLOGY SERVICES BY THE BANK

Type of IT service to be provided by the Bank.
a. Data Center Management. b. Disaster Recovery Center.
c. Application service provision.
IT service recipient.
a. Name :
b. Address :
c. Brief business description :
d. Relationship with Bank :
General information regarding IT services to be provided by the Bank.
a. Management Location :
Data Center :
Disaster Recovery Center :
b. List of application services provided by the Bank.

No.	Application Service Type	Application Service Name
1	Example: Laku Pandai	Application “ABC”
2	Example: Electronic Banking Service	Mobile Banking
3	Example: Electronic Banking Service	ATM
...	...	...
...	...	...

If the Bank provides IT service in the form of Data Center and/or Disaster Recovery Center, attach an analysis of the adequacy of the Bank's Data Center and/or Disaster Recovery Center capacity (e.g., rooms and network) for the Bank's business needs in the future, taking into account the capacity of the Data Center and/or Disaster Recovery Center provided by the Bank to other parties.
Attach a cost-benefit analysis of providing IT services that can demonstrate benefits to the Bank exceeding the costs of providing IT services.
Attach a risk analysis regarding the provision of IT services that at least covers operational, reputational, legal, compliance, and strategic aspects, as well as mitigations that the Bank must undertake to ensure the fulfillment of confidentiality, integrity, availability, and authenticity regarding the provision of IT services.
Attach the draft agreement between the Bank and IT service users as required in the OJK MRTI.

Appendix 2.3.2

REQUEST FOR APPROVAL

PLAN FOR ISSUING ELECTRONIC BANKING SERVICES *)

Systems, procedures, and authorities in the issuance of Electronic Banking Services.
Brief description or explanation regarding the Electronic Banking Services to be issued.
IT infrastructure readiness to support each Electronic Banking Service product.
Attach explanation regarding the IT architecture system of the Electronic Banking Services to be issued and the connection form with the core banking system.
Results of risk analysis and identification inherent in Electronic Banking Services and forms of security controls for risk mitigation, including to ensure the fulfillment of the principles of confidentiality, integrity, availability, and non-repudiation.
Explanation of rules applied by the Bank regarding:
a. two-factor authentication to be used; b. encryption to be used; and
c. passwords (numeric alphanumeric criteria, password length).
Description of the accounting information system to be applied to the Electronic Banking Services to be issued.
Attach results of risk analysis and identification of Electronic Banking Services in the form of identification, measurement, monitoring, and risk mitigation of the newly issued Electronic Banking Services, including operational, legal, and reputational risks.
Attach results of independent party examinations that provide opinions on product characteristics and adequacy of IT system security related to Electronic Banking Services as well as compliance with applicable laws and regulations, established standards, and/or generally accepted practices (best practices).
Description of supporting organizational structure readiness and built-in controls to be applied to the Electronic Banking Services to be issued.
Business analysis results regarding projections for new product issuance in the next 1 (one) year.

*) The request for approval of the plan to issue Electronic Banking Service products is submitted to the OJK at the latest 2 (two) months before implementation as required in the OJK MRTI.

Appendix 2.3.3

REQUEST FOR APPROVAL

PLAN FOR MANAGING ELECTRONIC SYSTEMS LOCATED AT DATA CENTER AND/OR DISASTER RECOVERY CENTER BY SERVICE PROVIDERS OUTSIDE INDONESIA *)

Planned management location:
a. Data Center..............................................................................
b. Disaster Recovery Center ......................................................
c. Electronic System Function........................................................
Attach data on the name, address, and ownership of the planned Data Center and/or Disaster Recovery Center provider.
Attach summary of needs definition and due diligence results conducted by the Bank in the plan to use IT SP to manage Data Center and/or Disaster Recovery Center outside Indonesia.
Regarding the due diligence summary in item 2, include the following as attachments to the summary:
a. Bank's analysis of IT audit results conducted by independent parties on the development of application systems offered and security systems at facilities owned by IT SP; b. Bank's risk analysis regarding the plan to hand over Data Center and/or Disaster Recovery Center management to IT SP, including operational, legal, and reputational risks, as well as country risk analysis; and
c. Bank's analysis regarding the adequacy of IT SP's Disaster Recovery Center.
Attach the draft agreement between the Bank and the Data Center and/or Disaster Recovery Center provider abroad containing matters as required in the OJK MRTI.
Attach summary of IT SP's risk analysis regarding the management of Data Center and/or Disaster Recovery Center to be offered to the Bank.
Attach summary of cost-benefit analysis of IT management by IT SP which among others covers:
a. benefits to the Bank exceeding costs charged by IT SP to the Bank; b. assessment of adequacy and suitability of application systems to be used with Bank's needs;
c. analysis of security controls used by IT SP to ensure the fulfillment of confidentiality, integrity, availability, and authenticity; and
d. analysis of performance, reputation, and continuity of service provision to IT service users.
Attach images of current IT architecture and planned architecture after Data Center and/or Disaster Recovery Center management is handed over to IT SP.
Attach the supervision plan to be conducted by the Bank over the management of Data Center and/or Disaster Recovery Center planned.
Attach a statement letter from the Bank regarding the Bank's willingness to provide access to internal auditors, external auditors, and the Financial Services Authority to obtain data and information accurately and timely whenever needed.
In the event the Bank is a branch office of a bank domiciled outside Indonesia or a Bank owned by a foreign financial institution, attach:
a. Statement letter from the financial institution supervisory authority abroad that IT SP is under its supervision; b. Statement letter of no objection from the local supervisory authority if the Financial Services Authority intends to examine the management of the Data Center and/or Disaster Recovery Center;
c. Statement letter that the Bank will periodically submit the results of assessments conducted by the Bank's office abroad or the parent Bank office regarding the implementation of risk management on IT SP. This statement letter must state the planned periodicity; and
d. Assessment results by the Bank's office abroad or parent Bank office regarding the implementation of risk management conducted by IT SP.
Attach the Bank's plan regarding:
a. improvement of service quality to customers; and b. improvement of human resources capabilities related to IT management used by the Bank.

*) The request for approval of the plan to manage Electronic Systems at Data Center and/or Disaster Recovery Center outside Indonesia is submitted to the Financial Services Authority at the latest 3 (three) months before the IT SP's management activities are effectively operated as required in the OJK MRTI.

Appendix 2.3.4

REQUEST FOR APPROVAL

PLAN FOR MANAGING INFORMATION TECHNOLOGY-BASED TRANSACTION PROCESSING BY INFORMATION TECHNOLOGY SERVICE PROVIDERS OUTSIDE INDONESIA *)

Description or explanation and flow chart of Standard Operating Procedures (SOP) of products and activities whose management will be handed over to IT SP.
Management location:
a. Data Center..............................................................................
b. Disaster Recovery Center ......................................................
c. Information Technology-Based Transaction Processing...............
Attach data on the name, address, and ownership of the planned Information Technology-Based Transaction Processing provider.
Attach summary of needs definition and due diligence results conducted by the Bank in the plan to use IT SP to manage Information Technology-Based Transaction Processing outside Indonesia.
Due diligence summary in item 3, accompanied by attachment summary regarding:
a. Bank's analysis of IT audit results conducted by independent parties on IT resources (including development of offered application systems, operating systems and procedures, and security systems at facilities owned) to be used for transaction processing by IT SP; b. Bank's risk analysis regarding the plan to hand over Information Technology-Based Transaction Processing management to IT SP, including operational, legal, and reputational risks, as well as country risk analysis; and
c. Bank's analysis regarding the adequacy of IT SP's Disaster Recovery Plan.
Attach the draft agreement between the Bank and the Information Technology-Based Transaction Processing provider outside Indonesia containing matters as required in the OJK MRTI.
Attach summary of IT SP's risk analysis regarding the management of Information Technology-Based Transaction Processing to be offered to the Bank.
Attach summary of cost-benefit analysis of Information Technology-Based Transaction Processing management by other parties which among others covers:
a. benefits to the Bank compared to costs charged by IT SP to the Bank; b. assessment of adequacy and suitability of application systems to be used with Bank's needs;
c. Bank's analysis of security controls used by service providers to ensure the fulfillment of confidentiality, integrity, availability, and authenticity; and
d. analysis of performance, reputation, and continuity of service provision to IT service users.
Attach images of current and planned reporting and information process flows after transaction processing is handed over to IT SP.
If the Bank is a branch office of a bank domiciled outside Indonesia or a Bank owned by a foreign financial institution, it is necessary to attach:
a. Statement letter from the financial institution supervisory authority abroad that IT SP is under its supervision; b. Statement letter of no objection from the local supervisory authority if the Financial Services Authority intends to examine the management of Information Technology-Based Transaction Processing;
c. Statement Letter that the Bank will periodically submit the results of assessments conducted by the Bank's office abroad or parent Bank office regarding the implementation of risk management on IT SP. This statement letter must state the planned periodicity.
d. Assessment results by the Bank's office abroad or parent Bank office regarding the implementation of risk management conducted by IT SP.
Attach the supervision plan to be conducted by the Bank over the management of Information Technology-Based Transaction Processing planned.
Attach the Bank's plan regarding:
a. improvement of human resources capabilities related to IT management used by the Bank; b. improvement of human resources capabilities regarding products offered by the Bank to customers;
c. application of customer protection aspects regarding products whose processing is handed over to IT SP; and
d. enhancement of the Bank's role in the development of the Indonesian economy through business plans.
Attach a statement letter from the Bank regarding the Bank's willingness to provide access to internal auditors, external auditors, and the Financial Services Authority to obtain data and information accurately and timely whenever needed.

*) The request for approval of the plan to manage Information Technology-Based Transaction Processing by IT SP outside Indonesia is submitted at the latest 3 (three) months before the IT SP's management activities are effectively operated as required in the OJK MRTI.

Appendix 2.4

INFORMATION TECHNOLOGY REALIZATION REPORT*)

Bank Name: ......................................
Bank Headquarters Address: ...............
Telephone Number: .................................
Reporter Name: ...................................
Reporter Office/Division/Section: ...........
Reporter Address: .................................
Telephone Number: .................................
Report Date: ...............................

Appendix 2.4.1

REALIZATION OF ACTIVITIES AS

INFORMATION TECHNOLOGY SERVICE PROVIDER*)

Type of IT services provided by the Bank.
IT service users.
a. Name :
b. Address :
c. Brief business description :
d. Relationship with Bank :
General information regarding IT services provided by the Bank.
a. Management Location :
Data Center :
Disaster Recovery Center :
a. Data Center Management

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 Service Provision

Realization Date (dd/mm/yyyy)	Agreement Document (document number and date)	Cooperation Period (dd/mm/yyyy to dd/mm/yyyy)

b. List of application service offerings provided by the Bank No. Type of Application Service Application Name Description Application Service 1 Example: Laku Pandai Application "ABC" 2 Example:
Electronic Banking Services
Mobile Banking
3 Example:
Electronic Banking Services
ATM
... ... ...
... ... ...
4. Attachment of the agreement between the Bank and financial service institutions that have realized the use of IT service offerings.
5. Attachment of the minutes of the provision of IT service offerings provided by the Bank that have been used by financial service institutions.
6. Attachment of the post-implementation review (PIR) results regarding the provision of IT service offerings provided by the Bank, which among others includes:
a. results of system performance review; b. compliance with user requirements;
c. problems that occurred and solutions, escalations, or resolution steps taken; and
d. effectiveness of established security measures.
*) The realization report of activities as an IT service provider is submitted to the Financial Services Authority (OJK) no later than 3 (three) months after implementation as required by POJK MRTI.

Appendix 2.4.2
REALIZATION OF ISSUANCE OF ELECTRONIC BANKING SERVICES *)

Date of realization ... (filled with dd/mm/yyyy format).
Brief description or explanation regarding the newly issued Electronic Banking Services.
Attachment of explanation regarding the IT architecture system of the newly issued Electronic Banking Services and the form of connection with the core banking system.
Attachment of explanation regarding the form of internal controls, specifically security controls that ensure the fulfillment of confidentiality, integrity, and availability aspects.
Description of the readiness of the supporting organizational structure and built-in controls over Electronic Banking Services.
Attachment of policies and procedures explaining the readiness of the IT infrastructure for Electronic Banking Services.
Attachment of post-implementation review results regarding the use of IT related to the issued Electronic Banking Services, which is not limited to reviews regarding:
a. system performance; b. customer complaints and follow-up actions;
c. compliance with user requirements;
d. problems that occurred along with solutions, escalations, or resolution steps taken; and e. effectiveness of established security measures.
*) The realization report of the issuance of Electronic Banking Service products is submitted to the Financial Services Authority (OJK) no later than 3 (three) months after implementation as required by POJK MRTI.

Appendix 2.4.3
REALIZATION OF THE PLAN FOR OPERATING ELECTRONIC SYSTEMS LOCATED AT DATA CENTERS AND/OR DISASTER RECOVERY CENTERS OUTSIDE INDONESIAN TERRITORY *)

Date of realization ... (filled with dd/mm/yyyy format).
Location of operation:
a. Data Center..............................................................................
b. Disaster Recovery Center ......................................................
c. Function of Electronic System........................................................
Attachment of photocopy of the agreement between the Bank and the Data Center and/or Disaster Recovery Center operator.
Attachment of the latest analysis results of security controls used to ensure the fulfillment of confidentiality, integrity, and availability in operations entrusted to the IT service provider.
Attachment of post-implementation results regarding the use of the IT service provider's Data Center, which among others includes review results regarding:
a. system performance; b. compliance with user requirements;
c. problems that occurred along with solutions, escalations, or resolution steps taken; and
d. effectiveness of established security measures.
Attachment of test results regarding the use of the Disaster Recovery Center operated by the IT service provider.
Attachment of minutes of the transfer of the Data Center and/or Disaster Recovery Center.
Attachment of the latest IT architecture diagram after the Data Center and/or Disaster Recovery Center operations are handed over to the IT service provider.
Description of the Bank's latest risk analysis regarding the operation of the Data Center and/or Disaster Recovery Center by the IT service provider outside Indonesian territory, including operational, legal, and reputational risks, as well as country risk analysis.
*) The realization report of the operation of Electronic Systems located at Data Centers and/or Disaster Recovery Centers outside Indonesian territory is submitted to the Financial Services Authority (OJK) no later than 3 (three) months after implementation as required by POJK MRTI.

Appendix 2.4.4
REALIZATION OF THE PLAN FOR OPERATING INFORMATION TECHNOLOGY-BASED TRANSACTION PROCESSING TO SERVICE PROVIDERS OUTSIDE INDONESIAN TERRITORY *)

Description or explanation and flowchart of the Standard Operating Procedure (SOP) for Bank products and activities whose operation is entrusted to the IT service provider.
Date of realization ... (filled with dd/mm/yyyy format)
Location of operation:
a. Data Center ..............................................................................
b. Disaster Recovery Center.......................................................
c. Information Technology-Based Transaction Processing ...............
Attach photocopy of the agreement between the Bank and the service provider for operating Information Technology-Based Transaction Processing outside Indonesian territory.
Attach test results regarding the use of the operation of Information Technology-Based Transaction Processing outside Indonesian territory.
Attach minutes of the transfer of the operation of Information Technology-Based Transaction Processing outside Indonesian territory.
Attach post-implementation results regarding the use of the IT service provider in operating Information Technology-Based Transaction Processing outside Indonesian territory, which among others includes review results regarding:
a. system performance; b. compliance with user requirements;
c. problems that occurred along with solutions, escalations, or resolution steps taken; and
d. effectiveness of established security measures.
Attach the current process and information reporting flow diagram after the operation is handed over to the IT service provider.
Attach the analysis results of security controls used to ensure the fulfillment of confidentiality, integrity, and availability in the operation of Information Technology-Based Transaction Processing entrusted to the IT service provider outside Indonesian territory.
Attach a letter of statement from the IT service provider as an affiliated party stating willingness to be examined by the Financial Services Authority regarding the operation of Information Technology-Based Transaction Processing.
*) The realization report of Information Technology-Based Transaction Processing by the IT service provider outside Indonesian territory is submitted to the Financial Services Authority (OJK) no later than 3 (three) months after implementation as required by POJK MRTI.

Appendix 2.5
INCIDENTAL REPORT REGARDING CRITICAL EVENTS,
MISUSE, AND/OR CRIMES IN THE OPERATION OF INFORMATION TECHNOLOGY *)
Bank Name: ....................................
Bank Headquarters Address: .............
Telephone Number: ...............................
Reporter Name: .................................
Reporter Office/Division/Department: .........
Reporter Address: ...............................
Reporter Telephone Number: ...............................
Report Date: .............................

Date of incident ... (dd/mm/yyyy).
Attach chronology and evaluation of the cause of the incident.
There is an element of intent.
Yes No
Related work units including persons who can be contacted further ...
Impact or consequences caused.
a. Financial losses b. Operational disruptions
c. Lack of confidentiality and data integrity
Attach the Bank's follow-up plan.
*) A critical event is an event that significantly increases risk exposure. Misuse or crimes in IT operations are actions that result in financial losses and/or disrupt the smooth operation of the Bank.

Appendix 2.6
IT AUDIT RESULTS REPORT *)
Bank Name:....................................
Bank Headquarters Address: ............
Telephone Number: ..............................
Reporter Name: ...............................
Reporter Office/Division/Department: .......
Reporter Address: .............................
Reporter Telephone Number: ..............................
Report Date: ...........................

Attach 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 resolution, and target completion time.
*) Special IT audits are conducted on IT-related aspects according to needs, priorities, and the Bank's IT risk analysis results.
) Information includes the type of service, service provider data (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 service operation, and other important information.

GLOSSARY

Acquirer: A Bank or institution other than a Bank that conducts payment card activities, which can be a financial acquirer and/or a technical acquirer.
Access: An effort to open a communication channel with specific hardware or software, such as a modem used to open internet access. The hardware or software is used not only to provide data but also to receive data for storage.
Accountability: A mechanism to assess responsibility for decision-making and actions.
Log Administrator: A file on a computer that stores information regarding administrator activities.
Automated Teller Machine (ATM): A terminal or computer machine used by a Bank that is connected to other computers via data communication, allowing Bank customers to deposit and withdraw money at the Bank or conduct other banking transactions.
Audit Trail: A file on a computer that stores information regarding user or computer activities, stored chronologically, which can be used for auditing or tracing.
Authentication: The ability of each party in a transaction to verify the authenticity of the other party.
Back Door: A method to bypass normal authentication or secure remote access of a computer to access a system but is not identified through normal checks.
Backup: A copy of the original document or a backup of the main machine that can be used if the main machine experiences a disturbance. Backup can be data backup or system backup. Backup can be placed on-site at the Data Center location and/or off-site at an alternative location.
Backup Site: A storage location for computer backups and files that is separate from the Data Center.
Business Impact Analysis (BIA): A process to ensure the consequences resulting from the unavailability of all IT resources. At this phase, it includes identifying various events that can cause disruptions to IT operational continuity.
Contingency Plan: Procedures containing plans or manual steps that must be taken by business units to conduct operational business activities during the recovery process.
Controller (Host-Front End): A type of mini-computer that functions to control the performance of hardware and software in a system such as computer terminals or ATMs, communication networks, or other computer facilities.
Cost and Benefit Analysis: A comparative analysis between investment costs and the benefits obtained by the Bank from each alternative service provider choice. The results of this analysis become one of the Bank's considerations for making outsourcing decisions or selecting IT service providers.
Cybersquatting: Registration or use of website addresses or domain names with malicious intent, namely to misuse or gain profit from the use of a trademark by unauthorized parties.
Defacing: An attempt by hackers to attack and change the appearance or content of a website.
Denial of Service Attack: An attack on an IT system causing it to become slow or completely non-functional, for example, by making network bandwidth capacity or computer disk space appear fully used, server disturbances, and disruptions in service provision to other systems or users.
Digital Certificate: An electronic identity used to identify and verify that a message was sent by an authorized person or company and is only read by authorized parties. Digital certificates are issued by a third party called a "certification authority".
Digital Signature: Information in the form of specific digital signs that can ensure sender authentication, data integrity, and non-repudiation.
Disposal Media Backup: The process of destroying backup media that have passed their retention period and are no longer used.
Down Time: The duration during which a system cannot function and be used by users due to hardware, software, and communication disturbances.
Due Diligence: A process to obtain the most complete information regarding IT service providers to assess reputation, operational and managerial capabilities, financial conditions, future development strategies, and the ability to keep up with the latest technological developments.
Electronic Fund Transfer (EFT): Transfer of funds between accounts through a payment system using electronic media. EFT can be conducted in financial transactions including via telephone and computer terminals.
Encryption: A tool to achieve data security by translating it using a password. Encryption prevents passwords or keys from being easily read in configuration files.
Escrow Agreement: An agreement that allows the granting of rights to software purchasers to have the latest source code version in the event that the system application manufacturing company ceases operations, for example, due to bankruptcy.
Exception Handling: A mechanism to handle unexpected conditions that can change the normal flow of an application system.
Firewall: Equipment to maintain network security that monitors and selects data or information traffic through the network and separates private and public networks. This equipment can be used to protect computers connected to the network from attacks that can damage internal computers and cause data corruption and/or denial of service for authorized users.
Full System Backup: System backup that covers the entire system used.
Gateway: A point in a network that functions as an entry point to another network or connects one network with another. A gateway can be a computer that manages and controls network traffic.
Hardcopy: A copy of computer data or information in printed form, also known as a printout.
Hardening: Parameter configuration. It is a process or method to secure a system from various threats or disturbances. Methods used include, among others, disabling unnecessary services, as well as unnecessary usernames or logins, developing intrusion detection systems, intrusion prevention systems, and firewalls.
Hub: Equipment that connects several cables on a network and forwards data or information to all addresses that are network points or target equipment.
Interoperability:
a. The ability of software or hardware on various types of machines from many vendors to communicate with each other; b. The ability to exchange and use information (usually in a large network consisting of several varied local networks).
IT Control: IT controls that include general controls and application controls integrated to support business processes. General IT controls are necessary to enable the implementation of application controls. General Bank controls include controls in Bank IT management and organization, access controls both physical and logical, and DRP implementation. Application controls are necessary to ensure completeness and accuracy at every stage of information processing. Application controls are integrated with the application systems used for transaction processing.
Key logger: A threat in the form of software or hardware used to obtain information (PIN, password) typed by users on the keyboard.
Library: A collection of software or data that has a specific function, is stored, and is ready for use.
Logic Bomb: A code intentionally inserted into a software system that, under certain conditions, will perform a series of destructive functions.
Man-in-the-middle-attack: A type of attack on information technology systems where the attacker (hacker) intercepts messages sent by the sender to the receiver and/or subsequently changes the content of the message and sends it back to the receiver. The attacker (hacker) will use a program that appears like a server to the client and appears as a client to the server.
Network interface: An interconnection point between user terminals, machines, or a network with another network.
Non-repudiation: A way to ensure the truth of the sender and receiver so that no party can deny it.
Offline: A system or computer that does not have a network connection or cannot communicate with other systems or computers.
Off-the-shelf: Available as is, made not based on special orders.
Outsourcing: The use of third parties (external) in the Bank's IT operations, causing the Bank to have continuous dependence on the services provided by that third party and/or for a certain period.
Parallel Distributed: A distributed system consisting of a group of computers connected by a network, with shared software so that all computers can share hardware, software, and data resources. This system can bridge geographical differences, improve performance, interaction, and reduce costs.
Password: A special code or symbol to secure a computer system, namely to identify parties accessing data, programs, or computer applications used.
Patch: A set of codes added to software to fix an error, usually a temporary correction between two software version releases.
Patch Management: System management that includes the process of obtaining, testing, and installing various patches used to fix a program.
Physical Security: A security system to prevent unauthorized access to computerized areas and supporting equipment or facilities.
Logical Security: A security system to prevent unauthorized access to computer systems and information stored therein, which among others includes the use of user IDs and passwords.
Personal Identification Number (PIN): A unique sequence of digits consisting of letters, numbers, or ASCII codes used to identify, among others, computer users, ATM users, internet banking users, and mobile banking users.
Switching Company: A company that provides electronic banking services to Banks and financial service institutions, among others in the management of computer hardware, telecommunications networks, information, and records of Bank and financial service institution customer transactions.
Phishing: One form of social engineering technique to illegally obtain someone's confidential information. Phishing can be in the form of fake emails that appear to originate from a Bank or credit card company to obtain information such as PINs and passwords.
Platform: Hardware or software such as computer architecture, operating systems, or programming languages that allow an application to operate.
Point of Sales (POS) or Electronic Data Capture (EDC): A hardware device or computer terminal that can be a cash register or debit/credit verification terminal that reads information on a card's magnetic stripe regarding transaction data at the merchant location, transmits data to the acquirer for verification and processing.
Power User: A user ID with very broad authority.
Public Key Infrastructure (PKI): A processing or arrangement where a trusted third party provides careful examination and ensures the validity of an identity.
Request for Proposal (RFP): A process of requesting proposals from service providers according to the Bank's needs for selection purposes. The proposals submitted must be able to answer in detail the Bank's needs as defined in the business requirement document or target operating model.
Restore: returning to the original function or condition prior to the occurrence of a disaster.
Restricted area: an area that can only be entered by persons who have obtained access rights.
Router: network equipment that forwards a data packet or information by selecting the best route to be taken in delivering such data or information.
Service Level Agreement – Service Level Guarantee: a part of a contractual agreement where the level of expected service provision by the parties is established, usually also covering performance standards such as agreed service levels or service provision time targets.
Softcopy: a copy of data or documents in the form of an electronic file.
Source Code – Source Code: software program instructions written in a format (language) and readable by humans.
Spoofing: a state where a person or a program can impersonate another person or program by falsifying data with the aim of obtaining certain benefits.
Spyware: software that collects sensitive information about users without the user's knowledge or consent.
Stress Test: a type of testing in development that uses various scenarios, for example, in adverse conditions. Stress tests are required regarding performance and load balancing, particularly for complex applications.
Switch: equipment in a network that forwards information packets to the destination address or equipment.
System: a working network of interrelated procedures, gathered together to carry out an activity or to achieve a specific objective.
System Log: a file on a computer that stores information regarding system or computer activities.
Trojan Horse: a destructive program inserted by a hacker into a program already known to users; its replication or distribution must be activated by a program already known to its users through "social engineering" methods.

This copy corresponds to the original
Legal Director 1
Legal Department signed
Yuliana

Unit Test: a test conducted by developers to test the functionality of small modules within a software program.
Upload and Download: electronic data transfer between two computers or similar systems.
User Acceptance Test: a final test by users to test the overall functionality and interoperability of an application system.
User Log: a file on a computer that stores information regarding user activities, such as login and logout times.
Virus: a destructive program that becomes active with human assistance (execution) and cannot replicate its own spread, as it is carried out by humans, such as copying, usually via email attachments, games, pirated programs, and others.
Website: a web site or information delivered through a web browser or a collection of web pages designed, presented, and interconnected to form an information source and/or to carry out transaction functions.
Worm: a computer program designed to automatically multiply itself and attach to emails or as part of network messages. Worms attack networks and result in the saturation of used bandwidth, thereby hindering the data transmission rate on the network.

Established in Jakarta on June 6, 2017
EXECUTIVE HEAD OF BANKING SUPERVISOR
FINANCIAL SERVICES AUTHORITY, signed
NELSON TAMPUBOLON

Implementation of Risk Management in the Use of Information Technology by Universal Banks

Appendix 2.1.10

DATA CENTER (DC) / DISASTER RECOVERY CENTER (DRC)

Appendix 2.1.11

INFORMATION TECHNOLOGY SECURITY

Appendix 2.1.12

DISASTER RECOVERY PLAN (DRP)

Appendix 2.1.13

INFORMATION TECHNOLOGY SERVICE PROVIDERS

13.1 Management of IT Service Provider Usage

13.2 Bank as IT Service Provider

Appendix 2.1.14

INFORMATION TECHNOLOGY COSTS

Appendix 2.2

REPORT ON IT DEVELOPMENT PLAN

Appendix 2.3

REQUEST FOR APPROVAL

Appendix 2.3.1

REQUEST FOR APPROVAL

PLAN FOR PROVIDING INFORMATION TECHNOLOGY SERVICES BY THE BANK

Appendix 2.3.2

REQUEST FOR APPROVAL

PLAN FOR ISSUING ELECTRONIC BANKING SERVICES *)

Appendix 2.3.3

REQUEST FOR APPROVAL

PLAN FOR MANAGING ELECTRONIC SYSTEMS LOCATED AT DATA CENTER AND/OR DISASTER RECOVERY CENTER BY SERVICE PROVIDERS OUTSIDE INDONESIA *)

Appendix 2.3.4

REQUEST FOR APPROVAL

PLAN FOR MANAGING INFORMATION TECHNOLOGY-BASED TRANSACTION PROCESSING BY INFORMATION TECHNOLOGY SERVICE PROVIDERS OUTSIDE INDONESIA *)

Appendix 2.4

INFORMATION TECHNOLOGY REALIZATION REPORT*)

Appendix 2.4.1

REALIZATION OF ACTIVITIES AS

INFORMATION TECHNOLOGY SERVICE PROVIDER*)

Lineage: In force