Standard for Information Technology Implementation for Rural Banks and Sharia Rural Financing Banks

To:

The Board of Directors of Rural Banks; and
The Board of Directors of Sharia Rural Financing Banks,
At their respective locations.

COPY
CIRCULAR LETTER OF THE FINANCIAL SERVICES AUTHORITY NUMBER 15 /SEOJK.03/2017 CONCERNING STANDARDS FOR INFORMATION TECHNOLOGY IMPLEMENTATION FOR RURAL BANKS AND SHARIA RURAL FINANCING BANKS

In connection with the Financial Services Authority Regulation Number 75/POJK.03/2016 concerning Standards for Information Technology Implementation for Rural Banks and Sharia Rural Financing Banks (State Gazette of the Republic of Indonesia Year 2016 Number 308, Additional State Gazette Number 5998), hereinafter referred to as POJK SPTI, it is necessary to regulate implementation provisions regarding the Standards for Information Technology Implementation for Rural Banks (BPR) and Sharia Rural Financing Banks (BPRS) in this Financial Services Authority Circular Letter as follows:

I. GENERAL PROVISIONS

Information Technology implementation by BPR and BPRS, which covers the processes of planning, development and procurement, as well as maintenance of Information Technology, is the responsibility of the Board of Directors and Board of Commissioners, ensuring that Information Technology implementation runs properly in order to achieve the vision and mission of the respective BPR and BPRS.
This Financial Services Authority Circular Letter is intended to provide guidelines for Information Technology implementation for BPR and BPRS as a minimum reference in the implementation of Information Technology, including in the formulation of policies and procedures for Information Technology implementation for BPR and BPRS.
This Financial Services Authority Circular Letter covers guidelines for Information Technology implementation, formats, and procedures for submitting reports related to Information Technology implementation.

II. INFORMATION TECHNOLOGY IMPLEMENTATION STANDARDS

In accordance with the provisions regulated in Article 2 paragraph (1) of POJK SPTI, Information Technology implementation by BPR or BPRS must include at least:
a. Core Banking Applications and Data Centers for BPR or BPRS having core capital of less than IDR 50,000,000,000.00 (fifty billion rupiah); or b. Core Banking Applications, Data Centers, and Disaster Recovery Centers for BPR or BPRS having core capital of at least IDR 50,000,000,000.00 (fifty billion rupiah).
In accordance with the provisions regulated in Article 5 paragraph (1) letter b of POJK SPTI, BPR and BPRS must ensure that Core Banking Applications are capable of performing bookkeeping of transactions across office networks:
a. on the same day for BPR and BPRS that do not provide electronic banking services and do not engage in activities as issuers of Automated Teller Machine (ATM) cards; b. online and in real-time for BPR and BPRS that provide electronic banking services and/or engage in activities as issuers of Automated Teller Machine (ATM) cards.

Electronic banking services as referred to in letters a and b also include activities as issuers of debit cards as referred to in the Financial Services Authority Regulation regarding activities and office networks of BPR based on core capital for BPR, and the Financial Services Authority Regulation regarding Sharia Rural Financing Banks for BPRS.

Policies and procedures for Information Technology implementation as referred to in number 1 refer to the Standards for Information Technology Implementation as referred to in Appendix I, which is an inseparable part of this Financial Services Authority Circular Letter. The formulation of policies and procedures for Information Technology implementation is carried out in accordance with the needs and complexity of the business of BPR and BPRS.
In accordance with the provisions regulated in Article 13 paragraph (2) of POJK SPTI, the policies and procedures as referred to in number 3 must include at least:
a. authority and responsibility of the Board of Directors, Board of Commissioners, and work units or employees responsible for Information Technology implementation; b. development and procurement;
c. Information Technology operations;
d. communication networks; e. information security; f. Disaster Recovery Plan; g. Information Technology internal audit; and h. cooperation with Information Technology service providers.
In accordance with the provisions regulated in Article 6 paragraph (2) and Article 30 paragraph (1) of POJK SPTI, BPR and BPRS that procure Core Banking Applications by purchasing must purchase the application from a Core Banking Application provider that is a legal entity no later than 3 (three) years since the POJK SPTI came into effect.
The procurement of Core Banking Applications referred to herein means procurement for new Core Banking Applications or replacement of Core Banking Applications.
In the event that BPR and BPRS carry out development or maintenance of owned Core Banking Applications without procuring new Core Banking Applications, BPR and BPRS must ensure that the development or maintenance of the Core Banking Applications referred to complies with the provisions regulated in Article 5 paragraph (1) of POJK SPTI.
No later than 3 (three) years since the POJK SPTI came into effect, Core Banking Applications must meet the minimum standards of Core Banking Applications as referred to in Article 5 paragraph (1) of POJK SPTI.
In accordance with the provisions regulated in Article 6 paragraph (4) and paragraph (5) of POJK SPTI, cooperation carried out by BPR and BPRS with Core Banking Application providers in the development and procurement of Core Banking Applications since the POJK SPTI came into effect must be implemented based on a written agreement covering at least the main points of the cooperation agreement as referred to in Appendix I CHAPTER II letter E, which is an inseparable part of this Financial Services Authority Circular Letter.
The written agreement as referred to in number 8 also contains clauses regarding the obligation for the Core Banking Application provider to:
a. have competent human resources, namely having special expertise in the field of Information Technology proven by expertise certificates, experience letters, and/or educational diplomas in accordance with the needs of Information Technology implementation; b. provide guarantees that during the term of the agreement, the Core Banking Application provider:
1. ensures that the Core Banking Applications work according to specifications;
2. is responsible if problems occur in the Core Banking Applications; and
3. performs maintenance of the Core Banking Applications.
In accordance with the provisions regulated in Article 17 paragraph (2) of POJK SPTI, cooperation between BPR and BPRS with Information Technology service providers in the implementation of Information Technology since the POJK SPTI came into effect must be based on a cooperation agreement containing at least the main points of the cooperation agreement as referred to in Appendix I CHAPTER VIII, which is an inseparable part of this Financial Services Authority Circular Letter.
The cooperation agreement between BPR and BPRS as referred to in number 10 with Information Technology service providers for the implementation of Information Technology that already existed at the time the POJK SPTI came into effect must be adjusted by referring to Appendix I CHAPTER VIII, which is an inseparable part of this Financial Services Authority Circular Letter.
In accordance with the provisions regulated in Article 22 paragraph (2) of POJK SPTI, the internal audit function regarding Information Technology implementation must be carried out periodically at least 1 (one) time in 1 (one) year with implementation as follows:
a. for BPR, the internal audit function regarding Information Technology implementation is carried out:
1. as part of the internal audit of BPR in accordance with the provisions regulated in the Financial Services Authority Regulation regarding the application of corporate governance for BPR; or
2. separately from the implementation of the internal audit of BPR in the event that the audit of Information Technology implementation is carried out by external auditors.
  b. for BPRS, the internal audit function regarding Information Technology implementation continues to be carried out by referring to the provisions regarding the application of BPRS corporate governance and other relevant regulations. The implementation of the internal audit function regarding Information Technology implementation may be carried out by the BPRS itself or by using external auditors.
The scope of internal audit regarding Information Technology implementation must include at least the aspects:
a. Core Banking Applications, to ensure that Core Banking Applications have met the minimum standards as referred to in POJK SPTI; and b. authority and responsibility of the Board of Directors, Board of Commissioners, and work units or employees responsible for Information Technology implementation, to ensure the implementation of authority and responsibility of the Board of Directors, Board of Commissioners, and work units or employees responsible for Information Technology implementation is carried out well in accordance with the provisions regulated in POJK SPTI.

III. REPORTS

Routine Reports
a. In accordance with the provisions regulated in Article 23 paragraph (1) of POJK SPTI, BPR and BPRS must submit reports on the implementation of the Information Technology internal audit function to the Financial Services Authority with implementation as follows:
1. For BPR, the report on the implementation of the internal audit function regarding Information Technology implementation is submitted as part of the report on the implementation and main points of internal audit results as regulated in the Financial Services Authority Regulation regarding the application of corporate governance for BPR, whether carried out by the BPRS itself or by using external auditors.
2. For BPRS, in the event that there are no provisions for reports on the implementation of the Information Technology internal audit function, the report on the implementation of the internal audit function regarding Information Technology implementation is submitted as a special report, whether carried out by the BPRS itself or by using external auditors.
b. The report on the implementation of the internal audit function regarding Information Technology implementation as referred to in letter a is submitted to the Financial Services Authority within the following time limits:
1. for BPR, referring to the submission time limit for reports on the implementation and main points of internal audit results as referred to in the Financial Services Authority Regulation regarding the application of corporate governance for BPR; and
2. for BPRS, submitted no later than January 31 for audits carried out in the previous year-end period.
Incident Reports
a. Current Status Report
1. In accordance with the provisions regulated in Article 24 of POJK SPTI, BPR and BPRS must submit a current status report on Information Technology implementation to the Financial Services Authority, including at least explanations regarding Information Technology implemented, an organizational structure describing Information Technology implementation, and policies and procedures owned regarding Information Technology implementation by BPR or BPRS.
  Included in the scope of the current status report on Information Technology implementation is the adjustment of cooperation agreements for Information Technology implementation between BPR or BPRS and Information Technology service providers as referred to in Roman II number 11.
2. The current status report on Information Technology implementation as referred to in number 1 is submitted to the Financial Services Authority within the following timeframes:
  a) for the first report, submitted within a period of 1 (one) year since this POJK SPTI came into effect; and b) after the 1 (one) year period as referred to in letter a) has passed and a fundamental change occurs in Information Technology implementation. What is meant by fundamental change in Information Technology implementation is a change to Information Technology configuration or Core Banking Applications, procurement of Core Banking Applications, cooperation with Information Technology service providers, and other fundamental development and procurement of Information Technology that can add and/or increase the risk of BPR or BPRS.
  
  c) submission of fundamental changes uses the current status report format accompanied by information regarding explanations and reasons for changes as referred to in Appendix II, which is an inseparable part of this Financial Services Authority Circular Letter. d) the current status report on Information Technology implementation as referred to in letter b) is submitted no later than 10 (ten) working days since the Information Technology effectively operates.
b. Report on the Realization of Cooperation with Information Technology Service Providers In accordance with the provisions as referred to in Article 25 of POJK SPTI, BPR and BPRS must submit a report on the realization of cooperation with Information Technology service providers in the implementation of Information Technology no later than 10 (ten) working days since the Information Technology implementation of BPR or BPRS effectively operates. The report on the realization of cooperation is attached with supporting documents in the form of cooperation agreements and provider profiles.

c. Report on Critical Incidents, Misuse, and/or Crimes in Information Technology Implementation
1. In accordance with the provisions as referred to in Article 26 paragraph (1) of POJK SPTI, BPR and BPRS must submit reports on critical incidents, misuse, and/or crimes in Information Technology implementation that can or have resulted in significant financial losses and/or disrupted the operational smoothness of BPR or BPRS.
2. In accordance with the provisions as referred to in Article 26 paragraph (2) of POJK SPTI, reports on critical incidents, misuse, and/or crimes in Information Technology implementation must be submitted:
  a) via electronic mail (e-mail) or telephone to the supervisor of BPR or BPRS at the Regional Office or Financial Services Authority Office overseeing the region of the BPR or BPRS headquarters no later than 1 (one) day after the critical incident, misuse, and/or crime is known; and b) via written report no later than 7 (seven) working days since the critical incident, misuse, and/or crime is known.

IV. OTHERS

Procedures for Report Submission
Submission of reports as referred to in Roman III is carried out as follows:
a. for BPR, submitted to the Financial Services Authority u.p. Regional Office or Financial Services Authority Office overseeing the region of the BPR headquarters; b. for BPRS, submitted to the Financial Services Authority u.p. Sharia Banking Department, Regional Office or Financial Services Authority Office overseeing the region of the BPRS headquarters.
Compliance with provisions for BPR or BPRS when POJK SPTI was promulgated is carried out by considering the following:
a. in accordance with the provisions as referred to in Article 30 paragraph (1) of POJK SPTI, BPR and BPRS that have obtained business licenses at the time this POJK SPTI was promulgated must comply with the provisions as referred to in Article 2 paragraph (1), Article 3 paragraph (1), Article 3 paragraph (2), Article 4, Article 5 paragraph (1), Article 6 paragraph (2), Article 8, Article 9, Article 12 paragraph (1), Article 13 paragraph (1), Article 14 paragraph (1), Article 14 paragraph (3), Article 14 paragraph (4), Article 16, Article 22 paragraph (1), Article 22 paragraph (2), Article 22 paragraph (3), Article 23 paragraph (1) and Article 23 paragraph (3) no later than 3 (three) years since this POJK SPTI came into effect. b. the provisions as referred to in letter a also apply to BPR or BPRS that obtain merger, consolidation, and/or change of business activities from BPR to BPRS licenses after the POJK SPTI was promulgated.
c. BPR and BPRS in the process of establishment and have not obtained business licenses from the Financial Services Authority at the time this POJK SPTI was promulgated must comply with all provisions in POJK SPTI at the start of operational activities in accordance with the provisions as referred to in the Financial Services Authority Regulation regarding rural banks.

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

V. CLOSING

The provisions in this Financial Services Authority Circular Letter shall come into effect on the date of determination.
Determined in Jakarta on April 6, 2017
EXECUTIVE HEAD OF BANKING SUPERVISOR
FINANCIAL SERVICES AUTHORITY, signed
NELSON TAMPUBOLON

APPENDIX I
CIRCULAR LETTER OF THE FINANCIAL SERVICES AUTHORITY NUMBER 15 /SEOJK.03/2017 CONCERNING STANDARDS FOR INFORMATION TECHNOLOGY IMPLEMENTATION FOR RURAL BANKS AND SHARIA RURAL FINANCING BANKS

GUIDELINES FOR INFORMATION TECHNOLOGY IMPLEMENTATION FOR RURAL BANKS AND SHARIA RURAL FINANCING BANKS

TABLE OF CONTENTS
CHAPTER I : AUTHORITY AND RESPONSIBILITY OF THE BOARD OF DIRECTORS,
BOARD OF COMMISSIONERS, AND WORK UNITS OR
EMPLOYEES RESPONSIBLE FOR INFORMATION TECHNOLOGY IMPLEMENTATION A. AUTHORITY AND RESPONSIBILITY OF THE BOARD OF DIRECTORS B. AUTHORITY AND RESPONSIBILITY OF THE BOARD OF COMMISSIONERS
C. AUTHORITY AND RESPONSIBILITY
OF WORK UNITS OR EMPLOYEES RESPONSIBLE FOR
INFORMATION TECHNOLOGY
IMPLEMENTATION
CHAPTER II : DEVELOPMENT AND PROCUREMENT OF ELECTRONIC SYSTEMS
A. POLICIES AND PROCEDURES
FOR DEVELOPMENT AND PROCUREMENT OF ELECTRONIC
SYSTEMS
B. STAGES OF ELECTRONIC SYSTEM DEVELOPMENT

Initiation Stage 16
User Requirement Definition Stage
Electronic System Design Stage
Programming Stage 20
Testing Stage 22
Implementation Stage 23
Post-Implementation Review Stage
Operation Stage 25
Maintenance Stage 25
Disposal Stage 25
C. PROCUREMENT OF ELECTRONIC SYSTEMS 25
Procurement Standards 25
User Needs Analysis 26
Cost-Benefit Analysis 27
D. MAINTENANCE OF ELECTRONIC SYSTEMS 27
Change Management 27
Patch Management 29
Library 29
Conversion 30
Documentation Maintenance 30
E. WRITTEN AGREEMENTS FOR
DEVELOPMENT AND PROCUREMENT OF ELECTRONIC
SYSTEMS INCLUDING CORE BANKING
APPLICATIONS
CHAPTER III : INFORMATION TECHNOLOGY OPERATIONS 37
A. POLICIES AND PROCEDURES FOR INFORMATION TECHNOLOGY OPERATIONS
Policies and Procedures for Data
Management a) Policies and Procedures for Data Center Operations b) Policies and Procedures for Database Management c) Policies and Procedures for Library Management
Policies and Procedures for Planning,
Management, Maintenance, and
Deletion of Hardware and
Software a) Capacity Planning Policies and
Procedures b) Hardware and Software
Configuration Management Policies and Procedures c) Hardware and Software Maintenance Policies and Procedures d) Hardware and Software (Disposal) Policies and Procedures
Policies and Procedures for Change
Management (Change Management) a) Change Control 46 b) Patch Management 46 c) Data Migration 47
Policies and Procedures for Incident/Problem
Handling a) Help desk 47 b) Super User Usage Handling 48
Policies and Procedures for Information
Exchange Control (Exchange of
Information)
Policies and Procedures for Quality
Assurance Functions
Policies and Procedures for Managing
Relationships with Service Providers
CHAPTER IV : COMMUNICATION NETWORKS 50
A. POLICIES AND PROCEDURES FOR
COMMUNICATION NETWORKS
B. COMMUNICATION NETWORK DESIGN 51
C. COMMUNICATION NETWORK ACCESS
CONTROL
D. CONTROL, SECURITY, AND
MAINTENANCE OF COMMUNICATION
NETWORK OPERATIONS
E. COMMUNICATION NETWORK MONITORING 56
F. COMMUNICATION NETWORK SOFTWARE 57
G. COMMUNICATION NETWORK DATA SECURITY 57
H. COMMUNICATION NETWORK DOCUMENTATION 57
CHAPTER V : INFORMATION SECURITY 58
A. INFORMATION SECURITY PRINCIPLES 58
B. INFORMATION SECURITY POLICIES 59
C. INFORMATION SECURITY PROCEDURES 60
a) Asset Management 60 b) Human Resource Management 60 c) Physical and Environmental Security 61 d) Logic Security (Logic Security) 62 e) Information Technology Operational Security f) Incident Handling in Information Security g) Backup and Restore Testing 67 h) Data Retention 67 i) Others 68
CHAPTER VI : DISASTER RECOVERY PLAN 69
A. POLICIES AND PROCEDURES FOR DISASTER
RECOVERY PLANS
Analysis of Disaster Recovery Plans
Types of Disaster Recovery Plan
Procedures
Components of Disaster Recovery Plan
Procedures
Determination of Clear Responsibilities
for Related Parties in
Disaster Recovery Plan Implementation.
B. DOCUMENTATION OF STRATEGIES AND PROCEDURES
FOR DISASTER RECOVERY
C. DISASTER RECOVERY PLAN TESTING 74
D. MAINTENANCE OF DISASTER RECOVERY
PLANS
CHAPTER VII : INFORMATION TECHNOLOGY INTERNAL AUDIT 77
A. ORGANIZATION IMPLEMENTING THE INTERNAL AUDIT FUNCTION FOR INFORMATION TECHNOLOGY IMPLEMENTATION B. GUIDELINES FOR INTERNAL AUDIT OF INFORMATION TECHNOLOGY IMPLEMENTATION
General Audit Policies 78
Audit Planning 80
Audit Execution 81
Reporting 81
Audit Follow-up 82
Development and Testing of Electronic
Systems
C. IMPLEMENTATION OF THE INTERNAL AUDIT FUNCTION
FOR INFORMATION TECHNOLOGY IMPLEMENTATION BY
EXTERNAL AUDITORS
D. INTERNAL AUDIT OF ACTIVITIES CARRIED OUT BY INFORMATION TECHNOLOGY SERVICE PROVIDERS
CHAPTER VIII : COOPERATION WITH INFORMATION TECHNOLOGY
SERVICE PROVIDERS
A. PROCESS FOR SELECTING INFORMATION TECHNOLOGY SERVICE PROVIDERS
Needs Determination 85
Cost-Benefit Analysis 86
Due Diligence on Information Technology
Service Providers
Determination of Information Technology
Service Providers
B. COOPERATION AGREEMENTS WITH
INFORMATION TECHNOLOGY SERVICE PROVIDERS
C. FOLLOW-UP ON THE REALIZATION OF
COOPERATION AGREEMENTS WITH
INFORMATION TECHNOLOGY SERVICE PROVIDERS
Risk Anticipation 93
Risk Follow-up 94
Emergency Plan 94
Disaster Recovery Plan 94
Guarantee of Information Technology
Implementation Sustainability
Glossary 96

CHAPTER I
AUTHORITY AND RESPONSIBILITY OF THE BOARD OF DIRECTORS, BOARD OF COMMISSIONERS, AND WORK UNITS OR EMPLOYEES RESPONSIBLE FOR INFORMATION TECHNOLOGY IMPLEMENTATION

In the implementation of Information Technology by BPR and BPRS, the Board of Directors and Board of Commissioners must ensure that Information Technology implementation runs properly and in line with the achievement of the vision and mission of the respective BPR and BPRS. In order to realize effective and efficient Information Technology implementation, the Board of Directors and Board of Commissioners must involve all levels of the BPR and BPRS organization. Effective management of Information Technology implementation by BPR and BPRS is necessary to generate the information required for decision-making by both BPR or BPRS and external parties. The success of BPR and BPRS Information Technology implementation depends heavily on the commitment of the Board of Directors, Board of Commissioners, and work units or employees responsible for Information Technology implementation, as well as users.

A. AUTHORITY AND RESPONSIBILITY OF THE BOARD OF DIRECTORS The authority and responsibility of the Board of Directors in Information Technology implementation must include at least:

Determining the development and procurement plan for BPR or BPRS Information Technology, covering activities:
a) evaluating, approving, and monitoring the development and procurement process of BPR or BPRS Information Technology; and b) ensuring that BPR and BPRS have cooperation agreements with Information Technology service providers or Core Banking Application providers that regulate the roles, relationships, rights, obligations, and responsibilities of all parties bound by the cooperation agreement, and ensuring that the cooperation agreement meets the validity requirements of the agreement and can

protect the interests of BPR and BPRS if issues arise later when BPR and BPRS cooperate with service providers;
2. establish policies and procedures related to the management of Information Technology that are adequate and communicate them effectively, both to the implementing work units and to Information Technology users;
3. monitor the adequacy of performance and efforts to improve the management of Information Technology;
4. ensure that the Information Technology used by BPR or BPRS can support business development, achievement of business goals, and continuity of service to BPR or BPRS customers, including activities:
a) providing accurate data and information to support an adequate management information system for BPR or BPRS; b) managing BPR or BPRS Information Technology capable of supporting sustainable business development for BPR and BPRS; c) managing BPR or BPRS Information Technology capable of supporting continuity of service to BPR and BPRS customers; and d) monitoring the development and procurement processes carried out by the working team as referred to in the Chapter regarding the development and procurement of Electronic Systems.
5. ensure an increase in human resource competence related to the management and use of Information Technology, including through adequate education, training, or certification, and education programs to increase awareness of information security;
6. ensure the availability of an effective information security management system and communicate it to the implementing work units and Information Technology users;
7. ensure the availability of adequate Information Technology management policies and procedures that are communicated and applied effectively both to work units responsible for implementation and to work units using Information Technology, at least including activities formulating policies, plans, and budgets for Information Technology management; and
8. ensure documentation of every change and development made to the Electronic System, including software, whether carried out independently (in-house) or in cooperation with Information Technology service providers.

B. AUTHORITIES AND RESPONSIBILITIES OF THE BOARD OF COMMISSIONERS The authorities and responsibilities of the Board of Commissioners in the management of Information Technology include at least:

directing and monitoring fundamental development and procurement plans for BPR or BPRS Information Technology, including:
a) significant changes to Information Technology configuration or Core Banking Applications; b) procurement of new Core Banking Applications; c) cooperation with Information Technology service providers; and/or d) other fundamental Information Technology development and procurement that can add and/or increase the risk of BPR or BPRS; and
evaluating the accountability of the Board of Directors regarding the management of BPR or BPRS Information Technology.

C. AUTHORITIES AND RESPONSIBILITIES OF WORK UNITS OR EMPLOYEES RESPONSIBLE FOR INFORMATION TECHNOLOGY MANAGEMENT
The authorities and responsibilities of work units or employees responsible for Information Technology management include at least:

assisting the Board of Directors and Board of Commissioners in Information Technology management, covering planning, implementation, and monitoring, manifested in activities:
a) ensuring the adequacy and effectiveness of Information Technology management policies and procedures; b) implementing all Information Technology management policies and procedures established by the Board of Directors; c) ensuring adequate supervision in every development and procurement of Information Technology systems; d) submitting periodic reports on Information Technology management to the Board of Directors, and if necessary, proposing actions to address weaknesses in Information Technology management found; and e) ensuring appropriate actions have been taken to correct audit findings from both internal and external auditors or based on reports from the Financial Services Authority;
supporting Information Technology development and procurement, at least including:
a) ensuring that BPR or BPRS Information Technology development and procurement comply with policies and procedures established by the Board of Directors; b) ensuring that project management related to Information Technology development and procurement is implemented consistently and adequately; and c) ensuring that written agreements between BPR or BPRS with core banking application providers or Information Technology service providers cover matters regulated in the POJK on IT Management and this Financial Services Authority Circular;
supporting Information Technology implementation, operations, and maintenance, at least including:
a) providing support in resolving Information Technology issues to user work units responsively and on time; b) ensuring that all information held by Information Technology user work units receives good protection against all disturbances that could cause losses due to the leakage of important data/information; and c) monitoring the performance of Information Technology services at BPR or BPRS, including the percentage of system downtime (downtime error), security violations, project progress, and implementation of Service Level Agreements (SLA).
carrying out efforts to resolve Information Technology issues that cannot be resolved effectively, efficiently, and on time by user work units; and
documenting every change and development made to the Electronic System, including software, whether carried out independently (in-house) or in cooperation with Information Technology service providers.

CHAPTER II
DEVELOPMENT AND PROCUREMENT OF ELECTRONIC SYSTEMS In the context of developing and procuring Electronic Systems, which may include internal software development, or the purchase of software, hardware, and/or Electronic System development services from Information Technology service providers, BPR and BPRS must take control steps to produce systems and data that maintain confidentiality, integrity, and availability, and support the achievement of BPR or BPRS goals, at least including:
a. establishing and implementing consistent procedures for the development and procurement of Electronic Systems; b. applying project management in the development and procurement of Electronic Systems;
c. conducting adequate testing during the development and procurement of Electronic Systems, including trials involving user work units, to ensure the accuracy and functionality of the Electronic System according to user needs and the compatibility of a system with other systems;
d. documenting the procurement, development, and maintenance of Electronic Systems; e. having Electronic System change management; and f. ensuring that BPR and BPRS Electronic Systems are able to retrieve information completely.

In the context of developing and procuring Electronic Systems, BPR and BPRS must apply project management to ensure that Electronic Systems have been developed with a good structure and have accommodated user needs and are consistent with the Information Technology owned by BPR or BPRS. The application of project management is carried out by a working team consisting of at least members from the work units or employees responsible for Information Technology management and Information Technology user work units. The working team reports every development and procurement process to the Board of Directors.

Meanwhile, the internal audit work unit or executive officials responsible for implementing internal audit functions are independent parties that provide input to the aforementioned working team to ensure the adequacy of controls in the development and procurement of Electronic Systems.

In carrying out Electronic System change management during application development, such as changes in user requirements, changes in supporting technologies used, and change management procedures must be formulated, implemented, and documented properly and correctly. Change requests must be reviewed before approval to determine other methods for making changes, change costs, and the time required for programming activities. The actual causes of changes must be known and documented properly and correctly. Audit trails of all requested changes must be maintained.

A. POLICIES AND PROCEDURES FOR THE DEVELOPMENT AND PROCUREMENT OF ELECTRONIC SYSTEMS Matters to be considered in the policies and procedures for the development and procurement of Electronic Systems include at least:

every development and procurement of Electronic Systems must always involve the work units or employees responsible for Information Technology management;
for Electronic Systems developed and procured by Information Technology service providers, BPR and BPRS must conduct a process for selecting Information Technology service providers referring to regulations regarding the implementation of outsourced work in accordance with applicable laws and regulations. BPR and BPRS must also ensure the adequacy of training and implementation manuals (manual books) prepared as part of the cooperation agreement between BPR or BPRS and the Information Technology service provider;
policies and procedures for the development and procurement of Electronic Systems refer to development stages, specification compliance in procurement, and the implementation of maintenance activities;
policies and procedures that BPR or BPRS must have in project management include:
a) cost-benefit analysis, including an analysis of the benefits to be received from the Electronic System, including Core Banking Applications to be developed and procured, based on current problems and obstacles in Electronic System management, including Core Banking Applications, compared to the costs to be incurred, including determining whether to use internal resources or outsourcing; b) relevant security requirements before the Electronic System is developed or procured; c) separation of environments for development, testing, and operations, including access restrictions to each environment; d) software selection analysis to ensure user needs are met; e) cooperation agreements between BPR and BPRS with Information Technology service providers that meet the validity requirements of the agreement; f) application of maintenance management for all processes of development and procurement of Electronic Systems that have been implemented; g) documentation of all results at every stage of project management; and h) a written project plan at least including:
1) project identification and project manager;
2) project objectives, background information, and development and procurement strategy;
3) description of main responsibilities of each personnel in project management;
4) procedures for collecting and disseminating information;
5) target results criteria for each stage of development and procurement (acceptance criteria);
6) security and control issues to be considered;
7) cut-off date for switching system application usage from the old version to the new version;
8) development and procurement standards to be used for project supervision, system control, and quality assurance;
9) documentation produced at each project stage;
10) project stage schedule and activities to be completed in each stage;
11) budget estimate of total project costs;
12) testing plan identifying testing requirements and testing procedure schedules; and
13) training plan identifying training needs and schedules so that users can use and maintain applications post-implementation;
the Electronic System change management procedures that BPR or BPRS must create are modification procedures at least including:
a) review before modification and authorization; b) testing before modification (in a separate testing environment); c) data backup procedures before modification; d) documentation consisting of:
1) explanation of modification;
2) reasons for applying or rejecting proposed modifications;
3) name of the individual performing the modification;
4) date and time the modification was performed; and
5) copy of the modified source code (if any).
e) evaluation after modification;
documentation that must be created during the modification process consists of:
a) priority information; b) identification of systems, Databases, and affected work units; c) name of the individual responsible for making the change; d) resource requirements; e) cost prediction; f) completion date prediction; g) implementation date prediction; h) consideration of potential security and reliability; i) testing requirements; j) implementation procedures; k) estimated downtime during implementation; l) backup procedures; m) documentation updates (application designs and scripts, network topology, user manuals, contingency plans, etc.); n) modification acceptance documentation from all related work units (users, technology, quality control, security, audit, etc.); and o) post-implementation audit documentation (comparison between plans and results).

B. STAGES OF ELECTRONIC SYSTEM DEVELOPMENT
One form of methodology that BPR or BPRS can use in developing Electronic Systems is the System Development Life Cycle (SDLC), which is divided into initiation and planning, requirement definition, design, programming, testing, implementation, post-implementation review, maintenance, and disposal stages, detailed as follows:

Initiation Stage
Initiation is the initial planning stage for developing Electronic Systems, including Core Banking Applications, to define the scope, objectives, schedule, and initial budget required.
The initiation stage begins with identifying needs to add, refine, or improve a system through a written proposal to obtain Board of Directors approval. The submission is made by the user work unit together with the work units or employees responsible for Information Technology management. The initiation stage consists of at least the following steps:
a) Submission of a written proposal containing user need identification to add, refine, or improve a system, objectives, and expected benefits, cost-benefit analysis, and the benefits of the Electronic System to be developed to support business strategy. The cost-benefit analysis includes an analysis of the benefits to be received from the Electronic System, including Core Banking Applications to be developed and procured, based on current problems and obstacles in Electronic System management, including Core Banking Applications, compared to the costs to be incurred, including determining whether to use internal resources or outsourcing. From this analysis, BPR and BPRS can determine the alternatives to be used. If an Electronic System from an Information Technology service provider is used, attention must also be paid to specification compliance with needs, impact on existing systems, after-sales technical support, financial condition of the Information Technology service provider, documentation completeness, and training. b) Board of Directors evaluation of the written proposal. c) Board of Directors approval of the written proposal regarding the development of new Electronic Systems or changes to Electronic Systems. After development approval is obtained at the initiation stage, BPR and BPRS conduct planning for more detailed identification of specific activities and resources needed to complete the project. This planning stage produces a project plan that must serve as a reference in project implementation and must be updated according to project developments.
User Requirement Definition Stage
User Requirement Definition is the process of analyzing user requirements for Electronic Systems, including Core Banking Applications.
Based on the written proposal approved by the Board of Directors, the working team can begin to prepare a detailed user requirement definition as the basis for starting Electronic System development. At this stage, all user requirements for the Electronic System are collected based on example documents, existing process and system specifications, interviews with end-users, and research and analysis of applicable regulations. This user requirement definition stage consists of:
a) Requirements Elicitation, which is the process of collecting information regarding the objectives of Electronic System development, desired results, system capabilities in accommodating business process needs, and system usage methods. b) Requirements Analysis, which is the process of understanding problems and needs to determine solutions that can be developed. At this stage, general estimates of time and cost for development for each requirement are determined. The results of the requirements analysis are used to generate business process flows that can clarify understanding of needs and solutions, both for user work units and software developers (work units or employees responsible for Information Technology management in case of independent development, or Information Technology service providers in case of development through cooperation). c) Requirements Specification, which is the process describing the functional systems to be developed, both in terms of software and supporting hardware as well as Database design. Requirements specifications must be complete, comprehensive, testable, consistent, clear, and detail the input, process, and output requirements needed. d) Requirements Management, which is the process to identify, control, and store every change to requirements during the Electronic System development process.
Electronic System Design Stage
Electronic System design is the process of converting identified information needs, functions, and networks during the initiation stage into design specifications to be used by developers.
One design technique is using prototypes that develop mockup designs of parts of the Electronic System such as screen displays, data structures, and system architecture. End-users, designers, developers, database administrators, and network administrators must conduct reviews and select designs to be used as prototypes in an iterative process until an agreed-upon design is used. The organizational unit implementing the internal audit function for Information Technology management and quality control must be involved as resource persons in the evaluation and approval process of the design to be used. At the design stage, a standard for Electronic System controls is required, including policies and procedures related to user activities and integrated controls in the Electronic System to be developed. At this stage, the internal audit work unit or executive officials responsible for implementing internal audit functions participate in providing control input that must be applied in the Electronic System. This stage is necessary to increase system security, integrity, and reliability by ensuring that authorized, accurate, complete, and safe input, process, and output information is maintained. Based on their purpose, controls are divided into preventive, detection/findings, or corrective controls. Controls that must be carried out include at least:
a) Input Control
At least includes checks on data validity/truthfulness, data/parameter ranges, and data duplication that is input. b) Process Control Ensures processes work accurately and can store or reject information. Process controls that can be performed automatically by the Electronic System include at least Error Reporting, Transaction Logs, sequence checks, and file backups. c) Output Control Ensures the system manages information securely and distributes process results information correctly and deletes information that has passed its retention period.
Programming Stage
Programming is the process of converting approved designs into programming languages. During this stage, the working team must create a testing plan that must be conducted. In addition, the working team must also update the migration, implementation, and end-user training plans, and documentation of maintenance manuals. Furthermore, in this stage, the working team must pay attention to:
a) Programming Standards, which explain among other things regarding programmer responsibilities. In the context of applying project management, the project manager must understand the entire programming process to ensure programmer responsibilities are met, at least:
1) Limiting programmer access to data, applications, utilities, and systems outside their responsibilities. Library management controls can be used to manage such access; and
2) Version control is a method that systematically stores the chronology of improved application copies and serves as one of the application documents.
b) Documentation
1) The working team must manage and maintain detailed documentation for every application that is part of the Electronic System, whether developed independently or purchased/developed by Information Technology service providers, including:
a) detailed application description; b) programming documentation; c) formats used (databases, displays, and information); d) naming standards; and e) end-user manuals.
2) 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.
3) In the event that applications are purchased or developed by Information Technology service providers, the working team must ensure that application documentation is performed

in accordance with the minimum documentation standards of BPR or BPRS.

Trial Stage
The trial is a process to test the design that has been converted into programming language so that the Electronic System, including Core Banking Applications, functions according to user needs and interoperability with other application systems used by BPR or BPRS. Modifications made during the trial must be documented to maintain the integrity of the overall application documentation.

BPR and BPRS must complete implementation instructions for user work units and work units or employees responsible for IT management, as well as prepare implementation and training plans. Trials that can be conducted by the working team, IT service providers, or Core Banking Application providers are:

a. Unit Testing
Unit testing is a trial of the functionality of each unit or sub-module of the Electronic System, including Core Banking Applications, that has been completed. Unit testing is conducted before system integration testing so that if anything happens, the configuration/code of that software unit can be changed without worrying about impacting other systems.

b. System Integration Testing
System integration testing is the testing of the overall functionality of the Electronic System, including Core Banking Applications, after being integrated into a complete whole. This testing is conducted to avoid difficulties in tracing if errors or bugs occur in the integration.

c. Stress Testing
Stress testing is a test of the resilience of the Electronic System or Core Banking Application in handling processes or transactions on a large scale/quantity.
Stress Testing is conducted after the working team, IT service provider, or Core Banking Application provider has provided a minutes of system integration testing results to the end user.

d. User Acceptance Test
User Acceptance Test (UAT) is the final trial process conducted by the working team, IT service provider, or Core Banking Application provider with the end user on the Electronic System, including Core Banking Applications, that has been completed, in order to test whether the overall system functionality meets user needs at the user requirements definition stage before deciding that implementation can be carried out. UAT can only be conducted after the working team, IT service provider, or Core Banking Application provider has provided minutes of the system integration testing results. At this stage, the internal audit work unit or executive officials responsible for carrying out the internal audit function may participate in testing while maintaining independence to ensure the availability, adequacy, and effectiveness of existing controls in the system. If the UAT results show that the Electronic System, including Core Banking Applications, has met user needs and BPR or BPRS security standards, a UAT minutes must be created that is approved by the end user.

Implementation Stage
The working team needs to carry out main activities, namely notification of the implementation schedule, training for users, and installation of the Electronic System, including Core Banking Applications, that have been approved into the operational environment. Other important matters that must be considered at least include:
a. application integrity examination in the form of adequate controls over the conversion from source code to object code to be implemented; b. data migration from the old Electronic System to the new Electronic System;
c. examination of the accuracy and security of migration results 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. data integrity, where BPR and BPRS must ensure the accuracy and reliability of the Database and data integrity; f. during implementation, BPR and BPRS avoid data patching because it can significantly affect data integrity in the Database on the operational server, so it must be avoided; and g. arrangement of source code storage and Database from the old system.
Post-Implementation Review Stage
The work unit or employee responsible for IT management must conduct a post-implementation review of the Electronic System to ascertain that all activities in the project plan have been carried out and project objectives have been achieved. The work unit or employee responsible for IT management must analyze the effectiveness of project management activities by comparing, among others, the plan and actual costs, benefits obtained, and project schedule accuracy. The results of the analysis must be documented and reported to the Board of Directors.
Operation Stage
In the operation of the Electronic System, there are procedures for supervising the implementation of operations, data security, data originality, data inputting, and Database management.
Maintenance Stage
Maintenance must be carried out on hardware, software, and documentation to ensure the operational effectiveness of the Electronic System. BPR and BPRS must establish maintenance procedures that are appropriate to the characteristics and risks of each Electronic System project.
Disposal Stage
Disposal is the final process of system development, including data, by deleting or destroying the system, including data. Every Electronic System resulting from development and procurement that is not used in operational activities and based on BPR or BPRS considerations is believed to be unnecessary and will no longer be maintained, will enter the final stage in the SDLC, namely the disposal/termination stage. This is done to ensure that the Electronic System used in operational activities is the most accurate and up-to-date Electronic System, and to prevent misuse by unauthorized parties.

C. PROCUREMENT OF ELECTRONIC SYSTEMS
In the process of procuring Electronic Systems, to ensure that the procured Electronic System meets functional needs, security criteria, and reliability, BPR and BPRS need to pay attention to the following:

Procurement Standards
Procurement standards must be applied to ensure that the procured Electronic System meets functional needs, security criteria, and reliability. In the procurement of Electronic Systems, BPR and BPRS must pay attention to at least:
a. a written proposal of the Electronic System procurement plan by the working team to obtain Board of Directors approval, which at least contains an analysis of user needs regarding the expected goals and benefits, cost-benefit analysis, and the benefits of the Electronic System to be procured to support business strategy; b. the suitability of IT service providers, written agreements, licenses, and products obtained with the IT management needs of BPR or BPRS;
c. the suitability of the offer specifications submitted by IT service providers with the IT management need specifications of BPR or BPRS;
d. comparison of offers submitted by one IT service provider with other IT service providers; and e. the financial condition of IT service providers and the commitment of IT service providers to service.
User Needs Analysis
Analysis of user needs is something that needs to be done before conducting an evaluation of the Electronic System to be procured. In this analysis, reasons for procuring the Electronic System, shortcomings of the currently used system, user needs and data processing, reports needed by users, the relationship of the Electronic System to be procured with other systems, and resources needed to install and maintain the Electronic System must be established. The Electronic System needs to be reviewed to ensure the availability of security controls and audit trails, such as access to data files, authorization processes, password controls, data access records, reports on security breach attempts, and the ability of utility programs to change data.
Cost-Benefit Analysis
In conducting cost-benefit analysis, the working team needs to compare each alternative IT service provider regarding the costs required, both direct and indirect costs. The capabilities and costs of each alternative need to be analyzed and compared, including among others the offered costs with specifications according to needs. The comparison as referred to above can be conducted by the working team by collecting references from other users or general information as information sources in evaluating the Electronic System to be procured, the computer systems used, changes or modifications made after implementation, duration of use, quality of after-sales support provided, performance on the same Electronic System, and other important information.

D. MAINTENANCE OF ELECTRONIC SYSTEMS
Maintenance activities must be carried out by BPR and BPRS, covering routine services and modifications to hardware, software, and related information to ensure the effectiveness of IT management for BPR or BPRS. For this purpose, Standard Operating Procedures (SOP) on Change Management are needed to ensure that changes occurring during the maintenance stage do not disrupt BPR and BPRS IT operational activities or degrade system performance/security. Change management includes overall modifications, minor modifications, and emergency changes (emergency modifications).

Change Management
The Board of Directors must establish detailed SOPs for change control containing procedures for authorization, testing, documentation, implementation, and socialization of such technology modifications. Modifications include hardware and software. Hardware modifications are needed to replace old, non-functional equipment, or to improve performance or storage capacity. Software modifications are needed to meet user needs, fix software problems, and security weaknesses in IT management, or to implement new technology. BPR and BPRS must coordinate Electronic System modifications through a centralized change management process due to the interconnection between Electronic Systems and operational systems. Based on their level of importance, modifications are classified into:
a. major modification, which is a significant functional change in the Electronic System, among others caused by the conversion or development of a new system due to the merger, amalgamation, or change of ownership of BPR or BPRS. Major modifications must be implemented following a structured process as done in the Electronic System development stages; b. minor modification, which is the implementation of changes in the Electronic System to improve performance, fix problems, or enhance security. Minor modification standards must include change requests, re-review, and approval procedures, and require BPR or BPRS to plan, test, and document all changes before implementation. BPR and BPRS must review all proposed modifications to ensure the modification's suitability with the existing system and ensure that only approved modifications are implemented. BPR and BPRS must establish Electronic System approval standards that include procedures to verify test results, check modified code, and ensure source code compatibility. After the Electronic System modification is completed, all source code must be secured in the library, both the latest version and the version before modification;
c. incidental modification (emergency modification), which is needed to fix problems in the Electronic System or restore operational processes quickly. Although such modifications must be completed quickly, they must still be implemented and controlled well. Emergency modifications must also be tested before implementation. However, if testing cannot be conducted thoroughly on emergency modifications before implementation, there must be procedures to properly backup files. This is important so that BPR and BPRS can cancel the modification if it causes disruption to the Electronic System.
Patch Management
IT service providers develop and release patches to fix problems in software, improve performance, and enhance security. If there are new patches, BPR and BPRS must evaluate the technical impact of installing such patches on business and security. BPR and BPRS must have procedures to identify the availability of patches from trusted sources. Patch management standards must include procedures for identification, evaluation, approval, testing, installation, and documentation of patches. BPR and BPRS must review all security settings and configuration parameters after the use of new patches to ensure that settings meet approved policies and procedures.
Library
To ensure the availability of applications used, BPR and BPRS must have a Library to store programs. Additionally, storage of information and/or documents in the form of data and applications related to servers originating from development and/or testing is necessary. Further explanation regarding libraries is contained in the chapter regulating IT operations.
Conversion
In the event of a merger, amalgamation, or change of ownership of BPR or BPRS requiring the integration of Electronic Systems, a conversion process needs to be carried out. In this process, major modifications are made to the existing Electronic System and new Electronic System development is carried out if necessary. In this conversion process, a structured process such as the Electronic System development stages must still be applied. Given the complexity of Electronic Systems in each BPR and BPRS involved in mergers, amalgamations, or changes of ownership, a comprehensive analysis of the impact of conversion on BPR or BPRS operational activities, particularly transaction processing, is required. To ensure the conversion process runs effectively, BPR and BPRS need to anticipate increased demand for balancing, reconciliation, exception handling, user and customer support (help desk), problem resolution (troubleshooting), network connectivity, and administrative system support.
Documentation Maintenance
Documentation standards must be able to identify main documents and detailed documents that have been approved and are in the desired format. Such documentation must contain all changes that have occurred in the system, applications, and configurations according to the standards determined.

E. WRITTEN AGREEMENTS FOR THE DEVELOPMENT AND PROCUREMENT OF ELECTRONIC SYSTEMS INCLUDING CORE BANKING APPLICATIONS Written agreements in carrying out the development and procurement of Electronic Systems, including Core Banking Applications, must at least include:

scope of work/services;
costs and duration of the cooperation agreement;
limitations of risks borne by BPR or BPRS and IT service providers (for the development and procurement of Electronic Systems) or Core Banking Application providers (for the development and procurement of Core Banking Applications) caused by changes, among others:
a. scope of the cooperation agreement; b. scope of business and organization of the IT service provider or Core Banking Application provider; and
c. legal aspects including regulations, copyrights, patents, and trademarks;
prohibition for IT service providers or Core Banking Application providers to use or disclose information owned by BPR and BPRS without the approval of BPR or BPRS, including in the process of implementing parallel runs;
guarantee from IT service providers or Core Banking Application providers for data security and confidentiality, especially bank secrets and customer personal data, including that the Electronic System can only be accessed by data owners (BPR and BPRS) and that the Electronic System does not contain back doors allowing access by unauthorized parties to the Electronic System and BPR or BPRS data;
responsibility of IT service providers or Core Banking Application providers to maintain the security and confidentiality of BPR or BPRS data/information after the expiration of the agreement;
statement that IT service providers or Core Banking Application providers guarantee the reliability of the Electronic System, including not using Electronic System features that could cause the Electronic System to not function properly;
standards for Electronic System specifications and performance at least including:
a. expected performance and functionality of the Electronic System; b. requirements and infrastructure needed to run the Electronic System;
c. identification of testing needs to determine the fulfillment of Electronic System performance standards; and
d. actions to be taken by IT service providers if the Electronic System fails during testing.
willingness of IT service providers or Core Banking Application providers to provide technical documents to BPR or BPRS related to the services performed by IT service providers or Core Banking Application providers, among others, IT process flows, implementation manuals (manual books), Database structures, and online help applications on the Electronic System that work interactively;
guarantee of access availability to source code in the event:
a. IT service providers or Core Banking Application providers can no longer provide services; b. modifications are needed that cannot be performed by IT service providers or Core Banking Application providers;
c. software, including Core Banking Applications, is made specifically for BPR or BPRS (proprietary); and/or
d. software is deemed important for the operational continuity of BPR or BPRS.
willingness of IT service providers to assist in the software conversion process, including data and data formats, when system replacement is needed in the future;
IT service providers or Core Banking Application providers provide guarantees at least that the Electronic System:
a. does not violate the intellectual property rights of third parties; b. does not contain undisclosed secret codes or automatic restrictions in the agreement;
c. works according to specifications and IT service providers or Core Banking Application providers are responsible in case of problems; and
d. is guaranteed to be maintained by IT service providers or Core Banking Application providers during the agreement period.
Service Level Agreement (SLA) containing performance standards of IT service providers or Core Banking Application providers, among others regarding agreed service levels and performance targets;
clause that the SLA remains valid in the event of a change of ownership, both in BPR or BPRS and in IT service providers or Core Banking Application providers;
reports on the performance monitoring results of IT service providers or Core Banking Application providers related to the SLA;
IT service providers or Core Banking Application providers cannot modify the Electronic System that has been agreed upon in the agreement without the approval of both parties;
requirement for IT service providers or Core Banking Application providers to report every critical incident, misuse, and/or crime in the development and procurement of Electronic Systems, including Core Banking Applications, that could result in significant financial loss and/or disrupt the operational continuity of BPR or BPRS;
requirement for IT service providers or Core Banking Application providers to conduct knowledge transfer to BPR or BPRS by planning training for BPR or BPRS human resources, among others regarding the number of human resources trained, the form of training, and the costs required, with the aim that BPR or BPRS human resources understand the IT used, especially IT process flows and Database structures of the Electronic System provided by the respective IT service providers or Core Banking Application providers;
sanctions and/or penalties for cancellation and/or breach of the cooperation agreement;
compliance with laws and regulations including dispute resolution in the event of disputes;
statement of no objection from IT service providers or Core Banking Application providers in the event that the Financial Services Authority or other competent parties according to laws and regulations conduct examinations of the service provision activities provided;
availability of data and information for examination purposes as referred to in item 21, including access rights, both logical and physical, to data managed by IT service providers or Core Banking Application providers;
implementation and costs of updating and modifying the Electronic System, if necessary;
requirement for IT service providers or Core Banking Application providers to have competent human resources, namely having special expertise in the field of Information Technology as evidenced by expertise certificates, experience letters, and/or educational diplomas according to the needs of IT management;
requirement for IT service providers or Core Banking Application providers to:
a. ensure that Core Banking Applications work according to specifications; b. be responsible in the event of problems with Core Banking Applications;
c. guarantee the maintenance of Core Banking Applications during the agreement period.
BPR and BPRS must ensure that in the cooperation agreement clauses there is a prohibition on subcontracting by IT service providers or Core Banking Application providers to third parties without the approval of BPR or BPRS

BPRS. In cases where part of the software development must be subcontracted, written approval from the BPR or BPRS is required. In granting such subcontract approval, BPR and BPRS must consider the complexity and availability of experts in the software development, as well as the data security of the BPR or BPRS. Furthermore, BPR and BPRS must ensure there is a clause stating that the Information Technology service provider or Core Banking Application provider is responsible for the software, even if it is designed or developed by another Information Technology service provider or Core Banking Application provider.

Development and performance specifications standards for Electronic Systems must at least consist of:
a. identification and functional specifications in which the operational Electronic System will function, and identification of milestones for the functionality that must be met by the Information Technology service provider or Core Banking Application provider during the development and procurement process; and b. regulations for modifying specifications and performance standards during the development and procurement process;
Software copyright (license) information must at least cover:
a. whether it is exclusive or non-exclusive; b. who and how many personnel in the BPR and BPRS can use the software, including usage within the network;
c. the duration of the software license;
d. the use of the software by other related entities is included in the license list; e. the application of copies of backup records of all important software required at a separate location (remote site) in the implementation of disaster recovery plans; and f. the continued validity of the license in the event of a merger, consolidation, or change of ownership, whether for the BPR and BPRS or the Information Technology service provider or Core Banking Application provider.
Provisions as referred to in numbers 1 through 28 apply mutatis mutandis to Information Technology service providers or Core Banking Application providers that receive subcontracts.

CHAPTER III
INFORMATION TECHNOLOGY OPERATIONS
This chapter discusses the activities and controls of Information Technology operations as a guideline for BPR and BPRS in implementing Information Technology management standards. Regulations regarding adequate Information Technology operations are crucial to ensure that information in computer systems is complete, accurate, current, integrity is maintained, and reliable, as well as free from errors, fraud, manipulation, misuse, and data destruction.

In managing Information Technology, BPR and BPRS must ensure that Information Technology operations are stable, secure, and efficient overall, whether managed independently or in cooperation with Information Technology service providers. BPR and BPRS must establish policies and procedures for Information Technology operations that guarantee the continuity of Information Technology operations and ensure their implementation in user work units, operator work units, or Information Technology service providers. Information Technology 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. Similarly, processing can be conducted in various distant but interconnected locations, whether online, real-time, or offline.

A. INFORMATION TECHNOLOGY OPERATIONAL POLICIES AND PROCEDURES BPR and BPRS are required to have policies and procedures covering every aspect of Information Technology operations in accordance with the POJK on IT Management (SPTI). The depth and scope of these policies and procedures are adjusted to the operational complexity of the BPR and BPRS. Policies and procedures must be documented in writing and used in the implementation of Information Technology operations. Policies and procedures contain details of tasks, responsibilities, delegation of authority, and implementation guidelines for user work units and Information Technology operator work units. Furthermore, BPR and BPRS must establish requirements to be met regarding hardware and software used in the production, testing, and development environments in the management of Information Technology for BPR and BPRS.

Data Management Policies and Procedures
BPR and BPRS must implement data management policies and procedures for Information Technology operations that cover:
a) Data Center Operational Policies and Procedures Policies and procedures applied in Data Center operational activities include routine and non-routine tasks. Activities related to Data Center operations must at least include:
(1) Task Scheduling
BPR and BPRS must have and execute schedules for all tasks to be performed in the operational Information Technology Data Center effectively and securely; (2) Task Operation Granting command line access to Information Technology operators must be limited according to authority in the determined task operation functions; (3) Report/Output Distribution Information produced by the system (output), in softcopy or hardcopy form, may be sensitive or confidential information. BPR and BPRS must have distribution procedures for reports/outputs, including determining the information to be generated (general or confidential), distributing outputs (hardcopy or softcopy), and destroying outputs that are no longer needed. These procedures are necessary to prevent the exposure of confidential information, reduce costs due to unnecessary outputs, and ensure output security; (4) backup processes (on-site and off-site), restore, download, and upload for data/Databases; and/or (5) activation of audit trails. b) Database Management Policies and Procedures Failure to manage and secure Databases can result in changes, destruction, or disclosure of confidential information, whether by users intentionally or unintentionally, or by unauthorized parties. Disclosure of confidential information by unauthorized parties can result in reputational, operational risks, and financial losses. BPR and BPRS must categorize data types in Databases into general information or confidential information categories. Databases storing confidential information require stricter controls compared to Databases storing general information. Therefore, BPR and BPRS must have a Database Administrator (DBA) function responsible for managing the BPR or BPRS Database. Policies and procedures that BPR and BPRS must possess regarding Databases include access, maintenance, issue handling, and Database administration. For BPR and BPRS that have Data Warehouses (DWH), BPR and BPRS must apply the same procedures as Database management policies and procedures. c) Library Management Policies and Procedures Libraries are collections of software or data with specific functions, stored and ready for use. In managing libraries, BPR and BPRS must conduct inventories and store all software and data stored in various media, including tapes and discs, including copies of all policies and procedures such as application execution instructions in the Data Center. BPR and BPRS must have policies and procedures regarding library management, including data access security procedures, handling of data storage media (for data/Databases and audit trails, retention periods, and testing of storage media, as well as access logs for data storage media). In creating policies, procedures, and standards for libraries, BPR and BPRS must consider the adequacy of storage/backup and disposal procedures for media. BPR and BPRS must always update data and application backups to ensure the backups can be used to restore systems,
applications, and data in the event of disasters or other disruptions.
Hardware and Software Planning, Management, Maintenance, and Disposal Policies and Procedures
BPR and BPRS must have policies and procedures for Information Technology operations related to hardware and software, including:
a) Capacity Planning Policies and Procedures
BPR and BPRS must have capacity planning policies and procedures to ensure that the hardware and software used by BPR or BPRS align with operational business needs and anticipate the development of BPR or BPRS businesses. Without good capacity planning, BPR and BPRS face risks of IT resource shortages or waste. Capacity planning is prepared periodically and always updated to accommodate existing changes. b) Hardware and Software Configuration Management Policies and Procedures In managing hardware and software configurations, BPR and BPRS must establish procedures regarding:
(1) hardware and software installation processes; (2) parameter settings (hardening) of hardware and software; and (3) inventory and updating of information regarding hardware, software, network devices, storage media, and other supporting devices present in the Data Center. Inventories conducted include:
(a) Hardware
Hardware inventory must be comprehensive, including inventory of hardware owned by third parties but located within the BPR or BPRS. Important hardware information to be updated includes the name of the Information Technology service provider, hardware model, purchase and installation dates, processor capacity, main memory, storage capacity, operating system, function, and location. (b) Software BPR and BPRS must conduct inventories of information regarding the name and type of software (operating systems, application systems, or utility systems). Other information that must be included in software inventories includes the name of the creator or Information Technology service provider, installation date, version and release number, software owner, parameter settings and active services, number of licenses owned, number installed, and number of users. (c) Network Devices Network infrastructure is crucial for BPR or BPRS operations, so the work unit or employees responsible for Information Technology management must document network configurations completely. Information in the documentation includes, among others:
i. network diagrams;
ii. identification of all internal and external connections of the BPR or BPRS;
iii. list and capacity of network equipment such as switches, routers, hubs, gateways, firewalls, and others;
iv. identification of Information Technology service providers regarding telecommunications within the BPR or BPRS, between the BPR or BPRS and other parties, and with the internet;
v. plans for network expansion and configuration changes; and
vi. overview of network security systems.
(d) Storage Media
Information required in storage media inventories includes type and capacity, storage location (on-site and off-site), type and classification of stored data, source system, as well as frequency and retention period of backups. (e) Data Center Supporting Devices BPR and BPRS must inventory Data Center supporting devices, including Uninterruptible Power Supply (UPS) and power control, fire detection and extinguishing systems, air conditioning, and temperature and humidity sensors. c) Hardware and Software Maintenance Policies and Procedures (1) Data Center Equipment and Facility Maintenance Periodic preventive maintenance of IT equipment is necessary to minimize equipment operational failures and to detect potential problems early. Therefore, BPR and BPRS need to have maintenance contracts with Information Technology service providers to ensure the availability of maintenance support from the provider. All maintenance should be based on established schedules, documented in a log, and evaluated periodically. (2) Physical Security and Data Center Environmental Controls (a) Data Center Physical Access Control Physical access to the Data Center must be limited and well-controlled. Data Center doors must always be locked; if necessary, they can be equipped with access cards and/or biometric devices. The Data Center room should not be labeled or have signage so that people can easily identify it. BPR and BPRS must have a logbook to record visitors entering the Data Center. (b) Data Center Environmental Controls In implementing Data Center environmental controls, the work unit or employees responsible for Information Technology management must perform at least:
i. supervise and monitor the Data Center environment, including: power sources, fire, water, temperature, and humidity. Applicable environmental controls include: use of UPS, raised floors, temperature and humidity regulation (AC, thermometers, and hygrometers), smoke/fire/heat detectors, fire suppression systems, CCTV (Closed Circuit Television) cameras, and pest control.
ii. ensure the availability of sufficient, stable power sources, and alternative sources to anticipate the failure of the main power source. To anticipate power outages, BPR and BPRS must ensure that voltage regulators, UPS, and generators work properly when needed. BPR and BPRS should preferably use automatic switching methods in case of failure in one power source to maintain power supply according to equipment needs.
iii. ensure the Data Center has fire and smoke detectors and water drainage pipes. Furthermore, BPR and BPRS must provide adequate fire suppression systems, whether automatic or manual. Fire suppression agents and systems used must consider safety for equipment and Data Center personnel.
iv. use raised floors to secure cabling systems and avoid grounding effects in the Data Center.
(c) Hardware and Software Performance
Monitoring of hardware and software must be conducted at least daily to ensure all devices operate properly, for example, servers remain on, Database capacity and server utilities do not exceed limits, and supporting facilities function well. d) Hardware and Software Disposal Policies and Procedures (Disposal) Disposal includes removing software, destroying 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 indications of the date, time, and other information when replaced by the latest source code version. Disposal activities must at least include:

moving data from operational systems to backup media according to procedures, including testing and backup procedures;
storing system documentation in preparation if needed to reinstall a system to operational servers;
managing data archives according to retention periods; and
destroying data whose retention period has expired.

Change Management Policies and Procedures
Change Management is a procedure regulating the addition, replacement, or removal of objects in the production environment. These objects can include data, applications, menus, computer devices, network devices, and processes. BPR and BPRS must have Change Management policies and procedures that at least cover requests, analysis, and approval of changes, as well as change installation, including the transfer of hardware and software from the testing environment to the operational environment. Change Management must consider the following:
a) Change Control
Interdependencies among Electronic Systems used in various work units require integrated Information Technology management. Therefore, all changes must go through a coordinated Change Management oversight function involving representatives from business work units, work units or employees responsible for Information Technology management, information security, and internal audit. Change installation procedures must consider operational continuity in the production environment, oversight, and regulations for securing Information Technology management. Minimum standards regulated must include risks, testing, authorization and approval, implementation time, validation after installation, and recovery. b) Patch Management In Change Management, BPR and BPRS must have complete documentation of patch installations performed. Furthermore, BPR and BPRS must ensure that they use the latest software version that is most appropriate. BPR and BPRS must also have current information regarding product fixes, security issues, patches or upgrades, or other issues relevant to the software version used. c) Data Migration Data migration occurs if there are major changes to the BPR or BPRS Electronic Systems, or if data from several different Electronic Systems is merged. In the event of data migration, BPR and BPRS must have policies and procedures regarding data migration handling. Stages to be undergone in data migration start from strategic planning, project management, Change Management, testing, contingency plans, backups, management of Information Technology service providers or Core Banking Application providers (vendors), and post-implementation review.
Incident/Problem Handling Policies and Procedures
Incident/problem handling procedures must cover hardware, operating systems, application systems, network devices, and security equipment.
BPR and BPRS must maintain necessary facilities to handle issues, including:
a) Help Desk
BPR and BPRS must have a help desk function so that user issues can be addressed immediately.
Matters to be considered in the help desk function are:

Availability of complete issue documentation, which must include user data, problem description, impact on the system (platform, application, or others), priority code, current resolution status, party responsible for resolution, root cause (if identified), target resolution time, and comment fields to record user contacts and other relevant information.
BPR and BPRS need to use a knowledge-based system to support help desk staff with alternative solutions for common issues. BPR and BPRS periodically update this system with information obtained from Information Technology service providers or Core Banking Application providers and from help desk staff experience.
b) Handling Super User Usage
A super user is a user-id with very broad authority. In handling issues, BPR and BPRS must establish super user handling procedures to prevent misuse. These procedures must at least regulate:
designation of parties with super user access rights, including the application of dual custody (splitting passwords among more than one person);
super user password storage procedures;
super user ID break procedures in emergencies;
super user password replacement procedures after use; and
documentation of super user usage in the form of minutes.

Information Exchange Control Policies and Procedures
Sending information online or via storage media must be adequately managed by BPR and BPRS to prevent risks related to information security. BPR and BPRS must have procedures for managing physical and logical information transmission at least:
a. requests and provision of information by internal and external parties; and b. sending information through various media, such as: hardcopy, discs, email, post, and internet.
For large-scale BPR and BPRS with high IT complexity, BPR and BPRS must consider separating WAN (Wide Area Network) and LAN (Local Area Network) segments with security devices (such as firewalls) that limit access and data traffic in and out.
Quality Assurance Function Policies and Procedures
BPR and BPRS should consider having a quality assurance function to understand the BPR or BPRS business processes. The quality assurance function assesses the quality of hardware and software according to established standards. Every system creation and change must go through quality assurance function approval before being transferred (migrated) to the production environment in accordance with Electronic System development guidelines and change management.
Third-Party Service Provider Relationship Management Policies and Procedures
If BPR or BPRS Information Technology management is conducted by an Information Technology service provider, BPR and BPRS must monitor and evaluate the reliability of the provider periodically, including performance, provider reputation, and continuity of service provision. Therefore, BPR and BPRS must have a third-party relationship management function responsible for monitoring Information Technology service provider services using procedures that at least include service monitoring, issue reporting, and documentation related to Information Technology service provider services.

CHAPTER IV
COMMUNICATION NETWORK
Communication networks are a very important aspect for the financial industry. This can be seen from the development of diverse financial institution products and activities through communication networks. Even currently, banking services have become borderless with the development of communication networks. BPRs and BPRSs can provide online and real-time electronic banking services such as Automated Teller Machines (ATM), Internet Banking, and Mobile Banking, whether owned by the BPR or BPRS itself or by Information Technology service providers.

Communication networks are also aspects that need integrity assurance through the implementation of good network management policies and procedures, maximizing network performance, designing networks resistant to disruptions, clearly defining network services, and implementing necessary security measures, as these communication networks are used to transmit information in the form of data, voice, images, and video, which are vulnerable to disruption and misuse.

A. COMMUNICATION NETWORK POLICIES AND PROCEDURES BPRs and BPRSs must have policies and procedures as guidelines in implementing communication network technology to ensure that operational continuity and communication network security remain maintained. Therefore, BPRs and BPRSs must establish baseline/standards used internally for each platform (for example, based on protocols or operating systems) and applied to all communication networks used by the BPR or BPRS.

Policies and procedures that must be established must at least cover the following:

Network performance measurement and capacity planning (performance and capacity planning);
Communication network security (network access controls, including remote access);
Change management (settings, configuration, and testing);
Network management, logging, and monitoring;
Use of the Internet, intranet, email, and wireless (including mechanisms for using communication networks);
Availability of problem resolution procedures (troubleshooting);
Availability of facilities for backup and recovery; and
Adequacy of contracts and availability of SLAs that match the needs of BPRs and BPRSs and must be monitored periodically if the communication network used by the BPR or BPRS is managed by an Information Technology service provider.

B. COMMUNICATION NETWORK DESIGN
Communication networks must be designed to be efficient yet dynamic to anticipate future development. At this stage, several aspects are considered, namely:

Determination of Communication Network Topology
Topology usage is planned according to needs. The types of topologies include:
a. Bus Topology
Bus topology is a topology that uses only one coaxial cable along the client node. Generally, the end of the coaxial cable is usually connected with a T-connector as an end-to-end cable. b. Star Topology Star topology is one form of network topology that uses a switch/hub to connect clients to each other.
c. Ring Topology
Ring topology is one of the topologies that connects one computer to another in a circular arrangement using a LAN card to connect computers to each other. d. Mesh Topology Mesh topology is a form of topology suitable for communication networks connecting many computers. This functions as a backup route when other routes experience problems. e. Peer-to-Peer Topology Peer-to-peer topology is a simple topology because it only uses 2 computers to connect to each other, usually using one cable connecting the computers for data exchange processes. f. Linear Topology Linear topology is usually called serial bus topology. In this topology, usually one main cable is used to connect each connection point on each computer. g. Tree Topology Tree topology is a combined topology of star and bus topologies. This topology is usually used for interconnection between centers with different hierarchies. h. Hybrid Topology Hybrid topology is a combined topology of several different topologies.
Communication network capacity planning.
Communication data network capacity planning is conducted by considering the history of communication network usage and the BPR/BPRS business plan.
Selection of communication network media.
Hardware backup, alternative routing (alternative routes), or alternative providers.
Physical and logical security at least consists of:
a. placement of network devices in locations safe from natural disruptions and unauthorized access; and b. configuration of network device system parameters.
Availability of audit trails, at least regarding changes to device settings and network communication access rights, as well as the use of such access rights.

C. COMMUNICATION NETWORK ACCESS CONTROL
Access control in communication networks must be considered because communication networks are the main gateway into the BPR and BPRS information systems. If not managed well, information security is threatened. In implementing access control, there are several aspects that BPRs and BPRSs must consider, namely:

access to communication networks by users is based on business needs while considering information security aspects;
separating communication networks based on segments, both logically and physically, for example, separation between development and production environments;
in cases where physical separation cannot be performed, BPRs and BPRSs must separate communication networks logically and monitor security access in the communication network;
decisions to connect to communication networks outside the BPR and BPRS must comply with security requirements and be formally approved by the Board of Directors before implementation;
implementing controls that can limit unauthorized or unexpected network traffic;
communication network device configurations must be well managed, including functions or services that are not required must be deactivated;
use of communication network security devices, such as firewalls, Intrusion Detection Systems (IDS), and Intrusion Prevention Systems (IPS);
use of additional communication network monitoring devices (network management systems) while considering their security; and
periodic testing of communication network security, for example, through penetration testing.

D. CONTROL, SECURITY, AND MAINTENANCE OF COMMUNICATION NETWORK OPERATIONS In carrying out control, security, and maintenance of communication network operations, several aspects must be considered, including:

availability of documentation regarding operational network policies and procedures according to user needs;
availability of hardware/software backups, communication network databases, and retention and data management settings, including tested restart/recovery mechanisms;
access to the network is limited only to authorized users through periodic review of "user profiles," including security against the use of every system command (system command), in which case a report must be made by the unit or employee responsible for Information Technology operations regarding every misuse of access;
adequate training for units or employees responsible for Information Technology operations must be conducted to be able to provide support for smooth network operations;
evaluation of operational network implementation to assess compliance with user unit needs and follow-up if improvements are necessary;
the need for a fast and accurate monitoring mechanism to ensure the effectiveness and efficiency of network operations, including process priority, response time, and hardware/software capacity;
availability of a Disaster Recovery Plan procedure, primarily covering backups of hardware/software, databases, and restart/recovery mechanisms, which require periodic testing; and
availability of alternative communication systems to anticipate if existing systems experience disruptions.

E. MONITORING OF COMMUNICATION NETWORKS
In monitoring communication networks used by BPRs and BPRSs, several aspects must be considered, including:

available audit trails must be monitored regularly to detect deviations early;
communication network performance is measured periodically based on availability levels and response time;
BPRs and BPRSs must monitor used and required capacity for business development plans compared to installed capacity;
BPRs and BPRSs must monitor and follow up on intrusions/attacks against communication networks; and
BPRs and BPRSs must periodically review user access grants to ensure that the granted access still matches their duties and authorities, and it is necessary to review users of communication networks in BPRs or BPRSs who have access to communication networks outside the BPR or BPRS.

F. COMMUNICATION NETWORK SOFTWARE
In monitoring and controlling and securing communication network software, BPRs and BPRSs must consider at least:

data transmission, including processes in emergency situations, authorization and audit trails, protection of sensitive data transmission, and access to available utilities; and
maintenance of communication network software.

G. COMMUNICATION NETWORK DATA SECURITY
In securing communication network data, attention must be paid to securing transmitted data using data encryption techniques and securing networks both physically and logically.

H. COMMUNICATION NETWORK DOCUMENTATION
In communication network management activities, BPRs and BPRSs must document the following:

policies, procedures, and baselines/standards regarding communication networks;
detailed communication network diagrams;
lists and specifications of communication network software and hardware;
lists of problems and their handling;
communication network monitoring reports;
communication network capacity planning reports;
contracts and SLAs with third-party communication network facility service providers;
communication network testing documents;
communication network implementation documents;
communication network change documents accompanied by reasons; and
lists of users and their authorities.

CHAPTER V
INFORMATION SECURITY
Information is important for BPRs and BPRSs, whether information related to customers, finances, reports, or other information. Leaks, damage, inaccuracy, unavailability, or other disruptions to such information can cause detrimental impacts, both financial and non-financial, for BPRs or BPRSs, customers, other banks, and the national banking system.

Information must be protected or secured by all personnel in BPRs or BPRSs.

Information security heavily depends on security regarding all aspects and components of related Information Technology, such as software, hardware, networks, supporting equipment (for example, power resources, air conditioning, etc.), and human resources (including qualifications and skills).

A. INFORMATION SECURITY PRINCIPLES
Information security must at least consider the following principles:

implemented to ensure that managed information maintains confidentiality, integrity, availability, and the traceability of electronic and/or electronic documents related to customers and all BPR or BPRS activities effectively and efficiently in accordance with applicable regulations;
considering human resource, process, and technology aspects;
implementing comprehensive and continuous information security by establishing information security objectives and policies, implementing information security controls, monitoring and evaluating the performance and effectiveness of information security policies, and making improvements.

In addition to the above, BPRs and BPRSs need to consider the implementation of international standards in the field of information security, including International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Control Objective For Information and Related Technology (COBIT), Information Technology Infrastructure Library (IT-IL), and national standards such as Indonesian National Standards (SNI), considering the complexity of the business, including diversity in transaction/product/service types and office networks, as well as supporting technology used.

B. INFORMATION SECURITY POLICY
The Board of Directors of BPRs and BPRSs must establish policies and have high commitment to information security. These policies must be communicated periodically to all BPR or BPRS employees and relevant external parties. Furthermore, periodic evaluations and evaluations upon significant changes must be conducted. Information security policies must at least cover:

information security objectives, at least covering asset management, human resources, physical security, logical security, Information Technology operational security, incident handling, information security, and information security in system development;
Board of Directors' commitment to information security in line with business strategies and objectives;
information security principles and standards, including compliance with applicable regulations, training and awareness raising regarding the importance of information security (security awareness program), business continuity plans, and sanctions for violations;
duties and responsibilities of parties in information security; and
documents or other regulations supporting information security policies.

C. INFORMATION SECURITY PROCEDURES

Asset Management
a) BPR and BPRS assets related to information must be identified, owners/responsible parties determined, and recorded to be protected appropriately; b) assets related to information can include data (both hardcopy and softcopy), software, hardware, networks, supporting equipment (for example, power resources, air conditioning), and human resources (including qualifications and skills); c) information must be classified to provide adequate security according to its classification. Examples of such classifications include:

confidential information, for example, customer deposit data, customer personal data;
internal information, for example, regulations regarding BPR or BPRS employee salaries; and
general information, for example, information about BPR or BPRS products offered to the public.
Classifications can be made based on value, sensitivity, legal/regulatory requirements, and importance levels for BPRs or BPRSs.

Human Resource Management
a) human resources, whether BPR or BPRS employees, consultants, honorary employees, and Information Technology service provider employees who have access to information, must understand their responsibilities regarding information security; b) the roles and responsibilities of human resources, whether BPR or BPRS employees, consultants, honorary employees, and Information Technology service provider employees who have access to information, must be defined and documented in accordance with information security policies; c) in cooperation agreements or contracts with BPR or BPRS employees, consultants, honorary employees, and Information Technology service provider employees, provisions regarding information security must be included in accordance with BPR or BPRS information security policies. For example, there must be clauses stating that BPR or BPRS employees, consultants, honorary employees, and Information Technology service provider employees must maintain the confidentiality of information obtained according to information classification; d) in addition to cooperation agreements between BPR or BPRSs and Information Technology service providers, all Information Technology service provider employees assigned to BPR or BPRSs must sign an information confidentiality agreement (non-disclosure agreement); e) training and/or socialization regarding information security must be provided to BPR or BPRS employees, consultants, honorary employees, and Information Technology service provider employees. This training and/or socialization is provided according to the roles and responsibilities of each party; f) BPRs and BPRSs must establish sanctions for violations of information security policies; g) BPRs and BPRSs must establish procedures regulating the requirement to return assets and changes/closure of access rights for BPR or BPRS employees, consultants, honorary employees, and Information Technology service provider employees caused by role changes or completion of employment periods or contracts. h) BPRs and BPRSs must establish segregation of duties and responsibilities, ensuring separation of tasks and responsibilities between human resources in BPR or BPRS operations.
Physical and Environmental Security
a) important information processing facilities (for example, mainframes, servers, computers, active network devices) must also be provided with adequate physical and environmental security to prevent unauthorized access, damage, and other disruptions; b) physical and environmental security for important information processing facilities includes, among others, room barriers, access control (for example, use of access control cards, Personal Identification Numbers/PINs, biometrics), completeness of security equipment inside the room (for example, alarms, fire detectors and extinguishers, temperature and humidity sensors, CCTV), and maintenance of room and equipment cleanliness (for example, from dust, cigarettes, food/drinks, flammable items); c) supporting facilities such as air conditioning, power resources, and fire detectors and extinguishers must ensure capacity and availability to support the operation of information processing facilities; d) assets owned by Information Technology service providers (for example, servers, switching tools) must be clearly identified and provided with adequate protection, for example, by applying sufficient security, dual control, or placing them separately from BPR or BPRS assets; e) periodic maintenance and inspections of information processing facilities and supporting facilities must be conducted according to established procedures.
Logical Security (Logic Security)
a) BPRs and BPRSs must have formal written procedures approved by the Board of Directors regarding user administration, including registration, modification, and deletion of users, for both internal and external users of BPR or BPRS (for example, Information Technology service providers). b) BPRs and BPRSs must establish control procedures through the provision of initial passwords to users, considering at least the following aspects:

initial passwords must be changed upon first login;
initial passwords must be provided securely, for example, through sealed envelopes or double-layered paper;
initial passwords must be unique for each user and not easily guessed;
user-id owners, primarily BPR or BPRS employees, honorary employees, and Information Technology service provider employees, must sign responsibility statements or user-id and password usage agreements upon receiving user-ids and passwords;
standard (default) passwords owned by operating systems, application systems, Database management systems, and network devices must be changed by BPRs or BPRSs before implementation and, as much as possible, standard user-ids from the system (default user-ids) must be changed.
c) BPRs and BPRSs must require users to:
maintain password confidentiality;
avoid writing passwords on paper and other places without adequate security;
choose quality passwords, namely:
(a) adequate password length so that it is not easily guessed; (b) easy to remember and consisting of at least a combination of 2 character types (letters, numbers, or special characters); (c) not based on personal user data such as names, phone numbers, or birth dates; (d) not using common and easily guessed words by software (to avoid brute force attacks), for example, words like 'pass', 'password', 'adm', or common dictionary words;
change passwords periodically; and
avoid using the same passwords repeatedly.
d) BPRs and BPRSs must deactivate access rights if user-ids are not used for a certain period, establish the maximum number of failed password attempts (failed login attempt), and deactivate passwords after reaching the maximum number of failed password attempts. e) BPRs and BPRSs must conduct periodic reviews/audits of user access rights to ensure that the granted access rights match the granted authorities. f) operating systems, application systems, databases, utilities, and other devices owned by BPRs and BPRSs should, as much as possible, assist in password security implementation, for example:
forcing users to change passwords after a certain period and rejecting if users enter the same password as previously used when changing passwords;
storing passwords securely (encrypted);
disconnecting or terminating user access if there is no response for a certain period (session time-out);
deactivating or deleting user access rights if users do not log in for a certain period (expiration interval), for example, due to leave or department transfers.
g) BPRs and BPRSs must consider risks and apply adequate security controls in the use of mobile computing devices and data storage media such as notebooks, hand phones, flash disks, external hard disks, and other media, including when using wireless access or wireless networks. h) BPRs and BPRSs must consider risks and apply adequate security controls against access points (access points) into computer networks and/or information processing facilities that can be utilized by unauthorized parties.

i) BPR and BPRS using file sharing must establish access restrictions at minimum through the use of passwords and access authorization settings.

j) BPR and BPRS must pay attention to security hardening processes for hardware and software, such as parameter settings or patches.

Information Technology Operational Security

Matters to be considered in the operational security of Information Technology include:

a) information and software must have tested backup and recovery procedures according to their level of importance;

b) BPR and BPRS must anticipate and implement adequate security controls over vulnerabilities in operating systems, application systems, Databases, and networks, including threats from unauthorized parties such as viruses, trojan horses, worms, spyware, Denial-of-Service (DoS), war driving, spoofing, and logic bombs;

c) BPR and BPRS must have policies and procedures for updating anti-virus software and patches and ensure their implementation;

d) BPR and BPRS must create procedures covering the identification of existing patches, testing, and installation if necessary;

e) BPR and BPRS must maintain records of the software versions used and routinely monitor information regarding product updates (enhancements), security issues, patches or upgrades, or other issues relevant to the software versions used;

f) BPR and BPRS must establish the use of encryption using specific cryptographic techniques to secure the transmission of sensitive information, especially through networks outside the BPR or BPRS communication network, in accordance with the latest technological developments. The use of such cryptographic techniques aims to maintain and ensure confidentiality, integrity, authenticity, and non-repudiation. Techniques that may be considered include encryption, hash functions, and digital signatures (using Public Key Infrastructure);

g) BPR and BPRS must apply identification and authentication methods according to the importance level of the application, for example, using one-factor authentication for "ordinary" applications and two-factor authentication for "critical" applications. Examples of identification and authentication methods include login ID and password, token devices, or biometrics (e.g., fingerprint, retina scan, face/iris/hand/palm analysis, signature recognition, voice recognition); and

h) BPR and BPRS must provide and review audit trails/logs at the network, system, and application levels, and establish the type of log (e.g., administrator log, user log, system log), information to be included in the log, storage duration or log capacity, considering applicable regulations for issue tracing purposes.

Incident Handling in Information Security

Matters to be considered by BPR and BPRS in handling incidents in information security include:

a) incidents that occur must be identified, reported, followed up, documented, and evaluated to ensure proper handling and to prevent the recurrence of incidents;

b) BPR and BPRS must establish incident handling procedures that regulate, among others:

who must report the incident;
types of incidents that must be reported;
incident reporting flow (point of contact);
analysis of the incident to prevent recurrence; and
documentation of evidence related to the incident and its follow-up.

c) BPR and BPRS should consider forming a special team to handle security incidents by TRIPI (Information Security Incident Response Team) according to the business scale and complexity of the Information Technology management of the BPR or BPRS;

d) BPR or BPRS employees, honorary employees, and IT service provider employees are requested to report whenever they find indications or potential weaknesses in the Electronic System in accordance with the security incident reporting policy and procedures. Weaknesses that need to be reported include, for example, viruses from incoming emails.

Backup and Restore Testing

Backup and restore testing are necessary to ensure data availability for the operational continuity of BPR or BPRS, both in routine operations and in the event of data damage or failure, so that greater losses can be avoided. In this regard, the aforementioned backup and restore testing include data, files, applications, operating systems, and other documents, which must be stored in a separate location/building. The above are some examples of controls and technologies that can be used to assist information security.

Data Retention

Data retention is conducted to maintain the integrity of backed-up data for a certain period. The data retention period is adjusted according to regulations governing corporate documents.

Others

Information security must also be applied in other aspects such as the development and procurement of Electronic Systems, including Core Banking Applications, data communication networks, disaster recovery plans, and cooperation activities with IT service providers or Core Banking Application providers.

CHAPTER VI
DISASTER RECOVERY PLAN

Banking activities cannot be avoided from disturbances/damages caused by nature or humans, such as earthquakes, bombs, fires, floods, power failures, technical errors, human negligence, labor strikes, riots, and so on. The resulting damage not only affects the technological capability of a BPR or BPRS but also impacts the operational business activities of the BPR or BPRS, particularly services to customers. If not handled specifically, besides facing operational risks, BPR and BPRS may also face reputational risks, leading to a decline in customer trust in the BPR or BPRS.

To minimize these risks, BPR and BPRS are expected to have Business Continuity Management (BCM), which is an integrated and comprehensive management process to ensure that BPR or BPRS operational activities continue to function even when facing disturbances/disasters, in order to protect the interests of stakeholders. Effective BCM needs to be supported by several things, one of which is the preparation of a Business Continuity Plan (BCP).

The mandatory BCP procedure components owned by BPR and BPRS are the Disaster Recovery Plan (DRP) in accordance with POJK SPTI. The Disaster Recovery Plan is a document containing plans and steps to restore access to data, hardware, and software required, so that BPR and BPRS can carry out critical business operational activities after a disturbance and/or disaster. The Disaster Recovery Plan emphasizes technological aspects, focusing on data recovery/restoration plans and the functioning of critical Information Technology application systems and infrastructure.

A. DISASTER RECOVERY PLAN POLICY AND PROCEDURES

The Board of Directors of BPR and BPRS must establish policies and have a high commitment to disaster recovery plans that include:

Analysis of the Disaster Recovery Plan

Analysis of the possibility of risks arising from factors such as:
a) fire factors; b) natural factors, such as floods and earthquakes; c) technical factors, such as hardware/software damage, power outages, or data transmission disturbances; and/or d) human factors, such as sabotage.

Types of Disaster Recovery Plan Procedures

The types of procedures in the Disaster Recovery Plan include:
a) emergency response procedures (immediate steps) to control the system during a disturbance/disaster, reduce the impact of losses, and determine the disaster status; b) system recovery procedures that allow BPR or BPRS operational activities to return to normal conditions; and/or c) data synchronization procedures are used to ensure consistency between the operational machine data and backup data, as well as to ensure all business processing data during the recovery period has entered the system.

Disaster Recovery Plan Procedure Components

Each Disaster Recovery Plan procedure must include at least the following components:
a) Personnel
The Disaster Recovery Plan must clearly state the composition, authority, and responsibilities of each personnel involved in Information Technology management and have adequate communication flows.

b) Technology and Core Applications
The procedures prepared must consider the technology components owned by BPR or BPRS, such as hardware, software, and BPR or BPRS communication facilities.
Furthermore, BPR and BPRS must have complete procedures and documentation to recover main applications related to Core Banking Applications or other BPR or BPRS operations.
Additionally, matters related to data need attention, such as system documentation and backup data.

c) Disaster Recovery Center (DRC)
For BPR and BPRS that have a Disaster Recovery Center, BPR and BPRS must ensure the availability of the Disaster Recovery Center as a backup Data Center that can be operated when the Data Center cannot operate (in disaster conditions). According to the selected strategy alternative, the BPR or BPRS Disaster Recovery Center can be managed independently or by an IT service provider, considering the following:
(1) The Disaster Recovery Center should be located in a separate location from the Data Center location, considering risk characteristics based on:
(a) risk analysis related to the Disaster Recovery Center location (whether the area is prone to earthquakes, lightning, floods, riots, unrest, and other disturbances) and connected to communication infrastructure and electricity different from the Data Center, as well as other facilities necessary for the system to continue operating; and (b) the geographical scope of a disturbance/disaster and its impact on the city or region where the Disaster Recovery Center location is located. (2) The Disaster Recovery Center must have electricity supply and telecommunications facilities that ensure the operation of the Disaster Recovery Center; (3) systems in the Disaster Recovery Center must be compatible with systems used in the Data Center and must be adjusted if changes occur in the Data Center; (4) it is a restricted area; and (5) it considers travel time to ensure the recovery process.

d) Backup Documentation, Systems, and Data
BPR and BPRS must ensure the availability of effective backups of important business information, software, and related system documentation, and users for each critical business function process. Matters to be considered in documentation, system, and data backups include:

backups must be stored in a separate location from the Data Center (off-site) meeting adequate security system standards, and every change and modification must be documented and copies must also be updated;
full system backups must be performed periodically or if there are fundamental system changes, backups must be performed as soon as possible;
all backup media use standard naming to identify usage, date, and retention schedule;
backup media must undergo periodic restore testing to ensure backups can be used when needed (emergency situations); and
BPR and BPRS must have procedures for the disposal of backup media.

e) Communication Facilities
BPR and BPRS must ensure the availability of alternative communication routes in the BPR or BPRS operational area that can be used internally or with external parties during disturbances/disasters.

Determination of Clear Responsibilities for Related Parties in Disaster Recovery Plan Management.

a) Responsibilities of the Board of Directors of BPR and BPRS include at least:
1. establishing written policies and procedures regarding the Disaster Recovery Plan;
2. reviewing and approving the Disaster Recovery Plan;
3. evaluating the feasibility of the Disaster Recovery Plan owned by IT service providers in case BPR or BPRS cooperates with IT service providers; and
4. determining the level of disturbance and disaster and its recovery.
b) Responsibilities of the work unit or employees responsible for Information Technology management include at least:
1. full responsibility for the effectiveness of Disaster Recovery Plan management, including ensuring that every party in BPR or BPRS is aware of the implementation of the Disaster Recovery Plan;
2. determining the recovery scenarios to be used in the event of disturbances or disasters based on prioritization of Electronic Systems considered critical; and
3. evaluating reports on each stage of testing and implementation of the Disaster Recovery Plan.

B. DOCUMENTATION OF STRATEGIES AND PROCEDURES FOR RECOVERY

BPR and BPRS must document strategies and procedures for the recovery process, including:

procedures for implementing the Disaster Recovery Plan;
processing priorities;
required resources (including hardware/software and server locations); and
data.

C. DISASTER RECOVERY PLAN TESTING

Disaster Recovery Plan testing is necessary to ensure that the Disaster Recovery Plan can operate well during disturbances/disasters. BPR and BPRS conduct testing of the Disaster Recovery Plan at least 1 (one) time in 3 (three) years. Testing is conducted on all critical systems/applications and critical infrastructure and involves IT users.

Critical systems/applications and infrastructure refer to systems/applications and infrastructure that can disrupt bank operational services, thereby potentially causing reputational risk.

BPR and BPRS review the Disaster Recovery Plan periodically at least 1 (one) time in 3 (three) years, considering the results of testing, including in cases where BPR and BPRS make significant changes to systems, applications, or Information Technology infrastructure, such as changes to Core Banking Applications.

If BPR and BPRS use IT service providers in operational activities, the testing conducted must also involve the respective service providers.

Scope of Testing

BPR and BPRS must clearly determine the functions, systems, and processes to be tested. Matters to be tested include the effectiveness of:
a) procedures for determining the level of disturbance and disaster; b) Disaster Recovery Center facilities provided by IT service providers, whether used for BPR and BPRS themselves or shared with other BPR and BPRS; c) Information Technology operational recovery procedures; and d) Data Center recovery.

The testing conducted must be documented orderly and evaluated to ensure the effectiveness and success of the testing. In case weaknesses in the Disaster Recovery Plan are found during testing, the Disaster Recovery Plan needs to be improved.

Testing Scenarios

BPR and BPRS must have comprehensive testing scenarios covering all possible conditions for each testing to be conducted. The implementation of these scenarios must not disrupt the operational activities of BPR or BPRS. The implementation of testing scenarios is expected to detect weaknesses in existing procedures to improve the Disaster Recovery Plan.

Analysis and Testing Results Report

The results of testing and analysis of each problem found during testing must be reported to the Board of Directors. Reported matters include at least:
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 comparison between the results of the Disaster Recovery Plan and the systems used, testing results, and proposed changes if there are differences; and e) recommendations for subsequent testing.

In case failure is found based on testing results, BPR and BPRS must examine the causes of failure or problems that occurred and conduct re-testing.

D. DISASTER RECOVERY PLAN MAINTENANCE

BPR and BPRS must ensure that the Disaster Recovery Plan can be executed at all times, among others, by increasing understanding across all organizational levels in BPR or BPRS or in IT service providers regarding the importance of the Disaster Recovery Plan and actively participating in the implementation of the Disaster Recovery Plan, particularly work units or employees responsible for Information Technology management.

BPR and BPRS must update the Disaster Recovery Plan to ensure its relevance to current conditions. In updating, matters to be considered include changes in systems, software, operating systems, hardware, related parties (counterparties), and service providers. These changes must be analyzed for their impact on the existing Disaster Recovery Plan and determine necessary improvements to accommodate these changes. Subsequently, the updated Disaster Recovery Plan must be documented and distributed to all organizational levels of BPR or BPRS.

CHAPTER VII
INFORMATION TECHNOLOGY INTERNAL AUDIT

An effective internal control system is an important component in the management of BPR and BPRS and serves as the basis for healthy and safe operational activities of BPR and BPRS. An effective internal control system can help BPR or BPRS in preserving assets, ensuring the availability of reliable financial and managerial reporting, increasing BPR or BPRS compliance with laws and regulations, and reducing the risk of losses, deviations, and violations of prudence aspects.

The use of Information Technology facilities, in addition to increasing the ability of BPR and BPRS to carry out operational activities, also contains risks that can result in losses, both financial and non-financial. Therefore, internal control systems need to be implemented as one of the efforts to minimize such losses.

The internal audit function is one part of the internal control system. The implementation of the internal audit function is carried out to evaluate the management of Information Technology independently and objectively to improve efficiency and effectiveness, internal controls, and good governance.

A. ORGANIZATION IMPLEMENTING THE INTERNAL AUDIT FUNCTION FOR INFORMATION TECHNOLOGY MANAGEMENT

The internal audit function regarding Information Technology management must be implemented as follows:

for BPR, the internal audit function regarding Information Technology management is conducted:
a) as part of the BPR internal audit in accordance with Financial Services Authority Regulations governing the application of governance for BPR; or b) separately from the BPR internal audit implementation in case the Information Technology management audit is conducted by external auditors;
for BPRS, the internal audit function regarding Information Technology management continues to refer to regulations governing the application of BPRS governance and other relevant laws and regulations. The implementation of the internal audit function regarding Information Technology management can be carried out by the BPRS itself or using external auditor services;

The implementation of the internal audit function is carried out by the Internal Audit Work Unit or Executive Officials responsible for implementing the internal audit function, referred to as the organization implementing the internal audit function for Information Technology management.

B. GUIDELINES FOR INTERNAL AUDIT OF INFORMATION TECHNOLOGY MANAGEMENT

General Audit Policy

The internal audit guidelines for Information Technology management include at least general policies regarding:
a) statement of vision and mission of the Information Technology management internal audit function; b) organizational structure and reporting system; c) determination of audit frequency and schedule, which BPR or BPRS will apply at least 1 (one) time in 1 (one) year as part of internal audit implementation or implemented separately from internal audit; and d) internal audit implementation is conducted on Information Technology-related aspects according to needs, priorities, and Information Technology risk analysis results, at least covering the following aspects:

Core Banking Applications, to ensure that Core Banking Applications meet the following minimum standards:
(a) applying laws and regulations for BPR or BPRS; (b) performing inter-branch transaction bookkeeping:
(1) on the same day for BPR and BPRS that do not provide electronic banking services and do not conduct activities as Automated Teller Machine (ATM) card issuers; (2) online and real-time for BPR and BPRS that provide electronic banking services and/or conduct activities as Automated Teller Machine (ATM) card issuers. Electronic banking services as referred to in numbers (1) and (2) also include debit card issuer activities as referred to in Financial Services Authority Regulations governing business activities and office network areas for BPR based on core capital for BPR and Financial Services Authority Regulations governing Sharia Rural Financing Institutions for BPRS. (c) generating data and information used to support the preparation of reports for internal and external needs; (d) consolidating functions within Core Banking Applications to support the provision of complete, accurate, current, and complete data and information; and (e) able to implement customer profiles in an integrated manner (Single Customer Identification File).
authority and responsibilities of the Board of Directors, Board of Commissioners, and work units or employees responsible for Information Technology management, to ensure the implementation of authority and responsibilities of the Board of Directors, Board of Commissioners, and work units or employees responsible for Information Technology management.

Information Technology as referred to in Chapter I. e) In addition to the aspects in letters d. numbers 1) and 2), BPR and BPRS may conduct audits on the following aspects of Information Technology management:
(a) development and procurement of Information Technology, to ensure that the development and procurement of Information Technology have met the minimum standards as referred to in POJK SPTI; (b) Information Technology operations, to ensure the implementation of Information Technology management is consistent with policies and procedures; (c) communication networks, to ensure that the management of communication networks is consistent with policies and procedures; (d) information security, to ensure the fulfillment of physical and logical security in the management of Information Technology; (e) disaster recovery plans, to ensure that disaster recovery plans can be executed at all times; and (f) the functionality of all Information Technology devices used, to ensure the fulfillment of confidentiality, integrity, and availability elements in the operations of BPR or BPRS. f) internal audit procedures for the management of Information Technology for each Information Technology activity in the management of Information Technology that requires an audit.

Audit Planning
The organ implementing the internal audit function for the management of Information Technology must have an annual audit plan regarding the management of Information Technology, both for Information Technology work units and for work units responsible for the management of Information Technology. In performing the internal audit function to assess the management of Information Technology, the organ implementing the internal audit function must at least do the following:
(a) identify data, applications and operating systems, technology, facilities, and personnel; and (b) identify activities and business processes that use Information Technology.
The internal audit plan for the management of Information Technology must receive approval from the Board of Directors.
Audit Execution
In order to implement the annual audit plan, the audit program (audit working plan, hereinafter referred to as “AWP”) is prepared for each audit assignment, which must at least cover:
(a) the organization, authority, and responsibilities of the auditors; (b) the scope of the audit according to the risk assessment results; (c) audit objectives, schedules, number of auditors, budgets, and reporting; and (d) technical audit steps necessary to achieve audit objectives. In its implementation, internal audits of the management of Information Technology must consider aspects of confidentiality regarding data and information obtained. The organ implementing the internal audit function for the management of Information Technology must consider the flexibility of the AWP so that it can be adjusted and completed according to identified risks. In the execution of audits, it is accompanied by working papers, the content and format of audit result reports, documentation and distribution, and the monitoring of follow-up actions. Audit findings must be accompanied by evidence and well-documented audit working papers.
Reporting
The report on the implementation of the internal audit function for the management of Information Technology serves as a tool for the Board of Directors to assist in assessing the quality and performance of work units or employees responsible for the management of Information Technology, as well as providing improvement suggestions. The report is submitted promptly to the President Director and Board of Commissioners, with copies sent to Board of Directors members who oversee the compliance function and the audited work unit. Reports on the implementation of the internal audit function for the management of Information Technology are also submitted to the Financial Services Authority (OJK) as part of the implementation report and key points of internal audit results, or submitted separately in accordance with OJK regulations and provisions.
Audit Follow-up
The auditee must respond to the audit results. If findings require follow-up, the auditee must provide commitments and target completion times. Subsequently, the organ implementing the internal audit function for the management of Information Technology must periodically monitor the implementation of the auditee's commitments regarding audit results and verify the improvements made. The organ implementing the internal audit function for the management of Information Technology must maintain documentation of the results of such follow-up. Follow-up reports on audit results are submitted to the President Director and Board of Commissioners, with copies sent to Board of Directors members who oversee the compliance function.
Development and Testing of Electronic Systems
The organ implementing the internal audit function for the management of Information Technology needs to play a role in the development of Electronic Systems to ensure that Electronic Systems are in accordance with the needs of BPR or BPRS and applicable regulations, have adequate controls, and have means for traceability (audit trails), but cannot act as the determiner of the implementation of Electronic Systems, but rather participate as a resource person in control aspects, particularly regarding required security standards. This role is necessary so that auditors can maintain independence and objectivity in audits conducted when Electronic Systems are implemented. In addition, the organ implementing the internal audit function for the management of Information Technology may provide recommendations to the President Director or other Board of Directors members regarding controls that need to be implemented.

C. IMPLEMENTATION OF INTERNAL AUDIT FUNCTIONS FOR THE MANAGEMENT OF INFORMATION TECHNOLOGY CARRIED OUT BY EXTERNAL AUDITORS
In the event of limitations in the capacity of the internal audit function for Information Technology at BPR or BPRS, the implementation of internal audit functions may be carried out by external auditors such as Public Accountant Offices or Independent Information Technology Audit Institutions. The use of external auditor services to perform internal audit functions for the management of Information Technology at BPR or BPRS does not reduce the responsibility of the organ implementing the internal audit function for the management of Information Technology for audit findings and follow-up. The use of external auditor services must consider the size and complexity of the business of BPR or BPRS. The implementation of internal audit functions for the management of Information Technology by external auditors still considers competency aspects, including adequate knowledge and experience, independence, and is based on a cooperation agreement. Although the implementation of internal audit functions is carried out by external auditors, audit procedures for the management of Information Technology must still refer to the internal audit policies and procedures for the management of Information Technology owned by BPR or BPRS.

D. INTERNAL AUDIT OF ACTIVITIES CARRIED OUT BY INFORMATION TECHNOLOGY SERVICE PROVIDERS The party implementing the internal audit function of BPR and BPRS must ensure the controls operated by Information Technology service providers and test the effectiveness of those controls. BPR and BPRS must ensure that agreements with Information Technology service provider parties include clauses providing access rights, both logically and physically, for:

internal auditors of BPR and BPRS;
external auditors appointed by BPR and BPRS; and
the Financial Services Authority (OJK),
to obtain necessary data and information promptly whenever needed, and to state non-objection in the event that the Financial Services Authority (OJK) and/or other competent parties according to applicable laws and regulations conduct examinations of the service provision activities provided.

CHAPTER VIII
COOPERATION WITH INFORMATION TECHNOLOGY SERVICE PROVIDERS In order to increase effectiveness and efficiency to achieve strategic objectives, BPR and BPRS may cooperate with Information Technology service providers. Such cooperation causes BPR and BPRS to have dependence on the services provided continuously and/or for a certain period. Cooperation with Information Technology service providers can affect the risks of BPR and BPRS, including operational, compliance, and reputational risks. These risks can be caused, among others, by the failure of Information Technology service providers to provide services, violations of security, or the inability to comply with laws and regulations. BPR and BPRS remain responsible for the management of Information Technology carried out in cooperation with Information Technology service providers.

A. INFORMATION TECHNOLOGY SERVICE PROVIDER SELECTION PROCESS

Needs Determination
In the event that BPR and BPRS will cooperate with Information Technology service providers, BPR and BPRS need to determine needs by considering at least:
a) the results of identifying specific functions or activities whose management will be carried out by Information Technology service providers; and b) the results of assessments of risks that may arise from the cooperation to be implemented, The stage of needs determination must result in a document containing detailed information regarding the needs of BPR or BPRS for the services to be provided by Information Technology service providers. The content of such documents must at least cover:
a) the scope and characteristics of services, technology used, and support for customers; b) standards and service levels including availability and performance, change management, service quality, security, and business continuity; c) minimum characteristics that must be met by Information Technology service providers to be used, such as experience, process control, financial conditions, and references regarding reputation; d) technical monitoring carried out by BPR or BPRS and reporting criteria carried out by Information Technology service providers; e) requirements to be met, including regarding systems, data, and personnel training, when BPR or BPRS undergoes transition or migration to systems provided by Information Technology service providers; f) the duration of the cooperation agreement, termination, and minimum scope of the cooperation agreement; and g) protection of cooperation agreements such as limitation of liability, compensation, and insurance. In the event that the management of Information Technology is considered to be carried out by related parties to BPR or BPRS, the Board of Directors of BPR or BPRS must ensure that the preparation and implementation process carried out is not different in the event that the management of Information Technology is carried out by unrelated parties to BPR or BPRS (arm’s length principle).
Cost-Benefit Analysis
After determining the needs for cooperation to be carried out by BPR or BPRS with Information Technology service providers, BPR and BPRS must conduct an analysis of direct and indirect costs in written offers by Information Technology service providers with specifications in accordance with needs, types of services, matters necessary in determining cost-effectiveness, completion timeframes, security, and business continuity, SLA, and solutions to problems faced. When BPR and BPRS conduct an analysis of written offers submitted, there is a possibility of finding inconsistencies with the needs of BPR or BPRS. Therefore, BPR and BPRS must evaluate such differences and their impact on the objectives and services expected by BPR or BPRS. In order to optimize the cost-benefit analysis process, in addition to using own estimates (owners estimate), BPR and BPRS may compare the cost-benefit offered between Information Technology service providers. Subsequently, if the written offer meets the needs or conforms to the specification needs created by BPR or BPRS, BPR and BPRS need to negotiate with Information Technology service providers before creating a cooperation agreement.
Due Diligence on Information Technology Service Providers
Due diligence on Information Technology service providers is conducted in order to obtain assurance that Information Technology service providers are able to meet the needs of BPR or BPRS. To obtain such assurance, BPR and BPRS may conduct evaluations and assess information related to Information Technology service providers, including:
a) the existence and history of Information Technology service providers; b) the qualifications, background, and reputation of the owners of Information Technology service providers; c) other companies using the same services from Information Technology service providers as references; d) financial conditions, including examinations of audited financial reports; e) the ability and effectiveness of service provision, including after-sales support; f) technology and system architecture; g) internal control environment, security history, and audit scope; h) compliance with laws and regulations; i) trust and success in maintaining relationships with subcontractors; j) insurance and maintenance guarantees; k) the ability to provide disaster recovery and business continuity; l) the application of risk management; and/or m) reports on the results of independent audits. Due diligence on Information Technology service providers conducted by BPR or BPRS during the selection process must be well documented and conducted periodically as part of the monitoring and control process. In conducting periodic due diligence on Information Technology service providers, BPR and BPRS should pay attention to changes or developments that have occurred during the period since the last due diligence using the most recent information.
Determination of Information Technology Service Providers
In determining Information Technology service providers selected for use by BPR or BPRS in managing Information Technology, BPR and BPRS must consider the following:
a) previous reports made that reflect the performance of Information Technology service providers previously, which are necessary to assess the performance of Information Technology service providers adequately; b) the ability to provide reports reflecting the performance of Information Technology service providers necessary to monitor that the performance of Information Technology service providers is adequate; c) the results of analyses of cost-benefit for each choice of Information Technology service providers to be selected and analyses of the fulfillment of service usage timeframes in accordance with the business plans of BPR or BPRS; d) the application of adequate Information Technology control principles, evidenced by audit results conducted by independent parties on Information Technology service providers, including logical and physical security; e) information from various sources, including annual reports of Information Technology service providers, in order to evaluate the reliability, performance, reputation, and continuity of service provision by Information Technology service providers; f) the availability of access to Databases for the Financial Services Authority (OJK), internal auditors, external auditors appointed by BPR and BPRS, and other competent parties according to laws and regulations, in the event that current or past data is required; g) selection documents containing considerations regarding the application of the “arm's length principle”, in the event that Information Technology service providers are related parties to BPR or BPRS.

B. COOPERATION AGREEMENTS WITH INFORMATION TECHNOLOGY SERVICE PROVIDERS Cooperation agreements for the management of Information Technology with Information Technology service providers must at least cover:

scope of work/services;
costs and the duration of the cooperation agreement;
risk limits borne by BPR or BPRS and Information Technology service providers resulting from changes, including:
a) the scope of the cooperation agreement; b) the scope of business and the organization of Information Technology service provider companies; and c) legal aspects, including regulations, copyrights, patents, and trademarks;
prohibitions for Information Technology service providers to use or disclose information owned by BPR and BPRS without the approval of BPR or BPRS;
guarantees from Information Technology service providers for security and confidentiality of data, especially bank secrets and customer personal data, including that Electronic Systems can only be accessed by data owners (BPR and BPRS) and that such Electronic Systems do not contain back doors allowing access by unauthorized parties to the Electronic Systems and data of BPR or BPRS;
statements that Information Technology service providers guarantee the reliability of Electronic Systems, including not using Electronic System features that may cause the Electronic Systems to function poorly;
standard specifications and performance of Electronic Systems, at least covering:
a) the expected performance and functionality of Electronic Systems; b) the requirements and infrastructure necessary to operate Electronic Systems; c) the identification of testing needs to determine the fulfillment of Electronic System performance standards; and d) actions that Information Technology service providers must take if Electronic Systems fail during testing.
the willingness of Information Technology service providers to provide technical documents to BPR or BPRS regarding the services performed by Information Technology service providers, including Information Technology process flows, implementation manuals (manual books), Database structures, and online help applications in Electronic Systems that operate interactively;
guarantees of access to source code in the event that:
a) Information Technology service providers can no longer provide services; b) modifications are required that cannot be performed by Information Technology service providers; and/or c) software is deemed important for the operational continuity of BPR or BPRS.
the willingness of Information Technology service providers to assist in the software conversion process, including data and data formats, when system replacement is required in the future;
Information Technology service providers provide guarantees at least that Electronic Systems:
a) do not violate the intellectual property rights of third parties; b) do not contain secret codes or automatic restrictions not disclosed in the agreement; c) work according to specifications and Information Technology service providers are responsible in the event of problems; and d) are guaranteed to be maintained by Information Technology service providers for the duration of the agreement.
SLAs containing performance standards of Information Technology service providers, including regarding agreed service levels and performance targets;
clauses that SLAs remain valid in the event of changes in ownership, both at BPR or BPRS and Information Technology service providers;
reports on the monitoring results of the performance of Information Technology service providers related to SLAs;
Information Technology service providers cannot modify Electronic Systems that have been agreed upon in the agreement without the approval of both parties;
the obligation of Information Technology service providers to report every critical event, abuse, and/or crime in the management of Information Technology that can or has resulted in significant financial losses and/or disrupted the operational continuity of BPR or BPRS;
the requirement for Information Technology service providers to conduct knowledge transfer to BPR or BPRS by planning training for BPR or BPRS human resources, including regarding the number of human resources trained, the form of training, and the costs required, with the aim that BPR or BPRS human resources understand the Information Technology used, especially the Information Technology process flows and Database structures of Electronic Systems provided by such Information Technology service providers;
sanctions and/or penalties for cancellation and/or violations of cooperation agreements;
compliance with laws and regulations, including dispute resolution in the event of disagreements;
guarantees that Information Technology service providers apply adequate Information Technology control principles, evidenced by audit results by independent parties;
the continuous responsibility of Information Technology service providers to maintain the security and confidentiality of BPR or BPRS data/information;
ownership and copyrights (licenses);
guarantees that Information Technology service providers continue to support services provided to BPR or BPRS for a certain period after implementation;
prohibitions on transferring (subcontracting) part or all of the management of Information Technology activities of BPR or BPRS to other Information Technology service providers;
the availability of online communication facilities, security for access and data transmission to and from Data Centers and Disaster Recovery Centers, and the management of other Information Technology in accordance with laws and regulations;
clear arrangements regarding backups, contingency, record protection, including hardware, software, and data files, to ensure the continuity of Information Technology management;
arrangements regarding security in the transmission of documents required to and from Data Centers and Disaster Recovery Centers, and other Information Technology management in accordance with laws and regulations;
statements of non-objection in the event that the Financial Services Authority (OJK) or other competent parties according to laws and regulations conduct examinations of the service provision activities provided;
the availability of data and information for examination purposes as referred to in number 28, including access rights, both logically and physically, to Electronic Systems that

managed, including data managed by Information Technology service providers;
30. the responsibility of Information Technology service providers to provide experts supported by expertise certificates according to the needs of Information Technology management;
31. the possibility of terminating, changing, making new agreements, or taking over activities managed by Information Technology service providers, and terminating agreements before the agreement period expires, including at the request of the Financial Services Authority; and
32. the obligation of Information Technology service providers to provide tested and adequate Disaster Recovery Plans.

C. FOLLOW-UP ON THE IMPLEMENTATION OF COOPERATION AGREEMENTS WITH INFORMATION TECHNOLOGY SERVICE PROVIDERS

Risk Anticipation
In the event that cooperation with Information Technology service providers has been implemented, BPRs and BPRSs must anticipate risks from the management of Information Technology entrusted to Information Technology service providers. In order to anticipate these risks, BPRs and BPRSs conduct monitoring to detect early if there are conditions as follows:
a) deterioration of the performance of BPR and BPRS Information Technology management caused by Information Technology service providers, which can have a significant impact on the business activities of BPRs or BPRSs; b) Information Technology service providers experiencing financial difficulties leading to insolvency, entering the process towards liquidation, or declared bankrupt based on a court decision; c) violations by Information Technology service providers regarding the obligation to maintain data and information security, including bank secrets and customer personal data; and/or d) conditions causing BPRs or BPRSs to be unable to provide data and information required for supervision by the Financial Services Authority.
Risk Follow-up
In the event that BPRs and BPRSs find conditions as referred to in item 1 above, BPRs and BPRSs are required to take specific actions at least:
a) report to the Financial Services Authority no later than 3 (three) working days from the date the above conditions were known by the BPR or BPRS; b) decide on the follow-up actions to be taken to address the problems, including terminating cooperation with Information Technology service providers if necessary; and c) report to the Financial Services Authority regarding the follow-up decisions that have been and/or will be taken, no later than 10 (ten) working days from the date of the report on the conditions as referred to in letter a).
Contingency Plan
In the event that cooperation is terminated as referred to in item 2 letter b) or upon the order of the Financial Services Authority before the end of the cooperation agreement period, BPRs and BPRSs must have a contingency plan to maintain the continuity of the business of BPRs or BPRSs.
Disaster Recovery Plan
BPRs and BPRSs must ensure that dependence on Information Technology service providers can be mitigated so that BPRs and BPRSs remain able to manage Information Technology in the event of a disaster, by:
a) ensuring that Information Technology service providers have Disaster Recovery Plans according to the type, scope, and complexity of the Information Technology activities/services provided; and b) actively obtaining guarantees of readiness of the Information Technology service provider's Disaster Recovery Plan, such as periodic testing of the Disaster Recovery Plan.
Guarantee of Continuity of Information Technology Management
In order to maintain the continuity of Information Technology management, BPRs and BPRSs need to mitigate dependence on Information Technology service providers, including:
a) ensuring the availability of source code by Information Technology service providers when needed, by:

handing over the source code to the BPR or BPRS; or
in the event that the Information Technology service provider does not hand over the source code to the BPR or BPRS, the Information Technology service provider places the source code with a trusted third party that can guarantee the handover of the source code to the BPR or BPRS.
b) Information Technology service providers must provide guarantees to BPRs and BPRSs that the continuity of the application is supported by the principal software developer, in the event that the source code is not owned by the Information Technology service provider;

Glossary

Access:
activities involving interaction with Standalone Electronic Systems or within a network
Administrator Log:
files on a computer that store information regarding administrator activities.
Arm’s Length Principle:
a fair and mutually beneficial cooperation principle where each party entering into a cooperation agreement has equal bargaining power, even if the service provider is a related party.
Automated Teller Machine (ATM):
a terminal/computer used by BPRs or BPRSs connected to other computers via data communication, allowing customers to deposit and withdraw money at BPRs or BPRSs or conduct other banking transactions.
Audit Trail:
files on a computer that store 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 not identified through normal inspection.
Back Up:
a copy of original documents or a backup of the main machine that can be used if the main machine experiences an interruption. Backups can be data backups or system backups. Backups can be placed on-site at the Data Center location or off-site at an alternative location.
Biometric Device:
a device or information security technology system that uses body parts as identity and authentication.
Business Continuity Management (BCM):
a comprehensive and integrated management process to ensure that Bank operational activities can continue functioning despite disruptions/disasters to protect the interests of stakeholders.
Business Continuity Plan (BCP):
a series of processes carried out to ensure the continued continuation of activities under conditions of disruption or disaster.
Client:
a computer in a network that uses resources provided by a server.
Contingency Plan:
procedures containing plans or manual steps that must be taken by business units to carry out operational business activities during the recovery process.
Cost and Benefit Analysis:
a comparative analysis between investment costs and profits obtained by BPRs or BPRSs from each alternative provider choice. The results of this analysis become one of the considerations for BPRs or BPRSs to make decisions on outsourcing or provider selection.
Database:
a comprehensive set of data arranged systematically, accessible by users according to their respective authorities, and managed by a Database Administrator.
Data Center:
a facility used to place Electronic Systems and related components for the purpose of placement, storage, and data processing.
Denial of Service (DoS):
an attack on information technology systems causing them to become slow or completely non-functional, for example, by making network bandwidth or computer disk space capacity appear fully used, server disruptions, and disruptions in service provision to other systems or users.
Digital Signatures:
signatures consisting of Electronic Information attached, associated, or related to other Electronic Information used as a verification and authentication tool.
Disaster Recovery Plan:
a document containing plans and steps to restore access to data, hardware, and software required, so that BPRs and BPRSs can carry out critical business operational activities after disruptions and/or disasters.
Disaster Recovery Center:
a facility used to restore data or information and important functions of Electronic Systems that are disrupted or damaged due to disasters caused by nature or humans.
Disposal Media Backup:
the process of destroying backup media that have passed their retention period and are no longer used.
Downtime:
the duration during which the system cannot function and be used by users due to hardware, software, and communication disruptions.
Encryption:
a tool to achieve data security by translating it using a key (password). Encryption prevents passwords or keys from being easily read in configuration files.
Exception Handling:
a mechanism to handle the emergence of unexpected conditions that can change the normal flow of an application system.
Firewall:
equipment to maintain network security that monitors and selects data/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 compromise internal computers, causing data corruption and/or Denial of Service for authorized users.
26. Gateway:
a point in a network that functions as an entry point to another network or connects one network to another. Gateways can be computers that manage and control network traffic.
27. Hardcopy:
a copy of computer data/information in printed form, also known as a printout.
28. Hardening:
the process/method to secure a system from various threats or disruptions. Methods used include, among others, disabling unnecessary services, as well as unnecessary usernames or logins, developing intrusion detection systems, intrusion prevention systems, and firewalls.
29. Hash Function:
a way to convert data (usually in the form of messages or files) into a specific number that can be used by computers to regenerate the original data.
30. Hub:
equipment that connects several cables on a network and forwards data/information to all addresses that are network points or target equipment.
31. 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 varying local networks).
32. System Integration Testing:
testing of overall functionality of the System after being integrated into a complete whole.

Library:
a collection of software or data that has a specific function and is stored and ready for use.
Logic Bomb:
code intentionally inserted into a software system that, under certain conditions, will perform a series of destructive functions.
Mobile Banking:
services that allow BPR or BPRS customers to conduct banking transactions via mobile phones. Mobile banking is generally conducted via SMS or mobile internet but can also use special programs downloaded via mobile phones.
Non-repudiation:
a method to ensure the authenticity of the sender and receiver so that no party can deny it.
Off-line:
a system or computer that does not have a network connection or cannot communicate with other systems or computers.
Outsourcing:
the use of third parties (external) in the management of BPR or BPRS information technology, causing BPRs or BPRSs to have continuous dependence on the services provided by such third parties or for a certain period.
Parallel Run:
one of the system implementation strategies where both old and new systems run side by side until users are sure that the new system has no problems. After a period of time when the new system is proven to work correctly, the old system will be completely removed and users will depend only on the new system.
Password:
numbers, letters, symbols, other characters, or combinations thereof, which are keys to access Computers and/or other Electronic Systems.
Patch:
a collection of code 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/facilities.
Logical Security:
a security system to prevent unauthorized access to computer systems and information stored therein, including the use of user IDs, passwords, etc.
Personal Identification Number (PIN):
a unique sequence of digits consisting of letters, numbers, or ASCII codes used to identify computer users, ATM users, internet banking users, mobile banking users, and others.
Platform:
hardware or software such as computer architecture, operating systems, or programming languages that allow an application to operate.
Super User:
a user ID with very broad authority.
Process Control:
control held by service providers, especially regarding the service processes provided to Banks to guarantee service quality in terms of confidentiality, integrity, and availability.
Proprietary:
exclusive ownership type by a specific party obtained legally.
Public Key Infrastructure:
a processing/arrangement where a trusted third party provides careful examination and ensures the validity of an identity.
Quality Assurance:
activities that ensure products or services meet established standards including reliability, usability, performance, and general quality standards established by the company.
Restore:
returning to original function or condition before a disaster occurred.
Restricted Area:
an area that can only be entered by persons who have obtained access rights.
Router:
network equipment that forwards data/information packets and selects the best route to take to deliver the data/information.
Service Level Agreement:
part of a contract agreement where the expected level of service provision by the parties is established, usually also including performance standards such as agreed service levels or target times for service provision.
Softcopy:
a copy of data or documents in electronic file form.
Source Code:
a series of commands, statements, and/or declarations written in a computer programming language that can be read and understood by humans.
Spoofing:
a state where a person or program can impersonate another person or program by falsifying data for the purpose of obtaining certain benefits.
Spyware:
software that collects sensitive information about users without the user's knowledge or consent.
Stress Testing:
testing the resilience of Electronic Systems or Core Banking Applications in handling processes or transactions on a large scale/quantity.
Switch:
equipment in a network that forwards information packets to the target address or equipment.
System:
a working network of interrelated procedures, coming together to carry out an activity or to achieve a specific goal.
System Development Life Cycle (SDLC):
a system development cycle that includes at least the following steps: (1) system planning, (2) system analysis, (3) system design, (4) system selection, (5) system implementation, (6) system maintenance, and (7) system disposal.
System Log:
files on a computer that store information regarding system or computer activities.
Testing:
trials conducted by quality assurance to test the overall functionality of application systems, including each object contained in the application system.
Trojan Horse:
a destructive program smuggled by hackers into programs already known to users, whose replication or distribution must be activated by programs already known to users through "social engineering" methods.
Unit Testing:
trials of the functionality of each unit or sub-module of a system that has been fully developed.
Uninterruptible Power Supply (UPS):
devices that have the main function of providing backup electricity for a certain period for installed electronic devices.

This copy is consistent with the original
Legal Director 1
Legal Department signed
Yuliana
69. Upload and Download:
transfer of electronic data between two computers or similar systems.
70. User Acceptance Test:
final testing conducted by end-users on a fully developed System to test the overall functionality of the system to see if it meets user needs at the user requirement definition stage before deciding that implementation can be carried out.
71. User Log:
files on a computer that store information regarding user activities such as login and logout times.
72. Virus:
a destructive program that becomes active with human assistance (executed), and cannot replicate itself; its spread is caused by human action, such as copying, usually via email attachments, games, pirated programs, and others.
73. War Driving:
an action to obtain wi-fi (wireless local area network) networks using devices that can detect the presence of wi-fi networks, such as laptops or smartphones.
74. Worm:
a computer program designed to automatically multiply itself by attaching to emails or as part of network messages. Worms attack networks and result in full bandwidth usage, thereby hindering data transmission rates on the network.

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

APPENDIX II
CIRCULAR LETTER OF THE FINANCIAL SERVICES AUTHORITY NUMBER 15 /SEOJK.03/2017 REGARDING STANDARDS FOR INFORMATION TECHNOLOGY MANAGEMENT FOR RURAL CREDIT BANKS AND SHARIA RURAL FINANCING BANKS

TABLE OF CONTENTS
CHAPTER I : CURRENT STATUS REPORT ON
INFORMATION TECHNOLOGY MANAGEMENT
FOR BPRs AND BPRSs
A. HUMAN RESOURCES RELATED TO
INFORMATION TECHNOLOGY
MANAGEMENT
B. DEVELOPMENT AND PROCUREMENT OF
ELECTRONIC SYSTEMS
C. INFORMATION TECHNOLOGY
OPERATIONAL ACTIVITIES
D. COMMUNICATION NETWORKS 8
E. INFORMATION SECURITY 9
F. DISASTER RECOVERY PLANS 12
G. INTERNAL AUDIT OF INFORMATION
TECHNOLOGY MANAGEMENT
H. COOPERATION WITH INFORMATION
TECHNOLOGY SERVICE PROVIDERS
I. FUNDAMENTAL CHANGES 17
CHAPTER II : REPORTS ON CRITICAL INCIDENTS, MISUSE
AND/OR CRIMES IN THE
MANAGEMENT OF INFORMATION TECHNOLOGY
CHAPTER III : REPORT ON THE IMPLEMENTATION OF COOPERATION WITH
INFORMATION TECHNOLOGY SERVICE PROVIDERS

CHAPTER I
CURRENT STATUS REPORT ON INFORMATION TECHNOLOGY MANAGEMENT FOR BPRs AND BPRSs Name of BPR/BPRS :
Head Office Address
BPR/BPRS
:
Telephone Number :
Name of Person in Charge
:
Position of Person in Charge
:
Report Date :
A. HUMAN RESOURCES RELATED TO INFORMATION TECHNOLOGY MANAGEMENT

Organizational structure of BPR or BPRS showing the position of work units or employees responsible for Information Technology management.
Attached Not Attached
Job description of work units or employees responsible for Information Technology management.
Attached Not Attached
Training and/or certification in the field of Information Technology previously attended by members of work units or employees responsible for Information Technology.
Attached Not Attached

B. DEVELOPMENT AND PROCUREMENT OF ELECTRONIC SYSTEMS

Policies and procedures for the development and procurement of BPR or BPRS electronic systems.
Attached Not Attached
List of Electronic Systems *) that have been implemented.
a) Developed in-house.
Attached Not Attached b) Developed by Information Technology service providers.
Attached Not Attached
Application Architecture
Attached Not Attached
List of Electronic Systems *) in the process of development and procurement.
a) Developed in-house.
Attached Not Attached b) Developed by Information Technology service providers.
Attached Not Attached
BPR or BPRS carries out project management functions for electronic systems currently under development and procurement.
Yes No
BPR or BPRS separates environments for development, testing, and operations.
Yes No
*) Contains information on the name of the Electronic System including applications, hardware/software or other Electronic Systems, the purpose of the Electronic System, the developer party (in-house or vendor name), the manager (internal/external), platform/operating system, implementation date, technical user documentation, type of Database system, location of the main server, and location of the backup server that installs this Electronic System including applications.

C. INFORMATION TECHNOLOGY OPERATIONAL ACTIVITIES *)

Information regarding BPR or BPRS Data Centers:
a) Address b) Ownership Status
Own Property
Property of Information Technology
Service Provider c) Specifications of the main server and other hardware.
Attached Not Attached d) Completeness of physical security at the Data Center.
Attached Not
Attached
There are servers located outside the Data Center.
Yes No
Special applications for information security (access control software).
Yes No
Problem Handling Procedures (Problem Handling including Helpdesk).
Yes No
Change management policies and procedures.
Yes No
Policies and procedures for managing user access rights to systems and applications.
Yes No
Determination of system & data sensitivity.
Yes No
Availability of audit trails on systems and data.
Yes No
Data backup policies and procedures.
Yes No
*) If there is more than 1 Data Center, additional Data Center information from item 1 to No. 9 above must also be included.

D. COMMUNICATION NETWORK

Structure/topology of Data Communication Network (primary and backup).
Attached Not Attached
Security policies and procedures for the Communication Network.
Yes No
List of hardware and software used for the Communication Network.
Attached Not Attached
Communication Network monitoring system.
Yes No
Policies and procedures for securing the Data Communication Network (e.g., firewall).
Yes No

E. INFORMATION SECURITY *)

Information security policies and procedures, including among others:
a) Granting, changing, and deleting user access.
Yes No b) Security Awareness Program.
Yes No c) Information security incident handling team (Incident Response Team).
Yes No d) Data classification.
Yes No e) Use of emergency user IDs.
Yes No f) Prevention of illegal software usage.
Yes No
Asset Management
a) Information-related asset management includes identification, determination of ownership and responsibility, and inventory of asset lists.
Attached Not Attached b) Information classification (e.g., confidential, internal, general) and its security procedures.
Attached Not Attached

c) Physical security including the use of security tools (access control cards, PINs, etc.) for information processing facilities.
Yes No
3. Access Security
a) Implementation of password security on applications, for example, applications forcing users to change passwords periodically.
Yes No b) Grouping of access rights granted to each user for every application owned by the BPR or BPRS.
Yes No c) Existence of an audit function (audit log/audit trail) for every activity performed by users and analysis of such audit logs/trails.
Yes No d) Periodic evaluation by an independent party regarding the correspondence between users and the access rights granted.
Yes No
4. Human Resources
a) Inclusion of provisions regarding information security in agreements with BPR or BPRS employees, contract employees, and third parties.
Yes No b) Existence of provisions regarding sanctions for violations of information security policies and procedures.
Yes No

c) Procedures for returning or changing access rights to information-related assets upon transfer or completion of employment agreements or duty periods.
Yes No
5. Information Technology Operations
Provisions regarding security in identification and access authentication, such as the use of passwords, tokens, biometrics, etc.
Yes No
6. Information Security Incident Handling
a) Provisions regarding the requirement to report the occurrence of information security incidents.
Yes No b) Procedures regarding the reporting, handling, documentation, and follow-up of information security incidents.
Yes No
*) If BPRs and BPRSs use Information Technology service providers in the implementation of Information Technology, the questions above also apply to the implementation of such Information Technology.

F. DISASTER RECOVERY PLAN

BPRs and BPRSs have a Disaster Recovery Plan.
Yes No
Disaster Recovery Center
a) Address b) Specifications of server backups and other hardware.
Attached Not Attached c) Completeness of physical security at the Disaster Recovery Center.
Attached Not Attached d) Disaster Recovery Center configuration (network topology, hardware, software, and other support).
Attached Not Attached e) Data backups (hot, warm, cold backup) for each application available at the Disaster Recovery Center.
Attached Not Attached
Disaster Recovery Plan Testing.
a) Policies and procedures for testing
Yes No b) Overall testing for all critical systems/applications was last done Ever Date:
.................
Never

c) Partial testing of systems/applications in the last 1 (one) year Application
..........................
Operational area
..........................
Date
………….
Date
..………

G. INTERNAL AUDIT OF INFORMATION TECHNOLOGY IMPLEMENTATION *)

The BPR or BPRS has an executive organ for the internal audit function regarding Information Technology implementation.
Yes No
If yes, attach the structure of the executive organ for the internal audit function regarding Information Technology implementation and complete it with the curriculum vitae of the internal auditor.
Attached Not Attached
The BPR or BPRS uses external auditors to perform the internal audit function regarding Information Technology implementation.
Yes No
If yes, attach the latest work agreement.
Attached Not Attached
The BPR or BPRS has internal audit guidelines for Information Technology implementation.
Yes No
Internal audit regarding Information Technology implementation is conducted at least 1 (one) time per year.
Yes No
State the two dates of the last internal audits regarding Information Technology implementation.
Date.......................................................
Date.......................................................
The internal audit regarding Information Technology implementation mentioned above has covered Core Banking Applications as well as the authority and responsibility of the Board of Directors, Board of Commissioners, and work units or employees responsible for Information Technology implementation.

Yes No
5. Internal audit reports regarding Information Technology implementation are submitted to the President Director, Board of Commissioners, Audit Committee (if any), and copied to Board of Directors members who oversee the compliance function.
Yes No
*) Information includes the type of services, data of the service provider (company name, data center address, company address, majority owner/group owner), date and duration of the agreement, contact person at the bank handling the IT implementation service, and other important information.

H. COOPERATION WITH INFORMATION TECHNOLOGY SERVICE PROVIDERS

Date of start of IT cooperation implementation for the BPR or BPRS:
Describe the name and address of the Information Technology service provider
Name :
Address :
Data Center Location :
Disaster Recovery Center Location :
List of Information Technology services managed by the Information Technology service provider.
Attached Not
Attached
Data Communication Network used by the Information Technology service provider for the BPR or BPRS.
Attached Not
Attached
Copy of the cooperation agreement between the BPR or BPRS and the Information Technology service provider.
Attached Not
Attached
Latest evaluation results regarding the cost-benefit analysis of Information Technology implementation by the Information Technology service provider.
Yes No
Analysis by the BPR or BPRS regarding the adequacy of the Information Technology service provider's Disaster Recovery Plan.
Yes No

I. FUNDAMENTAL CHANGES
This section is only to be filled if the BPR or BPRS submits a report on the current condition after exceeding 1 (one) year since the POJK on IT was issued and a fundamental change occurs in the implementation of Information Technology. In the event of a fundamental change, the BPR or BPRS must submit a report on the current condition as stated in Chapter I letters A to I to provide explanations and reasons for the fundamental change.

Effective date of operation since the fundamental change in Information Technology implementation *):
Type of fundamental change in Information Technology implementation:
*) Changes in IT implementation are reported within 10 (ten) working days after the fundamental change becomes effective as required by the POJK and OJK Circular Letter.
) What is meant by fundamental change includes changes to Information Technology configuration or Core Banking Applications, procurement of Core Banking Applications, cooperation with Information Technology service providers, and other fundamental IT development and procurement that can add and/or increase the risk of the BPR or BPRS. *) Explanations must be accompanied by further information including reasons for the fundamental change and technical details of the fundamental change performed by the BPR or BPRS. Accompanied by attached documents. Fundamental Change ) Explanation and Reason *) 1. 2. 3. etc

CHAPTER II
REPORT ON CRITICAL INCIDENTS, MISUSE AND/OR CRIMES IN INFORMATION TECHNOLOGY IMPLEMENTATION*) Name of BPR/BPRS :
Address of BPR/BPRS Headquarters
:
Telephone Number :
Name of Person in Charge
:
Position of Person in Charge
:
Report Date :

Date of Incident
Chronology and evaluation of incident causes
Attached Not
Attached
Presence of intentional elements
Yes No
Relevant work unit or employees who can be contacted further:
...................................................................................................
Impact/consequences caused
a. Significant financial loss
Yes No b. Operational disruption
Yes No
If the answer is "Yes", attach the form of operational disruption that occurred and the contingency plan that has been implemented.

c. Unsecured confidentiality and data integrity
Yes No
If the answer is "Yes", attach the form of threats to confidentiality and data integrity.
6. Follow-up plan by BPR and BPRS
Attached Not
Attached
*) The critical incidents referred to are serious system failures, system downtime, and degradation of system performance that affect the performance of the BPR and BPRS in providing services to customers. Misuse/crimes in Information Technology implementation are actions that result in financial losses and/or disrupt the smoothness of bank operations.

CHAPTER III
REPORT ON THE REALIZATION OF COOPERATION WITH INFORMATION TECHNOLOGY SERVICE PROVIDERS Name of BPR/BPRS :
Address of BPR/BPRS Headquarters
:
Telephone Number :
Name of Person in Charge
:
Position of Person in Charge
:
Report Date :

Date of start of IT cooperation implementation for the BPR or BPRS:
Describe the name and address of the Information Technology service provider
Name :
Address:
Data Center Location :
Disaster Recovery Center Location :
List of Information Technology services managed by the Information Technology service provider.
Attached Not
Attached
Nominal value of the cooperation agreement with the Information Technology service provider.
Attached Not
Attached

This copy is in accordance with the original
Legal Director 1
Legal Department signed
Yuliana
5. Duration of the cooperation agreement with the Information Technology service provider.
Attached Not
Attached
6. Photocopy of the cooperation agreement with the Information Technology service provider.
Attached Not
Attached
Determined in Jakarta on April 6, 2017
EXECUTIVE HEAD OF BANKING SUPERVISOR
FINANCIAL SERVICES AUTHORITY, signed
NELSON TAMPUBOLON

Standard for Information Technology Implementation for Rural Banks and Sharia Rural Financing Banks

Lineage: In force