To Comply Board Approved ICT Security Policy Version 4.3 2023

ICT Security Policy
Version: 4.3
Trust Bank Limited
May, 2023
Confidentiality
No part of this document may be disclosed verbally or in writing, including by reproduction, to any third party without the prior
written consent of the Bank. This document, its associated appendices and any attachments remain the property of the Bank
and shall be returned upon request.
Information Technology (IT) Division

Contents
Document Details .................................................................................... Error! Bookmark not defined.
Chapter 1 ........................................................................................................................................... 2
1.1 Introduction ............................................................................................................................. 2
1.2 Definition of ICT Policy ............................................................................................................. 2
1.3 Information Security Management System (ISMS) Objectives .................................................... 2
1.4 Scope ............................................................................................................................... 3
1.5 Acceptable Use Policy ............................................................................................................... 3
1.5.1 Unacceptable Use ............................................................................................................................... 3
1.6 Authority ............................................................................................................................... 3
1.7 Violations ............................................................................................................................... 3
1.8 Implementation........................................................................................................................ 4
1.9 Policy Modification ................................................................................................................... 4
Chapter 2 ........................................................................................................................................... 5
2.0 ICT Security Management ......................................................................................................... 5
2.1 Objective of Information Security ............................................................................................. 5
2.2 ICT Governance ........................................................................................................................ 5
2.2.1 Authority of the Board of Directors ......................................................................................................... 6
2.2.2 ICT Steering Committee .......................................................................................................................... 6
2.2.3 ICT Security Committee ........................................................................................................................... 7
2.3 Documentation ........................................................................................................................ 7
2.4 Internal Information System Audit ............................................................................................ 8
2.5 External Information System Audit ........................................................................................... 8
2.6 Standard Certification and License ............................................................................................ 9
Chapter 3 ......................................................................................................................................... 10
3.0 ICT Risk Management ............................................................................................................. 10
3.1 ICT Risk Governance ............................................................................................................... 10
3.2 ICT Risk Assessment................................................................................................................ 10
3.3 ICT Risk Response ................................................................................................................... 11
Chapter 4 ......................................................................................................................................... 13
4.0 ICT Service Delivery Management ........................................................................................... 13
4.1 Change Management .............................................................................................................. 13
4.1.1 Scope of Change Management .................................................................... Error! Bookmark not defined.
4.1.2 Change and Configuration Management Policy ........................................... Error! Bookmark not defined.
4.1.3 Change Management Governance .............................................................. Error! Bookmark not defined.
4.2 Incident Management............................................................................................................. 14
4.2.1 Computer Emergency Response Team (CERT) .................................................................................. 14
4.2.2 Incident Management Policy ................................................................................................................. 14
©Trust Bank Limited
4.3 Problem Management ............................................................................................................ 15
4.3.1 Objective of Problem Management ...................................................................................................... 15
4.3.2 Problem Management Policy ................................................................................................................ 15
4.4 Capacity Management ............................................................................................................ 16
4.4.1 Capacity and Performance Management .............................................................................................. 16
4.4.2 Performance Monitoring of IT Resources .............................................................................................. 16
4.4.3 Capacity Planning of IT Resources ......................................................................................................... 16
Chapter 5 ......................................................................................................................................... 18
5.0 Infrastructures Security Management ..................................................................................... 18
5.1 Infrastructure Security Governance ......................................................................................... 18
5.2 Hardware and Software Security Policy ................................................................................... 18
5.2.1 Software Modification and Code Review: ............................................................................................. 19
5.2.2 Updates & Patch Management ............................................................................................................. 19
5.3 Secure System Development Policy ......................................................................................... 19
5.4 Laptop Policy .......................................................................................................................... 20
5.5 BYOD Controls ........................................................................................................................ 20
5.6 Device Controls (Desktop and Laptop) ..................................................................................... 20
5.7 Security Baseline .................................................................................................................... 21
5.7.1 Server Virtualization ............................................................................................................................. 21
5.7.2 Operating System Hardening ................................................................................................................ 21
5.7.3 Network Hardening ............................................................................................................................... 22
5.7.4 Database Hardening .............................................................................................................................. 22
5.8 Data Encryption ...................................................................................................................... 23
5.9 Cryptography ......................................................................................................................... 23
5.9.1 Cryptographic Key Management ........................................................................................................... 24
5.10 Vulnerability Assessment (VA) and Penetration Testing (PT) .................................................. 23
5.11 Network Security Management ............................................................................................. 24
5.11.1 Network Access Control ...................................................................................................................... 24
5.11.2 Network Administration and Maintenance ......................................................................................... 25
5.11.3 Backup and Log Inspection .................................................................................................................. 25
5.12 Internet Access Management ................................................................................................ 26
5.13 Email Management ............................................................................................................... 26
5.14 Virus and Malicious Code Protection ..................................................................................... 27
5.15 Security Device Management ........................................................ Error! Bookmark not defined.
5.15.1 Baseline for System Configuration ...................................................................................................... 27
5.15.2 Router & Firewall Usage ...................................................................................................................... 28
5.15.3 Router & Firewall Configuration .......................................................................................................... 28
5.16 Cyber Security Governance and Security Operations Centre ................................................... 27
5.17 Data Center Controls ............................................................................................................ 29
5.17.1 Physical Security of Data Center and DR Site ....................................................................................... 30
5.17.2 Environmental Security of Data Center and DR Site ............................................................................ 30
5.17.3 Fire Prevention of Data Center and DR Site ......................................................................................... 30
5.17.4 Equipment Security of DC & DR........................................................................................................... 31
5.17.5 Working outside Designated Office Hours ........................................................................................... 31
5.18 Branch Server Room Controls ................................................................................................ 31
5.18.1 Physical Security Branch Server Room................................................................................................. 32
5.18.2 Branch Server Room Environmental Security ...................................................................................... 32
5.18.3 Branch Server Room Fire Protection ................................................................................................... 32
5.19 Mobile Device and Teleworking ........................................................................................... 32
5.20 Work from Home (WFH) Security .......................................................................................... 33
5.21 Remote Access (VPN) ............................................................................................................ 33
Chapter 6 ......................................................................................................................................... 34
6.0 IT Operation Management ...................................................................................................... 34
6.1 Operation of CBS, Application & System.................................................................................. 34
6.1.1 Operating time schedule ....................................................................................................................... 35
6.1.2 IT Division responsibilities ..................................................................................................................... 35
6.1.3 Employee’s responsibilities ................................................................................................................... 36
6.2 Third Party Management ........................................................................................................ 36
6.2.1 Third Party Software ............................................................................................................................. 36
6.2.2 Third Party Service Delivery .................................................................................................................. 36
6.3 Asset Management ................................................................................................................. 36
6.4 Disposal Policy ....................................................................................................................... 37
6.4.1 Disposal Policy of IT Equipment ............................................................................................................ 37
6.4.2 Disposal Policy for Data /Documents/Payment Cards (Debit/Credit/Prepaid) ...................................... 37
6.4.3 Considering factors for Data and Software removal .............................................................................. 38
6.4.4 Factors regarding Deleting Data- technical aspects ............................................................................... 38
6.4.5 Re-use of items from obsolete equipment ............................................................................................ 39
6.5 Insurance Fund & Depreciation ............................................................................................... 39
6.6 Data Leak Protection (DLP) Policy ........................................................................................... 39
6.6.1 Data in Motion ...................................................................................................................................... 39
6.6.2 Data at Rest .......................................................................................................................................... 39
6.6.3 Data in Use............................................................................................................................................ 40
6.7 Clear Desk and Clear Screen Management ............................................................................... 40
6.8 Information Handling ............................................................................................................. 40
6.9 Information Classification ....................................................................................................... 40
6.9.1 Responsibility........................................................................................................................................ 40
6.9.2 Classification ......................................................................................................................................... 41
6.9.3 Labelling................................................................................................................................................ 41
6.9.4 Handling................................................................................................................................................ 41
6.10 SECURITY CLASSIFICATION DEFINITIONS ................................................................................ 42
6.10.1 PUBLIC ................................................................................................................................................ 42
6.10.2 INTERNAL USE ONLY............................................................................................................................ 42
6.10.3 PROTECTION ....................................................................................................................................... 42
6.10.4 CONFIDENTIAL .................................................................................................................................... 43
6.10.5 PROTECTION ....................................................................................................................................... 43
Chapter 7 ......................................................................................................................................... 44
7.0 User Access Management ....................................................................................................... 44
7.1 User ID Management: ............................................................................................................. 44
7.2 Maintenance of System Users ................................................................................................. 45
7.3 Password Control ................................................................................................................... 46
7.4 Input Control .......................................................................................................................... 46
7.5 Privileged Access Management ............................................................................................... 46
7.6 Data Confidentiality ............................................................................................................... 47
7.7 Data Protection and Privacy .................................................................................................... 48
7.8 User Log Reports .................................................................................................................... 48
Chapter-8 ......................................................................................................................................... 49
8.0 Business Continuity & Disaster Recovery Management:........................................................... 49
8.1 Business Continuity Plan ......................................................................................................... 49
8.1.1 Guideline of BCP ................................................................................................................................... 49
8.1.2 Maintaining the BCP ............................................................................................................................. 50
8.1.3 Testing Continuity Plan ......................................................................................................................... 50
8.2 Disaster Recovery Management .............................................................................................. 50
8.2.1 Disaster Recovery Policy ....................................................................................................................... 51
8.2.2 DR Site Operation ................................................................................................................................. 51
8.3 Backup and Restore Policy ...................................................................................................... 51
Chapter 9 ......................................................................................................................................... 53
9.0 Acquisition and Development of Information Systems............................................................. 53
9.1 ICT Project Management......................................................................................................... 53
9.2 In-house Software .................................................................................................................. 53
9.2.1 In-house Software Development........................................................................................................... 53
9.2.2 Software/Application Rollout ............................................................................................................... 53
9.3 Statutory Requirements.......................................................................................................... 54
9.4 In-house Application Security ................................................................................................. 54
9.5 Software Security Framework ................................................................................................. 55
9.6 Software Documentation ........................................................................................................ 55
9.7 Outsourced Software Procurement Policy ............................................................................... 56
9.8 Software licensing .................................................................................................................. 56
9.9 Legal reference ....................................................................................................................... 57
Chapter 10 ....................................................................................................................................... 58
10.0 Service Provider Management .............................................................................................. 58
10.1 Outsourcing .......................................................................................................................... 58
10.1.1 Outsourcing Governance ..................................................................................................................... 58
10.1.2 Practices of Outsourcing activities:...................................................................................................... 58
10.1.3 Considering factors for Outsourced System......................................................................................... 59
10.1.4 Vendor Selection ................................................................................................................................. 59
10.1.5 Vendor Management .......................................................................................................................... 61
10.2 Service Level Agreement Policy ............................................................................................. 61
10.3 Cross-border System Support ................................................................................................ 62
10.4 Data Ownership .................................................................................................................... 62
Chapter 11 ....................................................................................................................................... 63
11.0 Alternative Delivery Channels ............................................................................................... 63
11.1 ATM and POS Transactions ................................................................................................... 63
11.2 Internet Banking ................................................................................................................... 64
11.2.1 Security of Internet Banking ................................................................................................................ 64
11.2.2 Operation of Internet Banking ............................................................................................................ 65
11.2.3 Awareness for Internet Banking .......................................................................................................... 65
11.3 Payment Cards ..................................................................................................................... 65
11.3.1 Payment Card Industry Data Security Standard (PCIDSS): ................................................................... 66
11.3.2 Card Data Retention Policy.................................................................................................................. 67
11.4 Auxiliary Services.................................................................................................................. 67
11.4.1 SMS Banking Service ........................................................................................................................... 67
11.4.2 Phone Banking Service ........................................................................................................................ 67
11.5 Contact Center Security ........................................................................................................ 68
Chapter-12 ....................................................................................................................................... 69
12.1 Customer Education .............................................................................................................. 69
12.2 Customer Awareness Program .............................................................................................. 69
12.2.1 Preparing work plan ............................................................................................................................ 69
12.2.2 Define objective of the program ......................................................................................................... 70
12.2.3 Formulating primary channels for the program ................................................................................... 70
12.2.4 Formulating program through interactive broadcast media ................................................................ 70
12.2.5 Outcome/Effectiveness of each awareness program........................................................................... 70
Chapter-13 ....................................................................................................................................... 71
13.1 Human Resources Security Management ............................................................................... 71
13.1.1 Prior to Employment ........................................................................................................................... 71
13.1.2 Screening ............................................................................................................................................ 71
13.1.3 Terms and Conditions of Employment ................................................................................................ 71
13.1.4 Information and Cyber Security Awareness Program .......................................................................... 71
13.1.5 Termination and Change of Employment ............................................................................................ 72
13.1.6 Social Media Policy.............................................................................................................................. 72
13.1.7 Social Engineering Policy ..................................................................................................................... 72
13.2 Sanctions on ICT Security Policy Violations ............................................................................ 73
Acronyms ......................................................................................................................................... 74
Annexures ........................................................................................................................................ 75
Annexure 1 76
Service Request Form .................................................................................................................................... 76
Annexure 2 77
User Acceptance Test ..................................................................................................................................... 77
Annexure 3 78
Dispensation Form......................................................................................................................................... 78
Annexure 4 79
Incident Reporting Form ................................................................................................................................ 79
Annexure 5 80
Remote VPN Access REQUEST FORM ............................................................................................................. 80

Document Profile
Revision Number 4.3
Document ID TBL-ISMS-POL-01- ICT Security Policy
Reviewed By ICT Security Committee
Document Owner CISO
Document Approver Board of Directors
Approved Date 15-05-23
Next Revision 15-05-24
Document Classification Internal Use Only

Document Location Intraweb
Document Change Control

Revision No. Date Issued Author Nature of Change
4.3 16-05-23 CISO Revision & Modification
Revision History
Revision Date Author Change History

1.0 Original IT Division New Document
2.0 August, 2011 IT Division Revision & Modification
3.0 January, 2014 IT Division Revision & Modification
3.1 March, 2016 IT Division Revision & Modification
4.0 February, 2018 IT Division Revision & Modification
4.1 November, 2018 IT Security Team Revision & Modification
4.2 August, 2020 IT Security Team Revision & Modification
4.3 May, 2023 IT Security Team Revision & Modification
Approval List
Name Position Date
Humaira Azam MD & CEO 15-05-23
EC 18-07-23
Board 12-08-23
©Trust Bank Limited Internal Page 1
Chapter 1 Information Security Management System (ISMS) Policy
1.1 Introduction
The Banking industry has changed the way they provide services to their customers and process information in
recent years. Information and Communication Technology (ICT) has brought about this momentous
transformation. Security of Information for a financial institution has therefore gained much importance, and it
is vital for us to ensure that the risks are properly identified and managed. Moreover, information and
information technology systems are essential assets for the bank as well as for their customers and stakeholders.
Information assets are critical to the services provided by the banks to their customers. Protection, Data privacy
and maintenance of these assets are critical to the organizations’ sustainability.
Trust Bank Limited (TBL) is one of the new generation private sector banks in the country competing with
another 56 banks nationwide which includes some nationalized, foreign, and local commercial banks.
Technological change and diffusion of new technologies are moving at an incredible pace. Such development
and diffusion accelerates the importance of innovation of the bank if the bank is to remain competitive. Trust
Bank Limited should take appropriate measures and responsibility of protecting the information from
unauthorized access, modification, disclosure and destruction.
1.2 Information Security Management Framework
a) Risk Assessment: TBL will conduct a risk assessment to identify information security risks, assess the
likelihood and impact of those risks, and prioritize risk mitigation activities.
b) Risk Treatment: TBL will select and implement appropriate controls to mitigate identified risks to an
acceptable level.
c) Information Security Controls: TBL will implement a set of information security controls based on
industry-recognized standards and best practices.
d) Incident Management: TBL will establish an incident management process to detect, respond to, and
recover from security incidents.
e) Business Continuity: TBL will develop and maintain a business continuity plan to ensure the timely
recovery of critical business functions and information systems in the event of a disruption
1.3 Information Security Management System (ISMS) Objectives

This Information Security Management System (ISMS) policy outlines TBLs commitment to protect the
confidentiality, integrity, and availability of our organization’s information. This policy defines control
requirements to which each must adhere. The primary objectives are:
a. Protect the confidentiality, integrity, and availability of TBLs information assets;

b. Comply with all applicable laws, regulations, and standards;
c. Identify and mitigate information security risks to an acceptable level;
d. Continuously improve our information security posture;
e. Promote a culture of security awareness and responsibility.
f. To establish a secured environment for the processing of data
g. To establish a holistic approach for ICT Risk management
h. To aware stakeholders' roles and responsibilities for the protection of information
i. To establish appropriate project management approach for ICT projects
1.4 Scope
This Policy is a systematic approach required to ensure security of information and information systems within
TBL Head Office and Branches from which Bank’s information is accessed including home and offsite. It covers
information that is electronically generated, received, stored, printed, scanned and typed. However, the
provisions of this policy shall be applied to:
a. Technology infrastructure, information and communication systems

b. All activities, legal/contractual agreements and operations required to ensure data security including
facility, physical security, network security, disaster recovery and business continuity planning, use of
hardware and software, data disposal and protection of copyrights and other intellectual property
rights.
c. All permanent and contractual employees those are responsible for usage of information system,
suppliers/vendors and consultants who have access to TBLs information systems.
d. Software that is owned, licensed or developed using own resources.
1.5 Acceptable Use Policy
An Acceptable Use Policy is intended to protect TBL employees, partners and the Bank from illegal or damaging
actions by individuals, either knowingly or unknowingly. This ICT Security Policy is a systematic approach of
controls required to be formulated for ensuring security of information and ICT systems.
a. HRD has a responsibility to inform the relevant departments and appropriate channels when an
employee is leaving the Bank. Systems Administration will then immediately revoke all access rights
previously assigned to the user.
b. PRIVATELY owned equipment belonging to employees must not be connected to the Bank’s
infrastructure. Any unauthorized equipment connected to the Bank’s infrastructure will be identified
and disconnected and the user shall be held accountable, which may result in disciplinary action.
c. HACKING, trying to gain unauthorized access to any computer system within the Bank constitutes a
criminal offence and will be subjected to the appropriate Legal process and/or Bank’s disciplinary
procedures.
1.5.1 Unacceptable Use
Under no circumstances is an employee of TBL authorized to engage in any activity that is illegal under local,
regulatory or international law while utilizing TBL owned resources.
1.6 Authority
This policy has full support from the Management, Executive Committee and Board of Directors of TBL. This
policy is currently effective for all TBL employees and computer systems.
1.7 Violations
Violations may result in disciplinary action in accordance with bank policy. Failure to observe these guidelines
may result in disciplinary action by the bank depending upon the type and severity of the violation, whether it
causes any liability or loss to the bank or the presence of any repeated violation(s).

1.8 Roles and Responsibilities
a) Senior management is responsible for approving this policy, allocating resources to support information
security, and monitoring compliance with this policy and related procedures.
b) Information security personnel are responsible for implementing, maintaining, and continuously
improving the ISMS.
c) All employees, contractors, consultants, and third-party partners are responsible for complying with
this policy and related procedures, reporting security incidents, and participating in security awareness
training.
1.9 Policy Modification
a. As Information & Communication Technology (ICT) is changing rapidly with global environment, the ICT
Policy may be amended and upgraded time to time accepting the better policies.
b. Such amendment or modification should be done in consultation with the concern
divisions/departments.
c. EC and Board of TBL will finally approve the policy as per recommendation of the ICT Security and Policy
Review Committee.

Chapter 2
2.0 ICT Security Management
The ICT Security Management of Trust Bank ensures that the ICT functions and operations are efficiently and
effectively managed. The ICT Security Management of Trust Bank also ensures maintenance of appropriate
systems documentations, particularly for systems, which support financial reporting. Trust Bank participates in
ICT security planning to ensure that resources are allocated consistent with business objectives which also is a
part of ICT Security Management. Sufficient and qualified technical employees are employed so that
continuance of the ICT operation area is unlikely to be seriously at risk all times.
Core principles for ICT security management are in the following areas:
i. Risk assessment
ii. Organizing information security
iii. Asset management
iv. Data center physical security
v. Information related communications and operations management
vi. Technology based access control
vii. System development and maintenance
viii. Information security incident management
ix. Business continuity management
x. IT security compliance
Trust Bank shall be aware of the capabilities of ICT and be able to appreciate and recognize opportunities and
risks of possible abuses. ICT Security Management deals with Roles and Responsibilities, ICT Security Policy,
Documentation, Internal and External Information System Audit, Training and Awareness, Insurance or Risk
coverage fund.
2.1 Objective of Information Security
Information Security activities are concerned with the protection of Information from unauthorized use or
accidental modification, loss or release. Information Security is based on the following three elements:
i. Confidentiality - ensuring that Information is only accessible to those with authorized access.
ii. Integrity - safeguarding the accuracy and completeness of Information and processing methods. Assets
can be modified only by authorized persons/parties or only in authorized ways.
iii. Availability - ensuring that authorized Users have access to Information when required. Assets are
accessible to authorized parties at appropriate times.
2.2 ICT Governance
ICT Governance as part of corporate governance is aimed at ensuring that IT is also managed with standards in
accordance with best practices that ensure the Bank’s information and related technology, support its business
objectives and its resources are used responsibly and its risks are managed appropriately. Information security
governance requires strategic, senior management commitment, resources and assignment of responsibility for
information security. ICT Governance stakeholders include Board of Directors, MD/CEO, IT Steering Committee,
IT Risk Management Committee, Chief Information Security Officer (CISO), Chief Risk Officer (CRO) and Senior
Business Executives. The Board of Directors and Executive Management (IT Steering Committee) shall be
responsible for overall ICT Governance.

2.2.1 Authority of the Board of Directors
Members of the Board need to be aware of the organization’s information assets and their criticality to ongoing
business operations. This can be accomplished by periodically providing the Board with the high-level results of
comprehensive risk assessments and business impact analysis. It may also be accomplished by business
dependency assessments of information resources. A result of these activities should include Board members
validating/ratifying the key assets they want protected and confirming that protection levels and priorities are
appropriate to a recognized standard of due care. The major responsibility of the Board for ICT supervision is:
a. Approving ICT strategy and policy documents

b. Ensuring that effective planning process has been placed
c. Endorsing that the ICT strategy is indeed aligned with business strategy of the bank
d. Ensuring that the ICT organizational structure complements the business model and its direction.
e. Ensuring ICT investments represent a balance of risks and benefits and acceptable budgets.
f. Ensure compliance status of ICT Security Policy
2.2.2 ICT Steering Committee
Information security affects all aspects of an organization. To ensure that all stakeholders affected by security
considerations are involved, a steering committee of executives shall be formed to serves as an effective
communication channel for management’s aims and directions and provides an ongoing basis for ensuring
alignment of the security program with organizational objectives. ICT Steering Committee shall ensure that IT
organizational structure exists, evaluate ICT investments, resource usage to ensure that it is in line with ICT
strategies and the Bank business objectives.
Formation of the ICT Steering Committee

i. Head of Security Management Department (SMD)
ii. Head of IT Division (ITD)
iii. Deputy Head of IT
iv. Head of Risk Management Division (RMD)
v. Head of Business
vi. Head of Operations
vii. Head of Internal Control and Compliance (IC&C)
viii. Head of Human Resources Division (HRD)
ix. Head of Legal
x. Head of FCAD
xi. Head of Information Security/CISO
Major Functions of ICT Steering Committee

a. Monitor management methods to determine and achieve strategic goals
b. Aware about exposure towards ICT risks and controls
c. Provide guidance related to risk, funding, or sourcing
d. Ensure project priorities and assessing feasibility for ICT proposals
e. Ensure that all critical projects have a component for "project risk management"
f. Consult and advise on the selection of technology within standards
g. Ensure that vulnerability assessments of new technology is performed
h. Ensure compliance to regulatory and statutory requirements
i. Provide direction to architecture design and ensure that the ICT architecture reflects the need for
legislative and regulatory compliance.

2.2.3 ICT Security Committee
The committee is responsible for identifying, assessing and proposing mitigation for every information-security-
related risk. The responsibility of the committee will be carried out by interacting with various committees and
stakeholders and preparing plans, proposals, policies, procedures and guidelines.
Formation of the ICT Security Committee

TBL should have ICT Security Committee which needs to be formed with the following representatives:
i. Head of Security Management Department
ii. Head of IT
iii. Deputy Head of IT
iv. Head of Risk Management Division
v. Representative of IC&C
vi. Representative of Operations Division
vii. Representative of Business Team/Committee
viii. Head of Information Security
Major Functions of ICT Security Committee

a. Ensure development and implementation of ICT security objectives, ICT security related policies and
procedures.
b. Provide ongoing management support to the Information security processes.
c. Ensure continued compliance with the business objectives, regulatory and legal requirements related
to ICT security.
d. Support to formulate ICT risk management framework/process and to establish acceptable ICT risk
thresholds/ICT risk apatite and assurance requirements.
e. Periodic review and provide approval for modification in ICT Security processes.
f. The security committee needs to follow information security process model based on 16 components.
i. Application security
ii. Cryptography
iii. IT security monitoring
iv. IT Incident management
v. Online banking security
vi. Malware management
vii. Core banking data protection
viii. Secure software development life cycle
ix. IT vendor (third-party) management
x. Access management in DC & DR
xi. IT Risk management
xii. Physical security of DC & DR
xiii. IT Awareness
xiv. Accountability and ownership of IT equipment
2.3 Documentation
a. Documents are to be preserved in two ways:

i. Scanning physical documents into electronic format and hard copy.
ii. The electronic format/soft copy needs to be archived in web-based document archiving system
so that the document can be downloaded on demand and with proper authorization.
b. Documents are to be included with Notes, Memos, Minutes, Resolutions, Decisions, Office Orders,
Instructions, Letters, Mails, Agreements, Contracts etc. Other documents includes:
i. Organogram and Branch Organogram
ii. Functional Job Description
iii. Fallback resource plan
iv. Schedule for roster for IT Shift duties.
v. Detailed design documents for all ICT service (e.g. Data center design, Network design, Power
layout for DC and DR, fire detection layout for DC and DR, water detection layout for DC and
DR)
vi. Maintain updated Operating Procedure for all ICT functional activities (e.g. Backup procedure,
Restore procedure etc.)
vii. Business Continuity Plan
viii. Updated Inventory of all Hardware & Software, including License
ix. Vendor Contact List.
x. External/Internal IT Audit Report.
xi. Change management Document (Patch, Q/A, UAT signoff).
xii. Problem management.
xiii. Agreement Copy of SLA, Escrow and Non-Disclosure
xiv. Technical documentation for all types of software.
xv. User Manual of all applications for internal/ external users.
xvi. Approved relevant requisition/ acknowledgement forms for different ICT
request/operation/services.
xvii. Annual Fire Drill Report.
xviii. ICT Risk Management Framework
2.4 Internal Information System Audit
a. Internal Information System (IS) Audit shall be carried out by Internal Audit of the bank. Internal IS audit
shall be conducted by personnel with sufficient IS Audit expertise and skills.
b. IT Security Unit will coordinate with IS audit team for performing Vulnerability Assessment (VA) and
Penetration Test (PT).
c. Computer-Assisted-Auditing Tools (CAAT) may be introduced in the process to perform IS audit
planning, monitoring/auditing, control assessment, data extraction/analysis, fraud
detection/prevention and management.
d. Internal Information System audit shall be done once in every one year. The report must be preserved
as ready reference for Bangladesh Bank and Audit Committee.
e. Banks should also ensure that audit issues are properly tracked and, in particular, completely recorded,
adequately followed up and satisfactorily rectified.
f. An annual system audit planned to be developed covering critical/major technology-based
services/processes and ICT infrastructure.
g. The branch shall take appropriate measures to address the recommendations made in the last Audit
Report. This must be documented and kept along. IC&C Division shall also ensure that audit issues are
properly tracked, recorded, adequately followed up and satisfactorily rectified.
h. The branches shall take appropriate measures to address the recommendations made in the last Audit
Report. This must be documented and kept along with the Audit Report.
2.5 External Information System Audit
a. TBL may engage external audit for their information systems auditing in-line with their regular IS audit.
The external audit report shall be preserved for regulators as and when required.
b. The audit report shall be preserved for regulators as and when required.

2.6 Standard Certification and License
a. IT Division should obtain standard certification or license whichever is required for the services that are
associated with Microsoft platforms (Windows OS and Office), Card Platform, Clearing/BACH, Core
Banking Software and Mobile Banking Platform.
b. Additionally, exposed/public portals issues such as Website, Internet Banking, Mobile Banking,
Payment Card Data etc. also need standard certification and licenses like SSL and HTTPS etc.
c. Upon approval, IT Division may introduce other certification and licenses which are necessary for
inclusion for new system or platform on prior approval if required. In this regard, IT Division should
place budgetary approval and implementation plan to appropriate authority (i.e. MD/EC/BoD) for
deploying or renew of license/certificate.

Chapter 3
3.0 ICT Risk Management
IT Risk is a growing component of total Operational Risk. As business increasingly depend on IT to automate
processes and store information, IT Risk Management is emerging as a separate practice. Organizations across
sectors and industries have begun to consolidate functions to develop a more comprehensive, focused approach
to IT Risk. IT Risk includes security, availability, performance and compliance elements, each with its own drivers
and capacity for harm.
Considering the circumstances the major factor of IT Risk Management includes Management of IT assets and
configuration and change processes as particular problem are as Best-in-class IT Risk management requires a
disciplined approach that includes IT Risk awareness, quantification of business impacts, solution design and
implementation across people, process, and technology, and creation of a sustained IT Risk Management
program complete with performance measurement and a model for continuous improvement.
Effective risk management system will be in place for any new processes and systems as well as a post‐launch
review. The risk management function should be ensured awareness of, and compliance with, the ICT security
control policies, and to provide support for investigation of any ICT related frauds and incidents.
3.1 ICT Risk Governance
a. An ICT Risk Management Committee should be formed to govern the overall IT security risks and
relevant mitigation measures. The committee will be formed with representatives from AD, IT Security
Unit, IT, RMD, Operations and IC&C.
b. The ICT Risk Management Committee shall formulate “ICT Risk Management Policy” for the bank. The
policy shall include the followings for Risk Governance:
i. Risk Appetite and Risk Tolerance shall be reviewed and approve especially for new technology,
new organizational structure, new business strategy and other factors require the enterprise to
reassess its risk portfolio at a regular interval. Risk Appetite shall be in terms of combinations of
frequency and magnitude of risk to absorb. Similarly, Risk Tolerance which needs to define
tolerable deviation from the level set by risk appetite. Such defined appetite and tolerance needs
approval from the Board/ICT Risk Management Committee and dearly communicated to all
stakeholders.
ii. Risk Ownership shall be defined to individuals for ensuring successful completion. Risk
accountability shall state the owner with required resources and have the authority to approve
the execution and/or accept the outcome of an activity within specific IT Risk processes.
iii. Risk measurement needs to be formulated for understanding of the actual exposure to IT risk by
Open Communication, enabling definition of appropriate and informed risk responses.
iv. Risk criteria with risk grading for each event should be developed. A procedure shall be defined
to external stakeholders regarding the actual level of risk and risk management processes in use.
v. Risk Awareness for well understanding and recognized as the means to manage risks. TBL shall
aware amongst all internal stakeholders of the importance of integrating risk and opportunity in
their daily duties. Moreover, TBL shall be transparent to external stakeholders regarding the
actual level of risk and risk management processes in use.
c. IT Security Unit shall report status of identified ICT security risk to the ICT Security Committee and ICT
Risk Management Committee as and when required.
3.2 ICT Risk Assessment
a. Meaningful IT risk assessments and risk-based decisions require IT risks to be expressed in unambiguous
and clear, business-relevant terms. Effective risk management requires mutual understanding between
IT and the business over which risk needs to be managed. All stakeholders must have the ability to
understand and express how adverse events may affect business objectives.
Risk assessment is a term used to describe the overall process or method to:
 Identify hazards and risk factors that have the potential to cause harm (hazard identification).
 Analyze and evaluate the risk associated with that hazard (risk analysis, and risk evaluation).
 Determine appropriate ways to eliminate the hazard or control the risk when the hazard
cannot be eliminated (risk control).
b. The primary objective is to leverage the internal audit function by shifting some of the control
monitoring responsibilities to the functional areas (Branches & Head Office). This is to enhance audit's
responsibilities. Self-assessment shall be implemented by the Management and employee of Head
Office & Branch. The IT Risk Policy shall have to include the followings for risk assessment:
i. Business impact analysis for understanding the effects of adverse technology related events
ii. Risk Factors those influence the frequency and/or business impact of risk scenarios. Risk
factors shall be interpreted as casual factors of the scenario that is materializing, or as
vulnerabilities or weaknesses.
iii. Risk Scenarios to identify the important and relevant risks. The developed risk scenarios can
be used during risk analysis where frequency and impact of the scenario are assessed. Risk
Scenario needs to include:
 Description of threat related risks
 Identification of existing controls vulnerabilities
 Determine likelihood of occurrence and severity of impact
 Determine risk level of threat
 Identify potential level of risk respect to data confidentiality, integrity, and availability
iv. Risk Assessment of critical ICT assets shall be done once in every one year or whenever
requires. The report must be preserved as ready reference for Bangladesh Bank and ICT Risk
Management Committee.
3.3 ICT Risk Response

a. Risk response is to bring measured risk in line with the defined risk tolerance level for the
organization. In other words, a response needs to be defined such that as much future residual risk
as possible falls within risk tolerance limits. When the analysis shows risks deviating from the defined
tolerance levels, a response needs to be defined. This response can be any of the four possible ways
such as Risk Avoidance, Risk Reduction/Mitigation, Risk Sharing/Transfer and Risk Acceptance.
b. The ICT Risk Management Committee shall give effort to implement measure and report different
indicators to ICT Security Committee that are equivalent in sensitivity. The committee shall strengthen
overall ICT risk management practices with sufficient risk management processes.
c. The IT Risk Policy shall have the following regarding the ICT Risk Response:
i. Set of metrics to serve as risk indicators. Indicators for risks with high business impact are most
likely to be Key Risk Indicators (KRIs). The KRIs are:
 Provide an early warning for a high risk to take proactive action
 Provide a backward-looking view on risk events that have occurred
 Enable the documentation and analysis of trends
 Provide an indication of the risk's appetite and tolerance through metric setting
 Increase the likelihood of achieving the strategic objectives
 Assist in continually optimizing the risk governance and management environment
ii. Define Risk response procedure to bring risk in line with the defined risk appetite after risk analysis.
iii. Control measures intended to reduce either of an adverse event and/or the business impact of an
event.
iv. Process for share or reduce Risk frequency or impact by transferring or otherwise sharing a portion
of the risk, e.g. insurance, outsourcing.
d. For critical risk response, the issues may be forward to Computer Emergency Response Team (CERT).
For unsolicited risk responses from CERT, the risk may be transferred to third party along with following
strategy with prior approval from the appropriate authority (i.e. MD/EC/BoD):
i. Transferring risk involves finding another party who is willing to take responsibility for its
management, and who will bear the liability of the risk should it occur.
ii. The aim is to ensure that the risk is owned and managed by the party best able to deal with it
effectively.
iii. Risk transfer usually involves payment of a premium, and the cost‐effectiveness of this must be
considered when deciding whether to adopt a transfer strategy in ad-hoc basis.
iv. This strategy is adopted when it is not possible or practical to respond to the risk by the other
strategies, or a response is not warranted by the importance of the risk.

Chapter 4
4.0 ICT Service Delivery Management
IT Operation Management covers technology procedure supervision including capacity management, request
management, change management, incident and problem management, asset management, operating
environment events and request management. Trust bank’s objective is to achieve the peak levels of technology
service excellence by minimum outfitted risk.
4.1 Change Management
Change is defined as anything—hardware, software, system components, services, documents, or processes—

that is deliberately introduced into the production environment and which may affect a service level or
otherwise affect the functioning of the environment or one of its components.
All change request by the branch or division should be processed through Business Committee for approval first.
Business Committee should prepare Business Requirement Document (BRD) which needs to cover the process
of any specific change, requirements of system changes and the impact that will have on business processes,
security matrix, reporting, interfaces, etc.
4.1.1 Change and Configuration Management Policy
a. Change Control
To effectively manage information resources, initial or baseline configurations of the information
resources, change management must be established prior to deployment.
b. Configuration Control
Configurations of information resources must be periodically reviewed to identify new vulnerabilities
and security requirements.
c. Standard Configuration
Standard configurations of hardware and software must be used to maintain a high level of information
security, enable cost-effective and timely maintenance and repair, and protect the information
resources against unexpected vulnerabilities.
d. Up gradation of software tools and database:
Change of technology may be required. In-house software requirement is approved from appropriate
authority.
e. General Controls
i. Initiating from a central management console.
ii. Providing scheduling, desktop management, standardization tools to reduce the costs associated
with distribution and management.
iii. Providing ongoing deployment for both new and legacy systems in mixed hardware and OS
environments.
iv. Scanning the entire network (IP address by IP address) and providing information such as service
pack level of the machine, missing security patches, key registry entries, weak passwords, users
and groups, and more.
v. Analyzing scan results using filters and reports to proactively secure information resources (e.g.,
installing service packs and hot fixes, etc.).
vi. Audit trails shall be maintained for business applications.

4.2 Incident Management
An incident occurs when there is an unexpected disruption to the standard delivery of ICT services. The Bank
should appropriately manage such incidents to avoid a situation of mishandling that result in a prolonged
disruption of ICT services.
4.2.1 Computer Emergency Response Team (CERT)
a. CERT shall be established and staffed to manage and respond to information security incidents.
b. The team shall be formed with representatives from IT Division, IT Security Unit and RMD with necessary
technical and operational skills to handle major incidents.
c. Information security incidents or events shall be reported in a timely manner to the required parties to
enable proper review of vulnerable controls and establishment of appropriate corrective measures in
order to reduce the likelihood of recurrence.
d. The team shall be responsible for specific event resolution and submit a post incident report to Head of
IT and IT Security Unit. IS Audit team and Head of IT Security Unit shall review all incident report for
compliance.
e. The team shall initiate incident response procedures in the event of a security incident to contain the
incident, protect the confidentiality and integrity of the Bank’s information and information resources.
f. As incidents may trail from numerous factors, root¬ cause and impact analyses need to be performed for
major incidents which result in severe disruption of ICT services. The team shall be responsible for
processing all incident reports and all follow up activities. The incident reports shall cover:
i. Identify and analysis of the root cause
ii. Analyze impact analysis covering:
 Extent of the incident including information on the systems, resources, customers that were
affected;
 Magnitude of the incident including foregone revenue, losses, costs, investments, number of
customers affected, implications, consequences to reputation and confidence;
 Breach of regulatory requirements and conditions as a result of the incident.
iii. Corrective and Preventive Measures
 Immediate corrective action to be taken to address consequences of the incident. Priority
shall be placed on addressing customers' concerns.
 Measures to address the root cause of the incident.
 Measures to prevent similar or related incidents from occurring.
iv. Summarizing the causes
v. Frequency and damage assessments of information security incidents.
vi. Define incident severity levels
g. The management shall arrange necessary training for managing and working as response team.
h. The team will be reshuffled at a particular interval of minimum once in a year.
i. In some situations, major incidents may further develop adversely into a crisis. Senior management shall
be kept apprised of the development of these incidents so that the decision to activate the disaster
recovery plan (DRP) can be made on a timely basis.
4.2.2 Incident Management Policy
a. Information Processing Systems shall be protected against events that may jeopardize information
security by contaminating, damaging, or destroying information resources.
b. An Incident Management Framework shall be developed by Bank’s IT Security Unit and RMD for
incident management. The framework needs to cover:
i. Definition of Information security incidents or events

ii. Objective of restoring normal ICT service with minimal impact to the business operations.
iii. Roles and responsibilities of employee involved in the incident management process (includes
recording, analyzing, remediating and monitoring incidents)
iv. Procedures to respond to reported incidents
v. Criteria for appropriate assessing severity levels of incidents
vi. Escalation and Response plan (testing on periodic basis)
vii. Escalation and Resolution procedure with proportionate timeframe
viii. Corrective and Preventive Measures
c. Reportable information security incidents shall be defined and communicated to respective parties
including all employees in order to enhance the knowledge of personnel with regard to security
incidents.
d. Adequate security measures shall be established to ensure that Information security related incidents
are detected and prevented in a timely manner.
e. IT Division shall follow the procedures set by CERT and accordingly respond to incidents in a timely
manner to protect the information resource(s) at risk.
f. Criteria shall be defined to aid the escalation of incidents up to the management chain based on the
defined criteria.
g. Customers should be made aware of any major incident as decided by the Management.
h. It is important that incidents are accorded with the appropriate severity level. As part of incident
analysis, CERT should determine the incident severity levels and recommend appropriate actions.
Concerned officers/executives may be trained to determine incidents of high severity level.
4.3 Problem Management
The aim of problem management is to determine and eliminate the root cause to prevent the occurrence of
repeated incidents. Problem management looks at wide-spread or recurring incidents and determines root
causes. Problem management can also prescribe changes in order to provide temporary workaround solutions
or to address the underlying problems.
4.3.1 Objective of Problem Management
The goal of problem management is to reduce the number and business impact of problems. The problem
management system ensures that problems are not only resolved, but also investigated to prevent recurrences
by establishing the root cause of incidents and then initiate actions to improve or correct the situation. The
objectives of Problem Management are to:
a. Proactive prevention of Incidents and Problems

b. Elimination of recurring Incidents
c. Understanding the root cause of Incidents so that corrective action can be undertaken
d. Reduce loss of business caused by application outages
e. Provide an audit trail of problems
f. Increase recovery time
g. Provide escalation procedures
h. Coordinate with Change Management
4.3.2 Problem Management Policy
While the objective of incident management is to restore the ICT service as soon as possible, the aim of problem
management is to determine and eliminate the root cause to prevent the occurrence of repeated incidents. The
problem management policy shall cover:
a. Any incident that is marked with different problem severity level

b. Any wide-spread or recurring incident
c. Any incident that involves an interruption to application or infrastructure services, any incident that
prevents customers from accessing alter delivery channel.
d. Any incident that prevents employee from performing their normal activities.
4.4 Capacity Management
The goal of capacity management is to ensure that ICT capacity meets current and future business requirements
in a cost-effective manner and to ensure that adequate capacity is available and that best and optimal use is
made of it to meet required performance needs.
IT Security Unit and IT Division shall ensure that the use of resources is monitored, tuned, and projections made
of future capacity requirements to ensure the adequate system performance.
4.4.1 Capacity and Performance Management
This addresses the control over the IT process of managing the performance and capacity of information systems
that satisfies the business requirement to ensure that adequate capacity is available and that best and optimal
use is made of it to meet required performance needs. It is enabled by data collection; analysis and reporting on
resource performance, application sizing and workload demand and takes into consideration:
a. Availability and performance requirements

b. Automated monitoring and reporting
c. Resource availability
d. Hardware and software price/performance changes
4.4.2 Performance Monitoring of IT Resources
IT Division shall ensure that the performance of IT infrastructure resources is continuously monitored and
exceptions are reported in a timely and comprehensive manner. The monitoring of such activity can be
conducted using licensed tool or by means of a separate hardware. The following holds:
a. Central management and monitoring of performance, utilization response rate and status of all
LAN/WAN Links connecting all clients, Head Office and information system location shall be done
multiple times daily from the Date Center.
b. Managing and monitoring of performances of critical application in the bank’s information system shall
be done centrally.
c. Managing and monitoring of performance of all application and file servers shall be done on regular
interval.
d. There shall be detail monitoring of all processes and implementation of appropriate thresholds to
determine and plan additional resources to meet operational and business requirements effectively.
4.4.3 Capacity Planning of IT Resources
IT Division shall review hardware performance and capacity to ensure that cost-justifiable capacity always exists
to process the workloads. The capacity planning will be done in the following manner:
a. Monitoring and planning of capacity for databases hosting the Bank’s information system application
files shall be done once in a year.
b. Servers require particular attention, because of the much greater cost and lead time for procurement
of new capacity.

c. Monitoring and planning of capacity for e-mail server and user mailbox sizes shall be done on every
three (03) years.
d. Monitoring and planning of disk quota for hosted services shall be done every three (03) years.
e. There shall be a specific IT capacity planning for system which is as follows:
IT Resources Capacity Plan

Database Size Free space on server shall not be less than 20% total disk space
User E-Mail Boxes Shall not be greater than 2 GB for the largest user mailbox
User Domain Personal Folder Shall not be greater than 1 GB per user
Must be able to sustain all servers and critical system hardware for at
Online UPS
least 40 Min
Must be able to transfer data at a speed of 512 Kbps and up to 5 Mbps
WAN Communication Links
depending on Branch and ATM location and volume of transaction
Shall be able to support clients at a ratio to be specified by the IT Support
IT Support Personnel
Unit
Must be able to power all critical electrical appliances including air
Generating Set
conditioners at all times
Must be able to cater for next 5 years business growth and employee
New Branch LAN Setup
deployment from the date of opening.
f. When identified as availability requirements, IT Division shall ensure prevention of resources from
being unavailable by implementing fault tolerance mechanisms, prioritizing tasks and equitable
resource allocation mechanisms. There shall be timely acquisition of required capacity, taking into
account aspects such as resilience, contingency, workloads and storage plans.

Chapter 5
5.0 Infrastructures Security Management
Security means protection of Data and Equipment from Internal and External threats. Data, the priceless assets
of the Bank should be protected from any level of hackers. Infrastructures Security Management describes how
TBL will manage the procurement, configuration, operations, and maintenance of information resource
hardware and software, whether located in the Bank or at offsite premises, in a manner that ensures information
security. Technology (hardware and software) security shall be implemented and maintained with the
appropriate level of technical and administrative controls to protect technology and operations infrastructure
from intentional or unintentional unauthorized use, modification, disclosure, or destruction. Change control
procedures, virus protection procedures, and standard configurations of hardware and software must be
implemented to reduce the Bank’s exposure to unacceptable risks and vulnerabilities.
To avoid fraud and forgery data and equipment should be maintained in a secured manner. Priority should be
given at the highest level for the security aspects of data and equipment. Security Policy includes data, data
handling, user and access control of users, external attack, hardware and location & position of hardware. The
Bank shall establish necessary processes and technical controls to ensure that technology security is maintained
on its entire infrastructure.
5.1 Infrastructure Security Governance
a. IT Division and IT Security Unit shall be responsible for implementing the policy and securing of
servers/workstations.
b. IT Division shall be responsible for maintaining policies by setting standards and developing the security
processes and procedures.
c. IT Division shall be responsible for implementing processes and procedures.
d. The internal IT audit team shall review Audit trails and enforcement of the policy.
e. IT Division and IT Security Unit will jointly conduct coordination with IS Audit Team for conducting VA
& PT.
5.2 Hardware and Software Security Policy

a. Information resources should use only hardware and software acquired from original and approved
sources by the Bank. IT Division shall comply with the terms of all software licenses and must not use
any software that has not been legally purchased or otherwise legitimately obtained.
b. Thorough testing of all new or modified hardware and software is required to ensure that there is no
adverse effect on the security of the information resources and duly confirmed by IT Division.
c. Vulnerabilities in hardware and software applications must be reviewed on periodic basis by IT Division
and IT Security Unit jointly. All vulnerability advisories involving the software and hardware in use
within the Bank information resources must be tracked.
d. Support & Delivery Department shall maintain an accurate inventory of the information resources. The
inventory management process must ensure accountability and must include current copies of
hardware and software maintenance agreements, licenses, purchase orders and serial numbers. IT
Division must remain updated on the list.
e. Only authorized employee can use, for approved purposes, diagnostic hardware and software that
enable the bypass of implemented security features, or allow network monitoring (e.g. network
scanning, sniffers).

5.2.1 Software Modification and Code Review:
a. All software that can be modified must be managed through change control and management process
upon approval of Business Team.
b. Software containing modifications must be documented detailing the extent of the modifications. The
modifications must be fully reviewed, tested, documented, and installed in a controlled environment
to avert possible adverse effects on the security of the production environment.
c. Custom programs that contain custom programming or scripts may be subject to an independent code
review. The independent code review will review the source code and documentation to verify
compliance with software design documentation and programming standards and to ensure the
absence of malicious code.
5.2.2 Updates & Patch Management
a. Successful Patch Management requires a robust and systematic process. The Patch Management
Lifecycle involves a number of key steps: preparation, vulnerability identification and patch acquisition,
risk assessment and prioritization, patch testing, patch deployment and verification.
b. Testing team of IT Division shall perform rigorous testing of security patches before deployment into
the production environment.
c. Information resources must use approved standard operating systems, including all approved updates
and patches. Operating systems must have controls in place to prevent a compromise of the integrity
of the computer operating system environment and must be configured to comply with operating
system security requirements.
d. Patches shall be rigorously tested in a non-production environment in order to check for unwanted or
unforeseen side effects;
e. A roll back plan shall be developed to include backing up the systems about to be patched to be sure
that it is possible to return to a known-good working configuration should something go wrong with
the patch and to ensure patches are installed properly, testing information resources after installation;
and documenting all associated procedures, such as specific configurations required.
f. Patch management shall be capable of highly granular patch update and installation administration (i.e.
treating patches and mainframes, servers, desktops, and laptops separately), Tracking machines, and
updating and enforcing patches centrally and verifying successful deployment on each machine.
g. Deploying client settings, service packs, patches, hot fixes, and similar items Bank wide in a timely
manner in order to address immediate threats.
5.3 Secure System Development Policy
a. Only the respective division/department/owner may request for software/system updates or

modification, and then only with the prior authorization of the Management. Procedures for
authorization should be provided either by email or some other documentation.
b. Software Manager of IT Division shall maintain a configuration control schedule for all operational
software and an audit log for all to updates to operational program libraries.
c. Software change management is carried out with an approval from appropriate authority/CAB.
d. Change management must be documented on Change Request Form which may include
Documentation of impact, management sign-off by authorized parties, testing of operational
functionality and back-out procedures.
e. There should be segregation in duties for development, testing and auditing. There should not be over
lapse of duties.
f. Previous versions of operational software are retained perpetually in the software repository server
with all necessary information as a contingency.

g. All system components and software will be ensured with latest vendor-supplied security patches
within a stipulated time frame and upon proper testing.
h. Physical or logical access is only given to suppliers shall be provided in line with an approved procedure.
i. The system configuration standards are reviewed as new vulnerabilities are found.
j. Software applications development is based on industry best practices and incorporates information
security throughout the software development life cycle.
5.4 Laptop Policy
a. Laptops will be provided to selected employees (e.g. Executives, Auditors, Managers, IT Officials etc.).
b. A request form needs to be filled for a laptop with proper justification by his Head of Division to
purchase and procurement Division.
c. User will take all reasonable measures to ensure the physical and digital security of the laptop like
locking the laptop in a secure location when it is not in use, changing the password as often as required
by User.
d. The laptops need to be in TBL domain system and have antivirus system installed with updated
definition. User will not install personal software on laptop.
e. If a laptop is lost or damaged by the employee, an amount equal to its depreciated value will be
deducted from his salary and a new one will be given to him as per procedure.
f. In the event of termination, retirement, Laptops must be returned to IT Division.
g. Obsolete laptops will be returned to IT Division. After sensitive data removal IT Division may dispose it
with GSSD.
5.5 BYOD Controls
a. The use of all personal portable/external storage devices e.g. smartphones, laptops, USBs is prohibited;
b. For emergency onsite support by vendors they may connect to TBL guest network, which shall be
completely separated from corporate network.
5.6 Device Controls (Desktop and Laptop)
a. To prevent damage of data and hardware, all Desktop and Laptop computers should be connected to
online or offline UPS.
b. Users are applying the “lock workstation feature” (ctrl/alt/delete, enter) when leaving a desktop or
laptop for unattended computers.
c. Password protected screen saver shall be used to protect Server, Desktop and Laptop from
unauthorized access. This period should not be more than One (01) minutes.
d. Confidential or sensitive information that stored in laptop and desktop must be encrypted.
e. All employees of the bank are responsible to turn off their personal Desktop/Laptop computers and
monitors at the end of each workday. When laptop computers are actively connected to the network
or information systems, these are not left unattended.
f. Laptop computers are stored by its authorized user. Computer media and several removal storages (e.g.
diskettes, CD ROMs, zip disks, pads, flash drives) shall be controlled.
g. Other information storage media containing private data such as paper, files, tapes, etc. are stored as
a tape backup or CD backup in a protected location or locked cabinet when not in use.
h. Individual users do not have authority to install or download software applications and/or executable
files to any desktop or laptop computer without any prior authorization. Please note that only
designated personnel from hardware or network department have privilege to installation or
download.

i. Desktop and laptop computer users are strictly prohibited via traceable user authorization parameters
to write, compile, copy, knowingly propagate, execute or attempt to introduce any computer code
designed to self-replicate, damage, or otherwise hinder the performance of any computer system.
j. Standard virus detection software must be installed on all desktop and laptop computers and should
be configured by Bank’s IT Division. Virus definition of the antivirus system must be update
automatically and from a central server or service point of domain.
k. Without any instruction from IT Division, Virus guard software or OS firewall should not be deleted or
disabled from Desktop and Laptop computers without expert assistance.
l. User Identification (ID) and authentication (password) will be required to access all desktops and
laptops whenever turned on or restarted. All laptop and desktop must be in domain.
m. Desktop and laptop computers should be configured to log all significant computer security relevant
events. (e.g. password guessing, unauthorized access attempts or modifications to applications or
systems software.)
n. Outside internet modem software and device shall not install in workstation.
o. All computers will be placed above the floor level and away from windows.
5.7 Security Baseline

Security baselining means both the configuration of Trust Bank Ltd.'s IT environment to confirm to be consistent
with standard levels and identification of what constitutes typical behavior on a network or computer system.
The baselining process involves hardening the key components of the IT architecture of the TBL to reduce the
risks of attack. Security baselining is comprised of hardening OS, network and DB.
5.7.1 Server Virtualization

a. TBL shall plan of setting limit on the use of resources (e.g., processors, memory, disk space, virtual
network interfaces) by each VM.
b. Host and guest Operating System (OS) must be updated with new/required security patches and other
patches if necessary. Patching requirements shall also be applied to the virtualization software.
c. Like physical servers, virtual servers need to be backed up regularly.
d. It shall be ensured that host and guests use synchronized time.
e. File sharing shall not be allowed between host and guest OSs, if not required.
5.7.2 Operating System Hardening

The hardening of operating systems involves ensuring that the system of TBL is configured to limit the possibility
of either internal or external attack. While the methods for hardening vary from one operating system to another
the concepts involved are largely similar regardless of whether Windows, UNIX. Linux or any other system is
being baselined. Some basic hardening techniques are as follows:
 Non-essential services - TBL shall configure operating system to run the services required to perform the
tasks for which it is assigned.
 Patches and Fixes - As an ongoing task, it is essential that all operating systems be updated with the latest
vendor supplied patches and bug fixes
 Password Management - Most operating systems today provide options for the enforcement of strong
passwords. TBL shall ensure that users are prevented from configuring weak, easily guessed passwords.
 Unnecessary accounts - All guest, unused and unnecessary user accounts must be disabled or removed
from operating systems. It is also vital to keep track of employee turnover so that accounts can be disabled
when employees leave an organization.
 File and Directory Protection - Access to files and directories must be strictly controlled through the use of
Access Control Lists (ACLS) and file permissions.

 File and File System Encryption - Some file systems provide support for encrypting files and folders. For
additional protection of sensitive data, TBL shall ensure that all disk partitions are formatted with a file
system type with encryption features.
 Enable Logging-TBL shall ensure that the operating system is configured to log all activity, errors and
warnings.
 File Sharing - Any unnecessary file sharing need to be disabled.
5.7.3 Network Hardening

Network hardening can be achieved using a number of different techniques:
 Updating Software and Hardware - TBL shall ensure that all networking software together with the
firmware in routers are updated with the latest vendor supplied patches and fixes.
 Password Protection- TBL shall ensure that all the routers and wireless access points are protected with
strong passwords and relevant security.
 Unnecessary Protocols and Services - All unnecessary protocols and services must be disabled and, ideally,
removed from any hosts on the network. For example, in a pure TCP/IP network environment it makes no
sense to have AppleTalk protocols installed on any systems.
 Ports - All the unused ports must be blocked by a firewall and associated services disabled on any hosts
within the network.
 Wireless Security - Wireless networks must be configured with highest available security level like with
WPA, WPA2 or any higher available level.
 Restricted Network Access - TBL shall ensure that proper steps are taken to prevent unauthorized access
to internal networks. The first line of defense should involve a firewall between the network and the
internet. Other options include the use of Network Address Translation (NAT) and access control lists (ACLs).
Authorized remote access should be enabled through the use of secure tunnels and virtual private networks.
5.7.4 Database Hardening

Database hardening can be achieved using a number of different techniques:
 Physical Database Server Security- The physical machine hosting a database of Trust Bank Ltd. should be
housed in a secured, locked and monitored environment to prevent unauthorized entry, access or theft.
 Firewalls for Database Servers- The database server of Trust Bank Ltd. must be located behind a firewall
with default rules to deny all traffic. The database server firewall is to be opened only to specific application
or web servers. Firewall rule change control procedures should be in place and notification of rule changes
should be distributed to System Administrators (SAs) and Database Administrators (DBAs). Firewall rules for
database servers are to be maintained and reviewed on a regular basis by SAs and DBAs.
 Database Software- Database software need to be patched to include current security patches. Provisions
are to be made to maintain security patch levels in a timely fashion. Application/Web Servers/Application
Code- Destination systems receiving in scope data should be secured in a manner commensurate with the
security measures on the originating system. All servers, applications and tools that access the database
need to be documented. Configuration files and source code are to be locked down and only accessible to
required OS accounts. Application code is preferred to be reviewed for SQL injection vulnerabilities. No
"Spyware" is allowed on the application, web or database servers.
 Administration Accounts/Permissions/Passwords- DBAs will review all requested script and database
changes to ensure the security of the system is not compromised. Accounts with system administration
capabilities are to be provided to as few individuals as is practical, and only as needed to support the
application. Passwords for all DBA operating system accounts and database accounts have to be strong
passwords, and must be changed when administrators/contractors leave positions.
 User Database Roles / Permissions / Passwords / Management & Reporting- Secure authentication to the
database must be used. Only authorized users should have access to the database. Strong passwords in the
database are to be enforced when technically possible, and database passwords need to be encrypted when
stored in the database or transmitted over the network. Applications should manage user permissions and
auditing to meet the Data Owner's requirements. A report of all access rights for users need to be provided
to the data by the DBAs on a regular basis.
 Database Auditing- All logins to operating system and database servers, successful or unsuccessful, must
be logged. Database objects with in scope data should have auditing turned on where technically possible.
Audit logs are to be reviewed regularly by appropriate authority. These requirements and the review
process need to be documented. Accounts that are locked due to maximum database login failures should
trigger an automatic notification to the security administrator(s) responsible for this system.
 Database Backup & Recovery- The backup and recovery procedures need to be documented Backup and
recovery procedures are to be tested periodically. Backup retention intervals should be documented and
has to be sufficient to meet the business resumption requirements and expectations of the data owner.
 Database Encryption & Key Management- In scope data has to be encrypted during transmission the
network. If database-level encryption for in scope data is implemented, procedures for secure key
management need to be documented. For data subject to disclosure that is encrypted at storage, the means
to decrypt must be available to more than one person and approved by the data owner. Key management
procedures for decrypting backups need to be documented, available to more than one person and
approved by the data owner.
5.8 Data Encryption
a. Encryption is the process of converting information using an algorithm to make the information
unreadable to anyone except those possessing the decryption key required.
b. For Data encryption, Crypto Technology and VPN technology will be engaged to encrypt and decrypt
sensitive data travelling through WAN or Public network. TBL may engage other certified technology
on requirement for out bounding data security.
5.9 Cryptography
a. Confidential or sensitive information that stored in laptop may be encrypted.

b. TBL shall ensure that network devices like Router may be configured Cryptography policy to protect
from outsider. When Cryptograph keys are being used or transmitted, it may be ensured that these
keys are not exposed during usage and transmission.
c. Latest version of TLS (Transport Layer Security) should be used on all servers. All previous instances of
SSL Version 2 and 3 Protocol should be disabled. Cryptograph keys may be used for a single purpose to
reduce the impact of an exposure of a key. If a key is compromised, it may be immediately revoked,
destroyed and replaced the key and all keys encrypted under or derived from the exposed key.
d. In the event of changing a Cryptographic key, TBL may generate the new key independently from the
previous key.
5.9.1 Cryptographic Key Management

a. Strong cryptographic keys are generated and documented by the Bank’s process. A fully automated
process may be in use.
b. Cryptographic keys are distributed securely via documented process.
c. Access to keys SHALL be restricted by the Head of IT to the fewest number of custodians considered
necessary to ensure security and enable the organization to function effectively.
d. Cryptographic keys are stored securely in encrypted format and key-encrypting keys are stored
separately from data-encrypting keys.
e. Cryptographic keys SHALL be changed periodically especially at the end of the defined life using best
practice guidelines pre-defined by the Bank.

f. Compromised keys SHALL be replaced immediately by the employee responsible. The Head of IT is
responsible for the retirement of old keys, archived keys are secured / stored at the Bank’s pre-defined
location and destroyed securely when no longer required.
g. Split knowledge and dual control of keys SHALL be used for manual key generation.
h. Unauthorized substitution keys are prevented via physical and logical access to the key generating
procedures and mechanisms. Procedures SHALL be developed to define these physical and logical
access controls.
i. Key custodians must sign the key custodian form specifying that they understand and accept their key
custodian responsibilities.
5.10 Vulnerability Assessment (VA) and Penetration Testing (PT)
The vulnerability scan (or even a vulnerability assessment) looks for known vulnerabilities and reports potential
exposures. A penetration test is designed to actually exploit weaknesses in the architecture of TBL systems.
a. IT Security Unit shall conduct VA & PT scan of ICT infrastructure on periodic basis to detect potential
security vulnerabilities
b. An external vulnerability scan may be conducted from outside the TBL Network. Internal vulnerability
scan shall conduct from inside the Trust Bank Limited on period basis.
c. A combination of automated tools and manual techniques shall be deployed to perform a
comprehensive VA. For web- based systems, the scope of VA shall include common web vulnerabilities
such as SQL injection, cross-site scripting etc.
d. A process shall be established by IT Security Unit to remedy issues identified in VAs and perform
subsequent validation of the remediation to validate that gaps are fully addressed.
e. Penetration test shall be conducted with proper backup taken of all the servers or systems that would
be associated during the test.
5.11 Network Security Management

5.11.1 Network Access Control
This section describes how the Bank secures access to TBL’s networks to ensure that confidentiality, integrity
and availability are maintained. It applies to all information that the Bank collects, stores, processes, generates
or shares to deliver services and conduct business, including networks from external partners and clients
connecting to the Bank’s information systems and networks.
The Bank shall apply Network Access Control mechanisms to authenticate and filter where possible network
connections connecting to its network either from CLIENTS or PARTNERS who works with the Bank to ensure
against unauthorized access and security of its networks, information and information systems.
a. IT Division will ensure Network Design Should to be well documented and implemented under a
documented plan.
b. Access should be restricted and controlled by Network Admin. Network equipment should be housed
in a secure environment and should be checked and monitored.
c. Network security devices, such as firewall as well as intrusion detection and prevention system must
be installed to protect the network perimeters.
d. Groups of information services, users, and information systems should be segregated in networks.
e. Unauthorized access and electronic tampering should be controlled strictly by IT Division.
f. The Network team is responsible to ensure that redundant communication links will be used for WAN.

g. Access control to such devices should be enabled to prevent unauthorised access/update to device
configurations. Authorization procedures are used to ensure that users only have access to those
services and networks which are appropriate for their role and to their business needs.
h. Secure Login feature (i.e. SSH) shall be enabled in network devices for remote administration purpose.
Any unencrypted log in option like TELNET must be disabling in network devices.
i. All passwords must be encrypted in network devices.
j. Authentication Authorization and Accounting (AAA) server must be established in network device to
manage the network devices effectively.
k. All default passwords of network devices must be changed.
l. SYSLOG Server may be established to monitor the logs generated by network devices.
m. All network device configuration backups needs to be taken on period basis and whenever there is
change applied to the existing configuration (system software, rules, etc.). Backups need to be stored
in a safe place and should only be accessible to authorized personnel.
n. Role based administrative shall be ensured for network devices.
o. Role-based Access Control Lists (ACLs) shall be implemented in the routers and switch to control
network traffic.
p. In case of dual connectivity failure, branches (only remote) may use modem with VPN to continue
transactions after necessary approval from IT Division. In such case, the use modem shall be
discontinued immediately upon restoration of network link.
5.11.2 Network Administration and Maintenance
a. Network administrators shall regularly monitor for software updates for firewall/router to block attacks
that can exploit known vulnerabilities
b. Network administrators need to verify regularly of the systems integrity (namely the removal or change
of files).
c. Before any change of configuration is implemented on a Server or an active device (Router, Switches,
Firewalls, etc.), there must be a documented approval for the change. A sign off from the other concern
department may also be in place before such changes are implemented.
d. Changes records of firewalls and routers shall follow proper change management process and duly
authorized.
e. Configuration of devices, including permitted protocols and services shall be documented.
f. Periodic review of Firewall and router rule sets and when there is any change to network diagram.
g. Daily monitoring of Network device logs.
5.11.3 Backup and Log Inspection
a. All network device configuration backups need to be taken on monthly basis and whenever there is
change applied to the existing configuration (system software, rules, etc.). Backups need to be stored
in a safe place and should only be accessible to authorized personnel.
b. There shall be unchanged records of abnormal events to allow for their reconstruction.
c. Network administrators will be notified within a reasonable time whenever a significant incident needs
attention (i.e. intrusion, disk full, etc.)
d. After every configuration change of any firewall/router, a revision to the rules and configuration must
be performed, and the changes should be tested both internally and externally.
e. Revisions to the firewall/router rules must be performed periodically. These revisions need to be
performed at least once in a year.

5.12 Internet Access Management
The Internet is an unregulated environment. Network team of IT Division shall filter Internet access as per policy
and will not be liable for any material viewed or downloaded by users that violates its Information Security Policy
or any other statutory or regulatory compliance. Users shall be individually accountable for their actions over
the Internet. Use of the Internet must be consistent with the Bank’s standard for business conduct and must
occur as part of the normal execution of the employee’s job responsibilities.
a. Access to the Internet is provided for banking business purposes only. A form needs to be filled
(Annexure- 1).
b. Internet will be provided to selected employees (e.g. all Department/Division Heads, Executives,
Managers, Credit/Fex, IT Officials etc.) with need to know basis and approval from Head of Division.
c. Employee should not make inappropriate use of their access to the Internet. They must not use Bank
systems to access illegal or other improper material.
d. All download may be blocked as per Management decision. If any download requires proper request of
download may submit to IT division.
e. Employee should not subscribe to chat rooms, dating agencies, messaging services or other on-line
subscription Internet sites unless they pertain to work duties.
f. Programs, including screensavers, must not be downloaded from the Internet without authorization
from the management. All desktop and laptop screen must contain Trust Bank logo.
g. IT Security Unit may monitor Internet usage by employees.
h. Abuse of Internet access will be dealt with severely relative to seriousness. Minor abuse will lead to
removal of the privilege of access from an individual’s workstation.
i. Vendors requiring temporary internet may be granted access through separate Wi-Fi, which is not
connected to corporate LAN.
j. Official documents should not be stored in any cloud storage like Google Drive, Dropbox etc.
5.13 Email Management
a. All employees should have his/her personal email address with Username and Password at the time of
joining (Annexure 1).
b. Mail Server size will be within 02 GB for each employee. User cannot send attachment more than 10
MB file size. Only the original holder of the email is authorized to use an email for official purpose.
c. Every mail has to come from an Individual employee and he/she is responsible for his/her mail
according his responsibilities and job description.
d. All emails shall have an automatic footer that contains the appropriate legal disclaimer set out by the
Bank about confidentiality of the email content and users are prohibited from amending or deleting it.
e. Confidential material sent by e-mail should be so marked but sent only with caution.
f. Employee should minimize the number of messages in their email in-box to ensure maximum efficiency
of the delivery system. Folders should be set up and messages filed accordingly.
g. All workstation users may have email access as per their job responsibilities. Division Heads and Branch
Managers should ensure that there is no abuse of this privilege.
h. Email is to be used for banking business only. Bank confidential information must not be shared outside
of the bank without authorization. Users are also not to conduct personal business using the computer
or email.
i. Corporate email address must not be used for any social networking, blogs, groups, forums, etc. unless
having management approval.
j. TBL email system is not to be used for the creation or distribution of any offensive, or disruptive
messages, including messages containing offensive comments about race, gender, age, sexual
orientation, pornography, religious or political beliefs, national origin or disability.

k. The email system must not be used to send illegal or inappropriate material. Users shall not use
profanities, obscenities, or derogatory remarks in email messages regarding employees, customers,
competitors, or others.
l. Bank retains the right to access and view all Emails sent and received by the Email system. This right is
exercised solely through the IT Division on the instructions of Managing Director.
m. Users’ mailbox shall be retained five (05) years online and later archived for compliance reference.
5.14 Virus and Malicious Code Protection
Malicious Codes (Viruses, Worm, Spyware, Rootkit etc.) are unwanted program that cause malicious damage to
various systems. Anti-Virus software helps to identify, delete or prevent these Malware and quarantine them as
appropriate. Anti-virus software must be updated frequent as per policy because new viruses are being released
almost on a daily basis. This section describes how the Bank establishes appropriate controls against malicious
codes, virus, Trojans and various malwares.
a. All machines, networked and standalone computers, should have up-to-date anti-virus protection
whether it is connected to network or not for malicious code protection.
b. Antivirus software should be updated with the latest virus definition file. All computers in the network
will get updated signature of anti-virus software automatically from the server at a predefined
schedule on all workstations of TBL.
c. Software and data supporting critical business activities must be regularly scanned or searched to
identify possible malicious code. Files received on electronic media of uncertain origin or unknown
networks must be checked for malicious code before use. Attachments to electronic mail must be
checked for malicious code before use.
d. Awareness program will be arranged for the users about computer malware and their prevention
mechanism to ensure that users receive adequate training on anti-malware responses, including
opening of mail attachments, and on identifying possible hoaxes.
e. The installation of anti-virus software on all machines is the responsibility of the IT Division. A formal
process for managing attacks from malicious code must include procedures for reporting attacks and
recovering from attacks.
f. Employee should virus-scan all media (including zip disks and CDs) before first use. The IT Division will
provide assistance and training where required.
g. On detection of a virus, employee should notify the IT Division who will provide assistance. Under no
circumstances PC user of Bank should not attempt to disable the virus scanning software.
h. The CERT team shall be responsible for incident management, for gathering information about any
cases of non-compliance with this policy.
5.15 Security Device Management
The objective of this policy is to define a security policy for all Firewalls/Routers and other network security
devices to ensure that the production network traffic is controlled through the definition of rules that permit or
deny access to the information transmitted over the network.
Moreover, standard security configuration is required for each and every network component This included
bank’s own network equipment, manage solution equipment and wireless devices.
5.15.1 Baseline for System Configuration
a. Prior to installing a system on the network, all vendor-supplied defaults (including but not limited to
passwords, simple network management protocol (SNMP), and community strings) shall be changed
and unnecessary accounts eliminated.
b. Wireless environments should have the following measures implemented on all wireless devices:
 Vendor defaults changed, including encryption keys, passwords/passphrases and SNMP
community strings.
 Firmware is updated to support strong encryption for authentication and transmission.
c. IT Division shall address server functions to ensure those which require different security levels, or that
may introduce security weaknesses to other functions are not present upon the same server.
d. Where virtualization technologies are used, only one primary function is implemented per virtual
system component or device.
e. All unnecessary and insecure services and protocols shall be disabled. All unnecessary functionalities
including scripts, drivers, features, subsystems, file systems, and unnecessary web servers shall be
removed from system components.
f. All non-console administrative access to systems shall be encrypted.
5.15.2 Router & Firewall Usage
a. A firewall is required and is present at each internet connection and between any Demilitarized Zone
(DMZ) and the internal network.
b. It should be ensured that firewall will be in place on the network for any external connectivity. Regular
checkup and update of firewall is necessary by authorized personnel.
c. Perimeter firewalls are installed between any wireless networks and the cardholder data environment.
These firewalls are configured to deny or control any traffic (which has a valid business justification)
from the wireless environment into the cardholder data environment.
d. It shall be ensured all Internet traffic coming to and going from TBL network must pass through secure
gateway (i.e. Firewall, Proxy etc.) and other network devices. Only specific types of network traffic are
allowed beyond the organization’s exterior firewalls.
e. The firewall(s) shall be configured to block download of software from the Internet.
f. The file system database of the system should be stored in a secure way (offline or in a read only media).
After the installation of a network device or after any change to its configuration, it is necessary that
administrators perform testing to ensure that the firewall is working correctly. After any installation, a
hash of the configuration file should be preserved.
g. Bi-annual rule-set review shall be followed for firewalls and routers.
5.15.3 Router & Firewall Configuration
a. The allowed traffic for each application should be defined, and the firewalls and or routers explicitly
configured to accept only such traffic. The rules that impose the highest restrictions should be used. By
default, nothing should be allowed, and the permissions should be granted according to requirements.
All network services, protocols and ports should be disabled, except the ones that are strictly necessary.
b. Firewalls are configured, on the basis of the scope assessment and the analysis of data flows, to restrict
inbound and outbound traffic to that which is necessary for the data environment and to restrict
connections between untrusted networks and system components. All other inbound/outbound traffic
is specifically denied, e.g. using an explicit ‘deny all’.
c. Firewall and router configuration files are secured and synchronized, in that running configuration files
and start-up configuration files (used during re-boot), have the same, secure configuration.
d. The firewall performs stateful inspection (dynamic packet filtering) ensuring only established
connections are allowed into the network.
e. The Network team with coordination with DC Manager shall maintain firewall and router configurations
which lists services, protocols and ports necessary for business. If insecure services/protocols/ports are
necessary (e.g. FTP) exception approval or compensating controls shall be implemented.

5.16 Cyber Security Governance and Security Operations Centre
a. The Board of Directors through its committees shall have overall responsibility for the cyber security
program. It shall provide leadership and direction for effective conduct of the processes. The Board
shall ensure that cyber security governance is integrated into the organizational structure and relevant
processes.
b. The enterprise network infrastructure should be secured and protected against cyber threat with the
appropriate types of Firewall (Layer 7) with intrusion detection and prevention capabilities (IDS/IPS),
while encryption should be used to protect data in transit or in backup media.
c. Firewalls and IPS should protect internal network from unauthorized intruder in the network
perimeters, secure the card holder data environment and minimize the impact of security exposures
originating from third party or overseas systems, as well as from the internal trusted network.
d. An information Security Operations Centre (SOC) shall be established to address technology
vulnerability, contingency planning, 24 x 7 monitoring/visibility of enterprise network and processes to
facilitate prompt detection of unauthorized or malicious activities.
e. There shall have dedicated and secure physical space for the SOC to engender teamwork, brain-
storming, knowledge-sharing among members and quick response time. The SOC shall also be
protected with both technical and physical controls and equipped with necessary tools to keep the SOC
employee abreast of imminent cyber events.
f. The SOC shall be equipped with a Security Information and Event Management (SIEM) solution that
aggregates data from various security feeds to provide real-time analysis of security alert. Where
applicable, the SOC shall be able to perform prompt remediation service.
g. For intuitive correlations and prompt visibility of the bank‟ security posture, feeds to the SIEM shall
also include logs from network devices, vulnerability assessment systems; application and database
scanners; penetration testing tools; IDS/IPS; and enterprise antivirus system.
h. Logs shall be protected and retained for defined period to facilitate future investigation.
i. The SOC shall be up and manned continuously (24x7), managed and administered by skilled IT
professionals with technical knowledge, experiences and suitable credentials in areas such as operating
systems, networking, cryptography, database administrator, digital forensic, etc. For effective
monitoring, shifts work schedule shall be adopted.
j. The SOC team shall have adequate knowledge of the business environment and infrastructure in order
to prioritize the most appropriate response when cyber-incidents occur.
k. There shall be a capacity planning tool/process that communicates SOC infrastructure (SIEM) storage
to enable the SOC team balance task workload with available resources.
l. Risk and vulnerability assessment vulnerability assessment shall be conducted on the SOC
infrastructure. The SOC infrastructure and processes shall be continually audited.
m. It shall have a forensic laboratory equipped with specialized forensic tools to support incident response
investigation efforts.
n. The SOC shall have well documented processes to
 triage various types of cyber-incidents with appropriate response approved by the business
process owners for operational consistency
 identify, analyze and report emerging threats
 gather and preserve evidence for Forensic Investigation
5.17 Data Center Controls
IT Division shall maintain physical security of the DC, DR and Branch server room. Physical access control,
Environmental security and fire protection etc. are maintains in DC and DR.

5.17.1 Physical Security of Data Center and DR Site
a. Physical security must be applied to Trust Bank Data Center (DC) and Disaster Recovery Site (DR).
b. DC and DR must be a restricted area and unauthorized access must be prohibited.
c. Entrance into the DC and DR will be restricted by bio-matrix or retina based access controller.
d. Access authorization list will be maintained and reviewed periodically for the authorized person to
access the Data Center.
e. Access authorization procedures will exist and be applied to all persons (e.g. employees and vendors).
Unauthorized individuals and cleaning crews must be escorted during their stay in the Data Center.
f. Access log with date, time and purpose will be maintained for the vendors, service providers and visitors
entered into the Data Center.
g. Security guard will be available for 24 hours.
h. Emergency exit door will be available.
5.17.2 Environmental Security of Data Center and DR Site
a. Protection of Data Center from the risk of damage due to fire, flood, explosion and other forms of
disaster will be designed and applied.
b. Raised floor with removable blocks or channels alongside the wall will be prepared to protect data and
power cables from interception and any sort of damages.
c. Water detection devices will be placed below the raised floor.
d. Any accessories not associated to Data Center will not be allowed to store in the Data Center.
e. Closed Circuit Television (CCTV) camera will be installed for monitoring.
f. The sign of "No eating, drinking or smoking" will be in display.
g. Dedicated office vehicles for any of the emergencies will always be available on site. Availing of public
transport must be avoided while carrying critical equipment outside the bank’s premises to avoid the
risk of any causality.
h. Data Center will have dedicated full‐time supported telephone communication.
i. Address and telephone or mobile numbers of all contact persons (e.g. fire service, police station, service
providers, vendors and all ICT personnel) must be available to cope with any emergency situation.
j. Power supply system and other support units must be separated from production site and placed in
secure area to reduce the risks from environmental threats.
k. Power supply from source (Main Distribution Board or Generator) to Data Center must be dedicated.
l. There should be two (02) sets of generator sets with enough diesel supply.
m. The following environmental controls will be installed and shall be regularly tested and maintenance
service contract shall be for 24x7 basis:
i. Uninterrupted Power Supply (UPS) with backup units
ii. Backup Power Supply
iii. Temperature and humidity measuring devices
iv. Water leakage precautions and water drainage system from Air Conditioner
v. Precision cooling with backup units.
vi. Emergency power cutoff switches where applicable
vii. Dehumidifier for humidity control
5.17.3 Fire Prevention of Data Center and DR Site
a. It shall be ensured that wall, ceiling and door of Dc and DR will be fire resistant.
b. Fire suppression equipment will be installed and conduct a fire drill on an annual basis to test the
equipment.
c. Automatic fire alarming system will be installed and tested periodically.

d. There will be a fire detector in DC and DR.
e. Electric and data cables in the DC and DR must maintain a quality and be concealed.
f. Any flammable items must not be kept in the DC and DR.
5.17.4 Equipment Security of DC & DR
a. Physical layout of Data Center including power supply and network connectivity will be documented.
b. Equipment shall be sited and protected to reduce the risks from environmental threats and hazards,
and opportunities for unauthorized access.
c. All IT equipment in DC & DR shall be protected from power failures and other disruptions caused by
failures in supporting utilities.
d. Power and telecommunications cabling shall be protected from interception or damage and should be
concealed. Both cables should be laid separately to reduce interference and be concealed.
e. Equipment shall be maintained to ensure its continued availability and integrity.
f. Equipment (i.e. Laptop, Tablet, and Router etc.), information or software shall not be taken offsite
without prior authorization. Security guard must seek Gate Pass before the equipment is taken offsite.
g. Tracking information shall be recorded for all physical media that is taken off site describing where/how
this is to be used and when it will be returned.
h. Security shall be applied to off-site equipment, taking into account the risks of working outside the
Bank’s premises.
i. All media shall be secured against loss or copying; this includes controls for physically securing all media
(including but not limited to computers, removable electronic media, paper receipts, paper reports).
5.17.5 Working outside Designated Office Hours
a. Access to the DC & DR premises is expressly restricted on non-working days (weekends and public
holidays).
b. However, there may be cases where officials require access to the premises. In such cases, approval
must be sought through Head of IT and other concern division for the final approval. The approval must
be granted on/before the close of business of the prior day. Emergency approvals can be sought via
email/SMS.
c. Security guard shall deny access to the DC & DR for any employee without authorization.
d. All employees must vacate the DC & DR after permitted time period. It is the responsibility of DC
Manager to remove such personnel from the premises except through authorization of the Head of IT.
5.17.6 Cable Management
a. TBL shall have a proper cabling management plan to determine the entry path of the cables into the IT
rack i.e., whether the cables will enter the IT rack through the roof or the floor. If entering from the top,
the location of IT rack roof cutouts and their proximity to the vertical cable channels need to be
considered. If entering bottom (the cables will most likely run under a raised floor), eliminate any
obstructions in the base that can interfere with the cable entry path.
b. TBL shall separate power and data cables to prevent EMI (erratic or error-prone data transfers).
c. TBL shall ensure that copper data cables and fiber optic cable runs are separated, because the weight
of copper cables can damage the fiber.
d. TBL shall maintain a consistent cable jacket color coding standard for each type of cable in the tray,
copper, fiber, telecommunication, Power over Ethernet (PoE), and high voltage power lines for easy
identification, expansion, and repairs.
e. TBL shall label cables securely on each end.
f. TBL shall secure cables and connectors to prevent excessive movement and to provide strain relief of
critical points.
g. After cables are installed and labeled, TBL shall ensure that the airflow path is clear of obstructions.
h. After installing the cable, TBL shall document the complete infrastructure including diagrams, cable
types, patching information, and cable counts and keep this information easily accessible to data center
personnel and assign updates to one or more staff members and maintain organization.
5.18 Branch Server Room Controls
Branch having servers at their premise must have following physical, environmental and Fire protection facilities
to be installed.
5.18.1 Physical Security Branch Server Room
i. Server/network room/rack must have a glass enclosure with lock and key under a responsible person.
j. Physical access shall be restricted, visitors log must exist and to be maintained for the server room.
k. Access authorization list must be maintained and reviewed on regular basis.
l. Server/network room/rack shall be air-conditioned. Water leakage precautions and water drainage
system from Air Conditioner shall be installed.
m. UPS shall be in place to provide uninterrupted power supply to the server and required devices.
n. Power supply shall be switched off before leaving the server room if otherwise not required.
o. The sign of "No eating, drinking or smoking" shall be in display.
p. Access authorization procedures shall be strictly applied to vendors, service providers, support
employee and cleaning crews.
q. Access authorization list shall be maintained and reviewed periodically for the authorized person to
access the Server Room.
5.18.2 Branch Server Room Environmental Security
a. There will be a provision to replace the server within shortest possible time in case of any disaster.
b. Water leakage precautions and water drainage system from Air Conditioner will be installed in all TBL
Branches.
c. Power generator will be in place to continue operations in case of power failure.
d. UPS (Online) will be in place to provide uninterrupted power supply to the server.
e. Proper attention must be given on overloading electrical outlets with too many devices.
f. Electricity earthling is located beside the generator room and used properly all over including the server
room.
5.18.3 Branch Server Room Fire Protection
Fire extinguisher must be placed outside of the server room. This must be maintained and checked on periodic
basis.
5.19 Mobile Device and Teleworking
This policy describes how the Bank allows usage of Mobile devices as part of normal business processes. The
Bank also ensures that due care is exercised over the mobile device usage and of the data they hold. Mobile
devices include but not limited to mobile phones, smart phones, tablet computers, memory sticks, external
storage devices, and all forms of portable multimedia devices.

Information processing equipment, internet, intranet and email access provided by the Bank is intended
primarily for the Bank’s business use.
The Bank shall ensure information security when using mobile devices to generate, process, transact or store
information resources that originate terminate or that are processed through the Bank’s information systems.
The protection required should be commensurate with the risks associated with compromise of confidentiality,
integrity, availability and authenticity of such information resource.
The Bank SHALL apply necessary technical Control mechanisms to ensure a safe environment and platform for
the use of such mobile device over its networks, systems and services including the data they contain.
a. All The Bank supplied mobile devices and their contents remain the property of The Bank and are
subject to regular audit and monitoring. These devices should only
b. Baseline security shall be enforced on all device.
c. Default setting and password must be changed.
d. All information classified as “confidential” must be encrypted if stored on a mobile device. Until
encryption policy is implemented enterprise-wide, confidential information must not be stored on
mobile devices
e. Portable devices should not be used to store sensitive/confidential information.
f. A lost or stolen device must be reported immediately to IT Division for remote wiping.
g. Devices must not be “jailbroken” or “rooted”* or have any software/firmware installed which is
designed to gain access to functionality not intended to be exposed to the user.
h. Users must not load pirated software or illegal content onto their devices. Only applications authorized
by the Bank can be run on mobile devices.
i. Devices must be kept up to date with manufacturer or network provided patches.
j. Embedded camera on handheld devices might be disabled in restricted environment.
k. Mobile Device settings (passwords etc.) must be consistent with the Bank’s Password policy
l. Disposal and decommissioning of mobile devices must conform to the Asset management and Change
Management Policy/Procedures.
All mobile devices generating, accessing, processing, transacting or storing The Bank information must comply
with the policy outlined above
5.20 Work from Home (WFH) Security
a. Open Wi-Fi should not be used to access corporate network.

b. Secure VPN and two factor authentication must be used to access corporate network from home or
during travel.
c. Default network name and password of home router should be changed.
d. Wi-Fi router should be configured to highest encryption.
e. Wi-Fi router SSID broadcast should be disabled.
f. Employees should only visit trusted sites using official laptop during WFH.
5.21 Remote Access (VPN)
a) Remote access shall only be allowed after through due diligence and Remote VPN Access Request Form
(Annexure - 5) needs to be filled.
b) Remote access for vendors shall only be activated on need to know basis and must be de-activated
immediately after use.
c) Remote access technologies must automatically disconnect VPN users after a specified period of
inactivity.
d) Remote access applicable to all TBL employees and contractors working for IT Division,
e) Only approved VPN client software may be used to establish VPN connections to TBL network.
f) Vendors with remote access must not use generic usernames/passwords nor may they use the same
credentials for multiple clients.
g) Authorized VPN users must prevent other unauthorized persons from getting their password or
physically accessing and using the computer while the VPN connection is active.
h) When accessing cardholder data via remote-access technologies, cardholder data shall not be copied,
moved, or stored onto local hard drives, removable computer media or external media.
i) Implement two-factor authentication for remote access to the network by employees, administrators,
and third parties.
j) VPN users are subject to restricted network resource access per their specified business requirements.
k) All Remote access session shall be audited and monitored for any unusual activity.
l) All computers connected to TBL corporate networks via VPN must use the most up-to-date anti-virus
software and up-to-date operating system security patches. A health check assessment of devices may
be performed before allowing for remote access.
Chapter 6
6.0 IT Operation Management
ICT Operation Management covers the dynamics of technology operation management including change
management, asset management, operating procedures and request management. The objective is to achieve
the highest levels of technology service quality by minimum operational risk.
6.1 Operation Security Policy
a. Operating procedures shall be documented, maintained and are made available to all Users who need
them.
b. Changes to information processing facilities and systems shall be controlled and documented.
c. Duties and areas of responsibility shall be segregated to reduce opportunities for unauthorized or
unintentional modification or misuse of organisational assets.
d. Development, test and operational facilities shall be separated to reduce the risks of unauthorised
access or changes to the operational system.
e. The Bank shall ensure that the security controls, service definitions and delivery levels included in the
third party service delivery agreement are implemented, operated and maintained by the third party.
The Bank shall ensure that the written agreement includes an acknowledgement that service providers
are responsible for securing cardholder data and other data or information of the Bank in their
possession.
f. The Bank shall regularly monitor and review the services, reports, records and PCI DSS compliance
status provided by third parties and shall carry out regular audits.
g. The Bank manages changes to the provision of services, including maintaining and improving existing
information security policies, procedures and controls, taking account of the criticality of business
systems and processes involved and re-assessment of risks.
h. The Bank shall ensure that the use of resources is monitored, tuned, and projections made of future
capacity requirements to ensure adequate system performance.
i. Acceptance criteria for new information systems, upgrades and new versions shall be established and
suitable tests of the system(s) shall be carried out during development and prior to acceptance.
j. Back-up copies of information and software shall be taken and tested regularly in accordance with the
agreed back-up policy.
k. Networks shall be managed and controlled in order to be protected from threats, and to maintain
security for the systems and applications using the network, including information in transit.

l. Security features, service levels and management requirements of all network services shall be
identified and included in any/the network service level agreement, whether those services are
provided in-house or outsourced.
m. Controls for the management of removable media shall be established.
n. Media shall be disposed of securely and safely (i.e. completely destroyed) when no longer required.
o. Procedures for the handling and storage of information shall protect the information from
unauthorized disclosure or misuse.
1) Media backups shall be securely stored offsite. The storage location shall be reviewed at least
annually to determine its suitability.
2) All paper and electronic media that contain cardholder data shall be physically secured.
Storage containers used for information to be destroyed shall be secured/locked.
3) All media shall be classified in line with the Bank’s classification policy to reflect the sensitivity
of the data stored on the media.
4) Media sent outside the Bank is logged, authorized by management and sent via secure courier
or method that can be tracked.
5) Periodic media inventories (minimum annually) shall be undertaken to ensure secure storage
and maintenance of hardcopy and electronic media.
p. System documentation shall be protected against unauthorized access.
q. Formal exchange policies, procedures and controls shall be in place to protect the exchange of
information through the use of all types of communication facilities.
r. Agreements shall be established for the exchange of information and software between the Bank and
external parties.
s. The Bank shall ensure that media are protected against unauthorized access, misuse or corruption
during transportation beyond the Bank’s physical boundaries.
t. Information involved in electronic messaging shall be appropriately protected.
u. Policy and procedures shall be developed and implemented to protect information associated with the
interconnection of business information systems.
6.1.1 Operating time schedule
a. Operation time-clock for users of any systems like applications, database and CBS etc. must be defined
as per management guidelines. It may be changed with the change of banking operation schedule
through notice/circular/guideline of the Management in line with Bangladesh Bank.
b. The time may be changed by the competent authority with proper written approval if necessary, in case
of any specific users.
c. Access to database, applications shall be restricted especially during weekends/holidays except for
special events like month end, half yearly end and year end purpose.
d. Audit trail must be available to review the user profile in the application.
6.1.2 IT Division responsibilities
a. IT Division shall be responsible for the administration of access controls to all computer systems of TBL.
b. IT Division may process addition, deletions, and changes of user related information upon receipt of a
written request from the end user’s supervisor/branch incumbent.
c. IT Division shall maintain a list of administrative access codes and passwords and keep this list in a
locked place.
d. IT Division will be responsible for allowing access to any PC, Laptop, printer, modem etc. of TBL into the
system based on the necessity.

6.1.3 Employee’s responsibilities
v. Will be responsible for all computer transactions that are made with his / her User ID and password.
w. Must not disclose passwords (CBS, intra apps, email etc.) to others.
x. Passwords must be changed immediately if it is suspected that they may have become known to others.
Passwords should not be recorded from where these may be easily obtained.
y. Should maintain the confidentiality of their own password and under no circumstance it should be
disclosed to someone else.
z. Should change password from time to time and be maintained confidentially.
aa. Should use passwords that will not be easily guessed by others and password complexity is to be
ensured.
bb. Should log out from systems and lock computer while leaving the workstation/computer even for a
short period of time.
cc. Should not attempt to access by using the accounts of other users.
dd. Login password of the user must be changed after first login.
6.2 Third Party Management

6.2.1 Third Party Software
a. All third-party software developed under contract or funded by the Bank must be considered the
property of the Bank unless otherwise stated in the contract.
b. Third-party software procured by the Bank but considered a required component of an information
resource used in an essential business activity must be licensed to the Bank.
c. It is the goal of IT Division to keep licensing accurate and up to date. The Bank shall sign escrow
agreement for licensed software to protect source code.
d. A written integrity statement must be provided with significant third-party software that provides
assurances that the software does not contain undocumented features or hidden mechanisms that
could be used to compromise the software or operating system security.
6.2.2 Third Party Service Delivery
a. The Bank shall ensure that the security controls, service definitions and delivery levels included in the
third party service delivery agreement (SLA) are implemented, operated and maintained by the third
party.
b. SLA shall be reviewed yearly/periodically and approved by appropriate authority
(Management/EC/BoD).
c. IS Audit team shall regularly monitor and review the services, reports, records and compliance status
provided by third parties and shall carry out regular audits.
6.3 Asset Management
a. Prior to procuring any new ICT assets, compatibility assessment (with existing system) shall be
performed.
b. AII ICT asset procurement shall be complied with the procurement policy of Bank.
c. Each ICT asset shall be assigned to a custodian (an individual or entity) who will be responsible for the
development, maintenance, usage, security and integrity of the asset.
d. All ICT assets shall be clearly identified and labeled. Labeling shall reflect the established classification
of assets.

e. Inventory is kept with all significant details (e.g. owner, custodian, purchase date, location, license
number, configuration, etc.) for Computer equipment should be maintained by bank’s Support and
Delivery Department through Inventory Management application
f. TBL shall review and update the ICT asset inventory once in a year by S&D.
g. Information system assets shall be adequately protected from unauthorized access, misuse or
fraudulent modification, insertion, deletion, substitution, suppression or disclosure.
h. The inventory system shall have monitoring process to view return back organizational assets from
employees/external parties upon termination of their employment, contract or agreement.
i. If any IT asset i.e. Desktop/Laptop, HDD, RSA Token, Pen drive etc. is lost or damaged by the employee
due to negligence, an amount equal to its depreciated value will be deducted from his salary and a new
one will be given to him as per procedure.
6.4 Disposal Policy
Technology equipment often contains parts which cannot simply be thrown away. Proper disposal of equipment
is both environmentally responsible and often required by law. In addition, computer accessories like hard
drives, USB drives, CD-ROMs and other storage media contain various kinds of information, some of which is
considered sensitive. In order to protect organizations data, all storage media must be sanitized appropriately
by overwriting or degaussing prior to disposal.
6.4.1 Disposal Policy of IT Equipment

Any equipment no longer in use needs to be securely decommissioned either by overwriting, degaussing,
encryption, or physical destruction of the storage medium. Whether a business is donating a system to a charity,
selling it by open tender simply disposing of it, the secure destroying steps needs to be performed.
a. Since a common area for data breaches is on archived media or computers that are no longer in use,
many new privacy laws require businesses to securely destroy data when it reaches end of life.
Formatting a hard drive or deleting files using built-in operating system features leaves the files open
to being recovered by a third-party with simple tools.
b. Any sensitive data no longer in use needs to be securely decommissioned either by overwriting,
degaussing, encryption, or physical destruction of the storage medium. Whether a business is donating
a system to a charity, selling it by open tender simply disposing of it, the secure destroying steps needs
to be performed.
c. All data on equipment’s and associated storage media’s must be destroyed or overwritten before sale,
donate or disposal:
i. A committee/team lead by Support & Service Department to be formed for this purpose with
one official from IT Division, one from Administrative Division, one from IC&C and one official
from Legal Affairs Division.
ii. The committee will sit at least once in a year and as and when required.
iii. The obsolete, disposal and re-use procedure to be recorded in a register.
6.4.2 Disposal Policy for Data/Documents/Payment Cards (Debit/Credit/Prepaid)

The Bank policy for disposal of Data /Document stored in the IT Division Data Centre that is of no use as to the
requirements of the Department is as follows;
a. The approximate time range should to be determined for any Data /Document to be useful to the Bank.
b. The files are to be categorized in accordance with the level of importance of a particular Data
/document.

c. All the Data /Document (Soft Copies) of the Division should to be stored and preserved in various
storage medium for up to 10 (Ten) years, considering all the Documents generated in the Division are
of importance to some extent.
d. Preserved Data /Documents (Soft Copies) of the Division of more than 10 (Ten) years is a subject to be
disposed.
e. At the end of the Preservation Period of any Data /Document, that may be erased from the system
subject to storage capacity and data sensitivity.
f. After the removal of Data /Document, Each system will be cleaned and evaluated for method of
disposal and hard disks will be repartitioned and reformatted.
g. The disposal of the Data /Document must be recorded in the proper asset register.
h. Unused/Undelivered cards and PIN mailer must be physically destroyed and be updated in the register.
i. SMS will be sent to customers about uncollected cards, where cards remaining uncollected for more
than 2 weeks,
j. If cards remain uncollected for over 60 days, Designated Person will send letter to the customers
requesting immediate collection and informing destruction fee realization, if not collected within time.
Usual Debit Card annual Fee will be deducted as destruction fee for Debit Cards and PIN
k. For cards remaining un-collected for 90 days, Designated Person will contact once again by phone.
l. Cards and PIN uncollected for 180 days from the date of issue will be destroyed by the Designated
Person under dual control with Manager Operation. Date of destruction is noted on both the “Card
Delivery Report/Register” available with Designated Person and on the “PIN Delivery Report/Register”
available with Designated Person. The Designated person and Manager Operation will make a note
“DESTRYOED” against each Card/PIN on the Card/PIN delivery Report/Register and both of them must
sign in evidence of destruction.
m. Designated person and Manager Operation will prepare a list and send of all cards/PIN mailers
destroyed to Card Division for updating the system and to Banking Operation Department (BOD) for
record.
n. Care should be taken that both cards and pin destruction is conducted in presence of all concerned
simultaneously.
o. Debit Card and PIN Mailers must have separate custodian.
6.4.3 Considering factors for Data and Software removal

There are a number of considerations to be made when moving or disposing of computer hardware. PCs may
have sensitive data on the hard disk, this must be removed and where appropriate backed up and / or
transferred to another PC. This is to satisfy the requirements of the Data Protection Act and to protect the Bank
from the results of leakage of sensitive information.
All the Software are purchased and licensed for use within the Bank and is therefore not transferable with a PC.
All software must be removed from hardware that is being disposed of. To ensure that these considerations are
taken into account all PCs must be disposed of under the supervision of proper authority.
6.4.4 Factors regarding Deleting Data- technical aspects

Before disposing of any computer system, it is vital to remove all traces of data files, Bank licensed software and
operating systems.
Merely deleting the visible files is not sufficient to achieve this, since data recovery software could be used by a
new owner to “undelete” such files. The disk-space previously used by deleted files needs to be overwritten with
new, meaningless data - either some fixed pattern (e.g. binary zeroes) or random data. Similarly, reformatting
the whole hard disk may not in itself prevent the recovery of old data as it is possible for disks to be
“unformatted”.

There are a number of tools available for fully wiping hard disks that will completely wipe the contents of any
specified files, or the whole of the free space on the disk. However, this approach still assumes that it has located
every file that needs to be taken care of, which may not always be easy.
A better approach is to reformat the hard disk, installing a clean copy of the original operating system, and then
run a suitable application on the free space. This should leave a machine in a suitable state for disposal.
6.4.5 Re-use of items from obsolete equipment

a. The reusable items are to be picked up from the obsolete Items with proper tagging & recording such
as the Hostname, Brand, model, Sl. No, collection date, Job performer name etc.
b. The reusable items are to be preserved at safe custodies of S&D department.
c. Reusable items will be used at the required host/equipment by recording in the obsolete register.
d. After proper data destruction Data owner items are to be prepared for re-use.
6.5 Insurance Fund & Depreciation
a. Adequate insurance coverage or risk coverage fund shall be maintained for critical IT infrastructure (DC,
DRS etc.) to mitigate the IT risks may occur.
b. IT Division shall coordinate with S&D Department for insurance coverage for computer equipment. All
insurance matters for computer hardware shall be conducted by S&DD of the Bank as per the policy.
c. General insurance needs to cover Fire damage, Water damage from a flood, complete loss through
theft, Damage resulting from vandalism.
d. Depreciation shall be charged on computer hardware as per bank’s policy.
e. Necessary risk coverage fund shall be maintained.
6.6 Data Leak Protection (DLP) Policy

IT related data will be classified in three categories (Confidential, Internal & Public use).
6.6.1 Data in Motion

a. DLP solution shall be configured at the endpoints to identify data in motion to Browsers, E-mail clients,
Mass storage devices and writable CD media etc.
b. DLP will scan for data in motion based on data classification. DLP will identify specific content, i.e.: a. E-
mail addresses, names, NID/PAN/AC no and other combinations of personally identifiable information.
c. DLP will be configured to alert the user in the event of a suspected transmission of confidential data,
and the user will be presented with a choice to authorize or reject the transfer.
d. DLP will log incidents centrally for review. The IT team will conduct first level triage on events,
identifying data that may be sensitive and situations where its transfer was authorized and there is a
concern of inappropriate use.
e. Access to DLP events will be restricted to a named group of individuals to protect the privacy of
employees.
6.6.2 Data at Rest

a. All devices in scope will have full disk encryption enabled.
b. Encryption policy must be managed and compliance validated by the proper authority.
c. Machines need to report to the central management infrastructure to enable audit records to
demonstrate compliance as required.
d. Where management is not possible and a standalone encryption is configured (only once approved by
a risk assessment), the device user must provide a copy of the active encryption key to IT.
e. TBL Management has the right to access any encrypted device for the purposes of investigation,
maintenance or the absence of an employee with primary file system access.
f. The encryption technology must be configured in accordance with industry best practice.
6.6.3 Data in Use

a. Sensitive/Confidential data residing in primary memory must use of enclave protection.
b. Sensitive/Confidential (PAN) data must be masked
c. Computer screens must be angled away from the view of unauthorized persons to ensure clear screen
and shoulder surfing.
6.7 Clear Desk and Clear Screen Management

a) Where practically possible, paper and computer media should be stored in suitable locked safes,
cabinets or other forms of security furniture when not in use, especially outside working hours.
b) Where lockable safes, filing cabinets, drawers, cupboards etc. are not available, office/room doors must
be locked if vacant. At the end of each session all sensitive information must be removed from the work
place and stored in a locked area.
c) Confidential information, when printed, must be cleared from printers immediately.
d) All disposable paper documents must be shredded before disposal so that it can’t be reproduced.
a) Any visit, appointment or message books must be stored in a locked area when not in use.
b) The Bank’s computer terminals must be locked when unattended.
c) Computer screens must be angled away from the view of unauthorized persons.
6.8 Information Handling

Procedures for the handling and storage of information shall protect this information from unauthorized
disclosure or misuse.
a) Media backups shall be securely stored offsite. The storage location is reviewed at least
annually to determine it is a secure environment.
b) All paper and electronic media that contain cardholder data shall be physically secured.
Storage containers used for information to be destroyed shall be secured / locked.
c) All media are classified in line with the Bank’s classification policy and so as to reflect the
sensitivity of the data stored on the media.
d) Media sent outside the facility is logged, authorized by management and sent via secure
courier or method that can be tracked.
e) Periodic media inventories (minimum annually) are undertaken to ensure secure storage and
maintenance of hardcopy and electronic media.
f) No users shall be allowed to store official data in cloud storage.
6.9 Information Classification

IT Divisions information assets may be classified into three types: PUBLIC, INTERNAL and CONFIDENTIAL. Each
attracts a baseline set of security controls providing appropriate protection against typical threats. Every
employee has a duty to respect the confidentiality and integrity of any of the Bank information and data that
they access, and is personally accountable for safeguarding assets in line with this policy. All the Bank’s
information assets and services are classified taking to account their legality, value, sensitivity and criticality to
the organization.
6.9.1 Responsibility
a) The owner of each asset shall be responsible for its classification, for ensuring it is correctly labeled
and for its correct handling in line with its classification.
b) The intended recipient of any information assets sent from outside the Bank becomes the owner
of that asset.
c) The IT System Unit in conjunction with GSSD shall be responsible for maintaining the inventory of
assets and services together with their classification levels.
d) The IT System Unit shall be responsible for the creation, maintenance and review of electronic
distribution lists and for ensuring that they conform to this security classification system
6.9.2 Classification
1. IT Division shall classify information into three levels of classification (Public, Internal Use Only, and
Confidential).
2. The classification level of all assets is identified, both on the asset and in the asset inventory.
3. The classification information must be included in the document footer, which must be manually
set to appear on all pages of the document or on the media on which it is recorded.
4. Information received from outside the Bank shall be re-classified by its recipient (who becomes its
owner) so that, within the Bank, it complies with this procedure.
5. Information that is not marked with a classification level shall be turned to its sender for
classification; if it cannot be returned, it is destroyed.
6. The classifications of information assets are reviewed annually by their owners and if the
classification level can be reduced, it will be. The asset owner is responsible for declassifying
information.
7. Confidential information is specifically restricted to the Board of Directors, Executive Management
and specific professional advisers. Information that falls into this category must be marked
‘Confidential’, and its circulation is kept to a minimum with the names of the people to whom it is
limited identified on the document. Each copy of a document that has this level of classification is
numbered and a register is retained identifying the recipient of each numbered copy. Confidential
information sent by e-mail must be encrypted and digitally signed, appropriately, and sent only to
the e-mail box of the identified recipient. Confidential information can only be processed or stored
on facilities which have been assessed in line with Risk Management Procedure as providing
adequate security for such information.
6.9.3 Labelling
1. Documents are labeled as set out above, in the document footer. Documents that do not have
footers are marked by addition of a physical, stick-on label.
2. Removable and storage media (CD-ROMs, USB sticks, tapes, etc.) are labeled:
a. Red: Confidential
b. Yellow: Internal Use Only
c. Green: Public
3. Electronic documents and information assets are labeled by marking them with their Classification
level at either the header or footer.
4. Information processing facilities should not be conspicuously labeled to reveal or suggest their
identity.
6.9.4 Handling
1. Information assets shall be handled by individuals that have appropriate authorizations or on facilities
that meet what the Bank’s specified requirements.
2. The requirements for transmission, receipt, storage and declassification of classified and restricted
information are described above. Destruction of information media shall be carried out by someone
who has an appropriate level of authorization and in line with the requirements of Media and
Information Handling Procedure
3. Confidential documents shall be circulated in secure pdf format / as read-only documents.

4. Portable and storage media (including spooled media) must be moved, received and stored on the basis
of the highest classification item recorded on them, are subject to the physical security controls and
are protected appropriately while being recorded.
6.10 SECURITY CLASSIFICATION DEFINITIONS

Three security classifications (Public, Internal Use Only, and Confidential) indicate the increasing sensitivity of
information and the baseline personnel, physical and information security controls necessary to defend against
a broad profile of applicable threats:
6.10.1 PUBLIC
Public data is information that may or must be open to the general public. It is defined as information with no
existing local, national or international legal restrictions on access or usage. Public data, while subject to the
Bank disclosure rules, is available to all members of the organization’s community and constituency and to all
individuals and entities external to the organization community and constituency. By way of illustration only,
some examples of Public Data include:
a) Public posted press releases

b) Publicly posted schedules of classes
c) Publicly posted organization maps, newsletters, newspapers, and magazines.
6.10.2 INTERNAL USE ONLY

Internal Use Only data is information that must be guarded due to proprietary, ethical, or privacy considerations,
and must be protected from unauthorized access, modification, transmission, storage or other use. This
classification applies even though there may not be a civil statute requiring this protection. Internal Use Only
Data is information that is restricted to members of the organization community who have a legitimate purpose
for accessing such data. By way of illustration only, some examples of Internal Use Data include:
1. Employment data
2. The organization partner or sponsor information where no more restrictive confidentiality
agreement exists
3. Internal telephone books and directories
4. All the organization constituency members’ data
6.10.3 PROTECTION
Internal Use Only data
1. Must be protected to prevent loss, theft, unauthorized access and/or unauthorized disclosure
2. Must be stored in a closed container (i.e. file cabinet, closed office, or department where physical
controls are in place to prevent disclosure when not in use.
3. Must not be posted on any public website
4. Must be destroyed when no longer needed subject to the organization records management policy.
Destruction may be accomplished by:
a) “Hard Copy” materials must be destroyed by shredding or another process that destroys the
data beyond either recognition or reconstruction. After destruction, materials may be
disposed of with normal waste.
b) Electronic storage media shall be sanitized appropriately by overwriting at sector level or
degaussing prior to disposal. Disposal of electronic equipment must be performed in
accordance with the organization’s electronic equipment disposal policy.

6.10.4 CONFIDENTIAL
Confidential data is information protected by statutes, regulations, the organization policies or contractual
language. Disclosure to parties outside the organization should be authorized by the Bank’s MD/CEO or
appropriate designated parties. By way of illustration only, some examples of Confidential Data include:
1. Members and non-public member data

2. Personnel and/or payroll or records
3. The organization’s constituency members’ data
4. Bank account numbers and other personal financial information (PAN)
5. Any data identified by government regulation to be treated as Confidential, or sealed by order
of a court of competent jurisdiction.
6. Network information of the organization’s constituency members.
6.10.5 PROTECTION
Confidential data
1. When stored in electronic format, must be protected with strong passwords and stored on servers that
have protection and encryption measures provided by third party provider in order to protect against
loss, theft, unauthorized access and unauthorized disclosure.
2. Must not be disclosed to parties without explicit management authorization
3. Must be stored only in a locked drawer or room or an area where access is controlled by a guard, cipher
lock, and/or card reader, or that otherwise has sufficient physical access control measures to afford
adequate protection and prevent unauthorized access by members of the public, visitors, or other
persons without a need-to-know
4. When sent via fax must be sent only to a previously established and used address or one that has been
verified as using a secured location.
5. Must not be posted on any public website.
6. Must be destroyed when no longer needed subject to the organization’s Records Management Policy.
Destruction may be accompanied by the following:
a) “Hard Copy” materials must be destroyed by shredding or another process that destroys the
data beyond either recognition or reconstruction. After destruction, materials may be
disposed of with normal waste.
b) Electronic storage media shall be sanitized appropriately by degaussing prior to disposal.
Disposal of electronic equipment must be performed in accordance with the Bank’s Disposal
Policy.
The MD/CEO, CISO must be notified in a timely manner if data classified as Confidential is lost, disclosed to
unauthorized parties or suspected of being lost or disclosed to unauthorized parties, or if any unauthorized use
of the bank’s information systems has taken place or is suspected of taking place.

Chapter 7
7.0 Access Control Policy (Ref: Controls A.5.1.1)
The objective of this chapter is to specify Information Security Policies and Standards to be adopted by the bank.
This chapter covers the basic and general information security controls applicable to all functional groups to
ensure that information assets are protected against risk.
This chapter describes how the Bank secures access to its information assets to ensure that confidentiality,
integrity and availability are maintained. It applies to all information that the Bank collects, stores, processes,
generates or shares to deliver services and conduct business, including information received from or exchanged
with external partners and clients and also to information systems.
a. The Bank shall control access to information on the basis of business and security requirements.
b. Access control rules and rights to applications, expressed in standard user profiles, for each user or
group of users are clearly stated, together with the business requirements met by the controls.
c. The security requirements of each business application are determined by a risk assessment that
identifies all information related to the application and the risks to that information.
d. The access rights to each application take into account:
1) The classification levels of information processed within that application and ensure that there is
consistency between the classification levels and access control requirements across the systems
and networks.
2) Data protection and privacy legislation (if existent) and contractual commitments regarding access
to data or services.
3) The “need to know” principle (i.e. access is granted at the minimum level necessary for the role).
4) Everything is generally forbidden unless expressly permitted.
5) Rules must always be enforced and guidelines for enforcement shall be provided.
6) User initiated changes to information classification labels shall be prohibited.
7) User initiated changes to user permissions shall be prohibited.
8) Rules that require specific permission before enactment SHALL be enforced.
9) Any privilege that users require to perform their roles, subject to need-to-use basis and event-by-
event basis SHALL be enforced.
e. The Bank shall provide standard user access profiles for common roles in the Bank.
f. Management of access rights across the network shall be applied and monitored and in line with
Controls A.9.2 of Annex A Controls
g. User access requests, authorization and administration are segregated as described in ISO 27001
Controls A.9.3
h. USER access requests are subject to formal authorization, periodic review and removal in line with
documented procedures.
i. Management of access to network and network services shall be applied and monitored and in line
with Controls A.9.1.2 of Annex A Controls
j. Management shall develop processes and controls to restrict installation of software on both
production and client official systems
7.1 User ID Management:

a. CBS and MB user creation, limit enhancement or modification, privilege allocation, revocation and
status changing of user shall be performed by IT Support team or nominated IT personnel upon prior
approval from Operations Division. Such activities should have 4- eye principle (checker and maker) in
the system.
b. IT Division should control USER ID creation upon approval from the Operations Division. IT Division is
responsible to ensure that each user must have a unique User ID and a valid password. Access to IT
systems and networks shall be granted on a need-to-use basis and within the period when the access
is required.
c. IT Security Unit will monitor and review such activity including non-employees (contractual,
outsourced, or vendor employee) for access restrictions.
d. User ID Maintenance form with access privileges will be duly initiated by the head of concern
division/department and approved by Operation Division.
e. User ID needs to be locked up after three (03) unsuccessful login attempts. IT Division should ensure
user ID and password will not be same. Operations Division should ensure every user should login with
their own user ID. IT Division should ensure user password expire after ninety (90) days. IT Division
should ensure user cannot give same password consecutive two (02) times.
f. IT Division shall ensure that record of user access uniquely identified and logged for audit and review
purposes.
g. Operations Division shall maintain a list of authorized users’ administrator changes in access rights and
remove users. The request of any new user for CBS, MB and other user accounts and alternation of user
limits shall come through an automated system which will be duly approved by
branch/divisional/department head and finally approved from Operations Division.
h. Terminated user account shall be immediately disabled from all platforms (OS, CBS) after HRD formal
request. User ID should not be deleted in any instance. Access privileges will be changed/ locked within
24 hours or as per TBL policy when users' status changed or user left the bank.
i. Access privileges shall be changed/locked immediately upon notification from HRD, when user’s status
changed (transfer/leave/suspension) or employee resigned from the bank.
j. Remote access accounts for vendors are enabled for the allowed period only (disabled otherwise), and
access is monitored during the enabled period.
k. Dynamic two factor authentication systems shall be implemented for all critical systems (iBanking,
Remote portal access etc.).
l. Default application IDs shall only be used by the applications, not by individual User or other processes.
m. All access to databases shall be authenticated. User access to the database is through programmatic
methods (stored procedures). Direct access/queries to the database are restricted to database
administrators.
n. All Administrative ID (OS/ IOS, Core Banking Solution, DBMS etc.) should be disabled and shall not be
used to administer any system components or for support purpose. There should be dedicated support
user ID with administrative privileges to carry out day to day support activities across the Bank.
o. IS Audit shall perform regular reviews of user access privileges verify that privileges are granted
appropriately.
p. The disciplinary action shall be invoked in cases of attempted unauthorized access.
q. User ID shall be created with least privileges and access right shall be reviewed by supervisor whenever
a user’s role or location changes.
7.2 Maintenance of System Users
a. The branch incumbent should select executives and Officers as ‘User’, who used to work in the CBS.
Everyone should have a user ID. Every individual should maintain a password to work into the system.
b. Operation Division shall permit every individual ‘User’ against their assigned official works/jobs and
responsibilities.
c. Individual ‘User’ should be liable for each transaction entered by them as marked in the application log
file and transaction file against their user ID.
d. Operations Division should maintain a ‘User’ list with given permissions to
the individuals with duly signed and date or generated from system.

7.3 Password Control
k. Administrative password of Operating System, Database and Banking Application will be kept in sealed
envelope under safe custody (centralized/decentralized) which is the responsibility of concern
divisions/branch heads.
l. Passwords shall be between 8-12 characters in length; containing a combination of upper, lower case
alphabets, numerals and special characters e.g (~!@#$%^&*+) for all IT platform’s except for SWIFT.
m. User ID needs to be locked up after three (03) unsuccessful login attempts. IT Division should ensure
user ID and password will not be same.
n. IT Division will ensure password history maintenance will be enabled in the system to allow same
passwords to be used again after at least three (03) times.
o. Password will be validated for a time interval after that user must have to change password. The
maximum validity period of password should not be beyond 30 to 90 days cycle.
p. To control the maximum number of invalid login attempts should be specified properly in the system.
(maximum 03 consecutive times).
q. Users should change their passwords when prompted by the system in the case of networked machines
or on a regular basis for standalone machines.
r. Bank’s employees are responsible for the security of their password which they should not divulge,
even to colleagues.
s. Passwords shall be stored on secure systems, separate from application system data and are protected
by encryption. The default passwords on all new equipment shall be changed to conform to the Bank’s
password requirements before the equipment is brought into service.
t. Passwords must be rendered unreadable during transmission and storage on all system components
using strong cryptography.
u. Password reset requests must be initiated through the Bank’s user access workflow (confirmation from
supervisor or written evidence) and cannot be initiated by telephone.
v. Bank’s IT Division will ensure audit trail must be available to review the user profile in the application.
7.4 Input Control
a. It must be ensured that, software will not allow the same user to be both maker and checker of the
same transaction. In this regard, the system should have such availability, otherwise the checking
should be done manually or any other approved way by the authority, but the maker and checker
should to be different.
b. Session time‐out period and Maximum idle time of a session/system/application for users should be
approval by IT Division (currently it is 03 min).
c. Audit trail must be clearly marked with User ID, date and time stamp.
d. All systems activities and inputs to applications are synced to central time server (NTP).
7.5 Privileged Access Management
a. Privileges shall be allocated on a need-to-use and event-by-event basis upon proper approval from
respective division/department/branch Head. Head of respective division/department/branch will
define the role of each admin for each system.
b. The roles of each privilege user/admin shall only grant access rights and system privileges based on
roles as defined.
c. The approved request for allocation of a privilege initiated by the user concerned shall be forwarded to
the System Administrator.
d. The System Administrator shall retain a log of all authorized privileges in the central log server.
e. The roles of the privilege users/admins will be documented and will be reviewed as and when required.

f. TBL shall adopt following controls and security practices for all privileged users of the bank including IT
employees performing critical operations:
i. Strong authentication mechanisms;
ii. Strong controls over remote access;
iii. Grant privileged access on a “need to have” basis;
iv. Review privileged users’ activities on a timely basis;
v. Prohibit sharing of privileged accounts;
vi. Disallow vendors from gaining privileged access to systems without close supervision and
monitoring.
g. The privilege ID will be disabled immediately after transfer and resign of the employee.
h. IT Security Unit shall regular monitor and check that no person by virtue of rank or position shall have
any intrinsic right to access confidential data, applications, system resources or facilities for legitimate
purposes.
i. IS Audit team shall ensure a regular review of existing privileges.
7.6 Data Confidentiality
a. Confidential data is information protected by statutes, regulations, the organization policies or

contractual language. Disclosure to parties outside the organization should be authorized by MD/CEO
or appropriate designated parties. By way of illustration only, some examples of Confidential Data may
include:
 Members and non-public member data
 Personnel and/or payroll or records
 The organization’s constituency members’ data
 Bank account numbers and other personal financial information (PAN)
 Any data identified by government regulation to be treated as Confidential, or sealed by order of
a court of competent jurisdiction.
 Network information of the organization’s constituency members.
b. Information of any customer is considered highly confidential and is unjustified/offence to disclose
directly in public without acknowledging the concerned stakeholders and authority. TBL is only liable
to Bangladesh Bank and other regularity authority to deliver any sort of customer information had
instructed by proper authority.
c. Personal data of the clients are not for sharing with external auditors unless instructed by the
competent authority/management.
d. Access to customer data by the users is so directed as designed by core banking software and
Employees are under user limit.
e. The employees of a branch may access to the clients of their branch as per their user limit and may
access to the preserved data by other branches as per client’s request.
f. MD/CEO shall allow the employees of IC&C to analyze any client data as and when required in
coordination with IT Security Unit for compliance.
g. Personal data shall only be disclosed to the data subject and other organizations and persons who are
authorized. There may be occasions where personal data is requested to be disclosed, there is a
requirement to keep an audit trail to provide accurate details of this disclosure.
h. The data may be transferred for the purpose of storage in logical format to the authentic sites as per
prior approval of the MD/EC/BoD.
i. Information stored in central database is highly confidential in raw form. This data must not be
delivered to any unauthorized users for improper use, personal use or any other use without proper
permission/instruction of the appropriate management.
j. Computer Systems shall be configured with appropriate security levels to preserve confidentiality.
Users will only have access to personal information that is necessary for the purposes of carrying out
their function.
7.7 Data Protection and Privacy
a. When stored in electronic format, must be protected with strong passwords and stored on servers that
have protection and encryption measures provided by third party provider in order to protect against
loss, theft, unauthorized access and unauthorized disclosure.
b. Must not be disclosed to parties without explicit management authorization
c. Agreements, SLA or some other means which is considered as confidential must be stored only in a
locked drawer or room or an area where access is controlled by a guard, cipher lock, and/or card reader,
or that otherwise has sufficient physical access control measures to afford adequate protection and
prevent unauthorized access by members of the public, visitors, or other persons without a need-to-
know.
d. Must not be posted on any public website and be destroyed when no longer needed. Destruction may
be accompanied by the following:
 “Hard Copy” materials must be destroyed by shredding or another process that destroys the data
beyond either recognition or reconstruction. After destruction, materials may be disposed of with
normal waste.
 Electronic storage media shall be sanitized appropriately by degaussing prior to disposal. Disposal
of electronic equipment must be performed in accordance with the Disposal Policy.
e. Operations Division and IT Security Unit must be notified in a timely manner if data classified as
Confidential is lost, disclosed to unauthorized parties or suspected of being lost or disclosed to
unauthorized parties, or if any unauthorized use of the information systems has taken place or is
suspected of taking place.
7.8 User Log Reports
a. Log Reports to be maintained for access into the system and uses of different
applications accordingly in detail.
b. The following functions must be recorded:
 Log-in attempts,
 Password changes
 File creations, changes and/or deletions
c. The audit trail event record should specify:
 Type of event
 When the event occurred
 User ID associated with the event
 Program or command used to initiate the event.
d. Audit trail and log Reports for all exceptions of the system should also be maintained
properly.

Chapter-8
8.0 Business Continuity & Disaster Recovery Management:
Effective business continuity measures are critical for any business entity. Trust Bank is committed to protecting
its employee and ensuring the continuity of critical businesses and functions in order to protect the Trust Bank
outlets, mitigate risk, safeguard revenues and sustain both stable financial market and customer confidence.
The development, implementation, testing and maintenance of an effective global Business Continuity and
Disaster Recovery Plan are required to sustain these objectives.
To further our commitment in the event of a significant business disruption, as well as meet all regulatory
requirements, Trust Bank’s infrastructure includes a Business Continuity Management (“BCM”) group that is an
integral part of Trust Bank's normal business operations. BCM plans, tests, and manages crises concerning
business lines and functions’ relocation and recovery. Business Continuity and Disaster Recovery Management
is required for planning of business resiliency for critical incidents, operational risks take into account for Data
Center disasters and the recovery plan.
8.1 Business Continuity Plan

8.1.1 Guideline of BCP
a. TBL should have a Business Continuity Plan (BCP) team under Operations Division addressing the
recovery of disaster to continue its operation. The bank shall establish a continuity planning framework,
which defines the roles, responsibilities and methodology to be adopted in case of a disaster. TBL should
ensure that a written Business Continuity Plan is developed containing the followings:
i. Guidelines on how to use the continuity plan.
ii. Emergency procedures to ensure the safety of all affected employee.
iii. Recovery procedures meant to bring the business back to the state it was before the incident or
disaster.
iv. Procedures to safeguard and reconstruct.
v. Co-ordination procedures with public authorities.
vi. Communication procedures with stakeholders, employees, key customers, critical suppliers,
stockholders and management.
vii. Contact information on continuity teams, affected employee, customers, suppliers, public
authorities and the media.
b. Primary objective of BCP should focus on the followings:
i) Survive in a disaster and re-establish normal business operations.
ii) The contingency plan shall cover the business resumption planning and disaster recovery
planning.
c. BCP should address the followings:
i) Critical application programs
ii) Responsible parties
iii) Third-party services
iv) Personnel and supplies
v) Emergency grab list such as backup tapes, laptops, flash drives, etc.
vi) Emergency contacts, addresses and phone numbers of employees, venders and agencies.
vii) Data files and time frames required for recovery after disaster occurs.
viii) Disaster recovery site map
ix) Action plan to restore business operations within the specified time frame for: i) office hour
disaster ii) outside office hour disaster.

8.1.2 Maintaining the BCP
a. The IT continuity plan shall be maintained (changed, updated and tested) whenever there is a major
change to the technological infrastructure of the Bank’s information system. Examples of situations that
might necessitate updating plans include the acquisition of new equipment, or upgrading of operational
systems and changes in:
i. Personnel
ii. Addresses or telephone numbers
iii. Business strategy
iv. Location, facilities and resources
v. Legislation
vi. Contractors, suppliers and key customers
vii. Processes, or new/withdrawn ones
viii. Risk (Technical, operational and financial).
b. BCP must be tested and reviewed regularly to ensure the effectiveness. Maintaining the IT continuity
plan shall be done annually or as need arises.
c. Documents related to BCP must be kept in a secured off‐site location. One copy shall be stored in the
office for ready reference.
d. The BCP shall be coordinated with and supported by the Business Impact Analysis (BIA) and the Disaster
Recovery Plan (DRP) considering system requirements, processes and interdependencies.
e. BCP shall be circulated to all relevant stakeholders. The recipients need to preserve a copy of amended
plan whenever any amendment or alteration takes place.
8.1.3 Testing Continuity Plan
a. To have an effective continuity plan, management must test the plan to ensure its adequacy, and to
ensure that management and employees understand the implementation.
b. Table-top testing of various scenarios (discussing the business recovery arrangements using example
interruptions)
c. Simulations (particularly for training people in their post-incident/crisis management roles)
d. Technical recovery testing (ensuring information systems can be restored effectively)
e. Testing recovery at an alternate site (running business processes in parallel with recovery operations
away from the main site)
f. Tests of supplier facilities and services (ensuring externally provided services and products will meet
the contracted commitment)
g. Complete rehearsals (Stress testing of personnel, equipment, facilities and processes).
h. There should be BCP team under Operations Division which will ensure that all concerned parties
receive regular training sessions regarding the procedures to be followed in case of an incident or
disaster and perform testing at least once in a year.
8.2 Disaster Recovery Management

a. Disaster recovery means recovery of total Computer System Setup along with data against any natural
or intruded disaster. DR site should be at a minimum of 10 kilometers (radius) of distance from DC as
guided by Bangladesh Bank ICT Security Policy. TBL may also establish near DC at same seismic zone of
DC if required.
b. DR test shall be carried out successfully at least once a year. DR test documentation shall include work
scope, plan and test result. Test report shall be communicated to management and other stakeholders
and preserved for future necessity.
c. Test and validate at least annually the effectiveness of recovery requirements and the ability of
employee to execute the necessary emergency and recovery procedures
d. TBL shall involve its business users in the design and execution of comprehensive test cases to verify that
recovered systems function properly.
e. DR plan shall exist for all the critical services where DR requirement is approved by the business. An up‐
to‐date and tested copy of the DR plan shall be securely held offsite. One copy shall be stored in the
office for ready reference.
8.2.1 Disaster Recovery Policy

a. Disaster Recovery Plan (DRP) needs to:
i. Defining system recovery and business resumption priorities
ii. Define specific recovery objectives including recovery time objective (RTO) and recovery point
objective (RPO) for ICT systems and applications.
iii. Define major system outages which may be caused by system faults, hardware malfunction,
operating errors or security incidents as well as a total incapacitation of the primary DC.
iv. Action plan for inter-dependencies between critical systems in drawing up its recovery plan and
conducting contingency tests.
v. Recovery strategies and technologies such as on‐ site redundancy and real-time data replication
to enhance recovery capability
8.2.2 DR Site Operation
a. DR site shall be equipped with compatible hardware and telecommunication equipment to support the
critical services of the business operation in the event of a disaster.
b. Physical and environmental security of the DR site or near DC shall be maintained.
c. Disaster Recovery center to be setup in a remote & secured area, which would be located in a separate
power phase and low risk Earth Quake area.
d. Parallel systems to be setup for each unit of Branch or Head office.
e. Backup Systems to be ready instantly / with a short notice for each unit of Branch or Head Office.
f. Redundancy is a must for All Servers, Applications, WAN connectivity, WAN equipment and LAN setup.
g. Information security shall be maintained properly throughout the recovery process.
h. Data mirroring (where possible RAID setup) to be implemented for all servers.
i. Recovery cell for computer systems to be ready for instant support.
8.3 Backup and Restore Policy
The section describes how the Bank manages backup of systems data and devices to ensure continuity in the
event of disaster. The Bank should apply all necessary technical and management control mechanisms to ensure
that backup of its information systems and networks are adequately performed and controlled.
This policy has been designed and implemented with disaster recovery/business continuity (i.e. the ability to
recover recent live data in the event of a partial or total loss of data) as key deliverable and is not therefore
designed as a method of archiving material for extended periods of time.
a. IT Division shall provide the appropriate central repository infrastructure for all employee to store critical
files/documents and all employee shall be individually responsible for data held locally on their desktop
or laptop computer.
b. IT Division and IT Security Unit along with the users shall ensure the safety and security of the backup
copies of information from not being damaged by natural calamities and theft (if possible to be sent at
off‐site location).
c. At least one copy of backup shall be kept on‐site for the time critical delivery. Backups shall only be
stored in secure offsite location. Only authorized personnel shall have access to the backup application
and media copies.
d. Backup media must be labeled (soft/hard format) properly indicating contents, backup cycle, backup
serial identifier, backup date and classification of the information content.
e. The data backup register shall be maintained, checked & signed by concern supervisor.
f. The backup log sheet shall be maintained, checked & signed by concern supervisor. The log needs to
include System starting and finishing time, System errors, corrective actions taken and confirmation of
the correct handling of data files and computer output.
g. Periodic testing should be carried out and validation of the recovery capability of backup media and
assess whether it is adequate and sufficiently effective to support recovery process.
h. All media contained backed-up information must be labeled with the information content, backup cycle,
backup serial identifier, backup date and classification of the information content.
i. The backup data shall be encrypted in tapes and secured inside a mobile handheld vault before
transported offsite for storage.
j. Monthly backups shall be retained for at least 10 year or as per Bangladesh Bank policy before being
overwritten.
k. Retrieval of backup media from offsite locations must be approved by Head of IT and Operations.
l. Datacenter Manager shall monitor backup operations regularly.
m. Backup media storage arrangements shall be reviewed annually to ensure adequacy.
n. IT division should develop and maintain backup & restore procedure which needs to focus the followings:
i. Frequency of backups which will be performed daily, weekly or monthly based on criticality of the
data.
ii. Define action plan and schedule of strategy of business application, involving the making of both
on- and off-line backups and the transfer of backups to secure off-site storage.
iii. Define schedule which needs to include the retention period for backed-up or archived
information. The retention period should be consistent with local legal and regulatory
requirements.
iv. Define frequency and schedule of backup for each business application.
v. Define type of back-up requirement (full, partial, incremental, differential, real-time monitoring)
at each point in the back-up schedule.
vi. Process of restoring information from both on- and off-site backup storage
vii. Backup systems shall be designed to ensure that routine backup operations require no manual
intervention.
viii. Backups shall be completed before at a stipulated time on working days. Any failed backups are
re‐run immediately with specified process.

Chapter 9
9.0 Acquisition and Development of Information Systems
For any new application or function for the bank requires analysis before acquisition or creation to ensure that
business requirements are met in an effective and efficient manner. This process covers the definition of needs,
consideration of alternative sources, review of technological and economic feasibility, execution of risk analysis
and cost‐benefit analysis and conclusion of a final decision to 'make' or 'buy'.
9.1 ICT Project Management
a. In drawing up a project management framework, it should be ensured that tasks and processes for
developing or acquiring new systems include project risk assessment and classification, critical success
factors for each project phase, definition of project milestones and deliverables. It should be clearly
defined in the project management framework, the roles and responsibilities of employee involved in
the project.
b. Project plan for all ICT projects shall be clearly documented and approved. In the project plans, the
deliverables should be set out clearly to be realized at each phase of the project as well as milestones
to be reached.
c. User functional requirements, business cases, cost-benefit analysis, systems design, technical
specifications, test plans and service performance expectations should be approved by the relevant
business units and ICT management.
d. IT Division in coordination with IT Security Unit shall establish management oversight of the project to
ensure that milestones are reached and deliverables are realized in a timely manner.
9.2 In-house Software

9.2.1 In-house Software Development
a. Detailed design and technical application requirements shall be prepared.

b. Criteria for acceptance of the requirement shall be defined and approved by the concerned business
unit.
c. Developed functionality in the application shall be managed in accordance with design specification
and documentation.
d. Source code must be available with software division and kept secured.
e. Source code shall contain title area, the author, date of creation, last date of modification and other
relevant information.
f. Detailed business requirements shall be documented and approved by the competent authority.
g. Detailed technical requirements and design shall be prepared.
h. Application security and availability requirements shall be addressed.
9.2.2 Software/Application Rollout
a. There should have a test environment to ensure the software functionalities before implementation.
b. User Acceptance Test should be carried out and signed‐off before going live.
c. Software Development Life Cycle (SDLC) with User Acceptance Test (UAT) shall be followed and
conducted in the development and implementation stage. User Verification Test (UVT) for post
deployment shall be carried out.
d. Support agreement must be maintained with the provider for the software used in production with the
confidentiality agreement.
e. System documentation and User Manual shall be prepared and handed over to the concerned
department or through blog. User Manual shall be published in intra Blog and particular blog URL shall
be linked in the respective application’s HELP menu.
9.3 Statutory Requirements
a. All the software procured and installed shall have legal licenses and record of the same shall be
maintained by the respective unit/department of Trust Bank.
b. There shall have a separate test environment/server to perform end-to-end testing of the software
functionalities before implementation.
c. User Acceptance Test (UAT) shall be carried out and signed by the relevant business units/departments
before rolling out in LIVE operation.
d. Necessary Regulatory Compliance requirements for banking procedures and practices and relevant
laws of Government of Bangladesh must be taken into account.
e. Any bugs and/or defects found due to design flaws must be escalated to higher levels in Software
Vendors' organization and Bank in time.
f. Support agreement must be maintained with the provider for the application software used in
production with the confidentiality agreement.
g. Escrow agreement shall be signed with renowned escrow provider to protect source code for
outsourced software.
9.4 In-house Application Security
a. Application security encompasses measures taken throughout the application's life-cycle to prevent
exceptions in the security policy of an application or the underlying system (vulnerabilities) through
flaws in the design, development, deployment, upgrade, or maintenance of the application.
Applications only control the use of resources granted to them, and not which resources are granted
to them. They, in turn, determine the use of these resources by users of the application through
application security.
b. Application security includes:
i. Knowing the threats.
ii. Securing the network, host and application.
iii. Incorporating security into software development process
iv. In-house software needs to be developed in such a way, so that it can prevent the threats
incurred in the following classes:
v. Input Validation
vi. Authentication
vii. Authorization
viii. Configuration Management
ix. Sensitive information
x. Session management
xi. Cryptography
xii. Parameter manipulation
xiii. Exception Management
xiv. Auditing
xv. Logging

9.5 Software Security Framework
Category Considerations
 Are credentials secured if they are passed over the network?
 Are strong account policies used?
Authentication  Are strong passwords enforced?
 Are you using certificates?
 Are password verifiers (using one-way hashes) used for user passwords?
 What gatekeepers are used at the entry points of the application?
 How is authorization enforced at the database?
Authorization  Is a defense in depth strategy used?
 Do you fail securely and only allow access upon successful confirmation of
credentials?
 How are session cookies generated?
 How are they secured to prevent session hijacking?
 How is persistent session state secured?
Session
 How is session state secured as it crosses the network?
management
 How does the application authenticate with the session store?
 Are credentials passed over the wire and are they maintained by the application?
If so, how are they secured?
 What algorithms and cryptographic techniques are used?
 How long are encryption keys and how are they secured?
Cryptography
 Does the application put its own encryption into action?
 How often are keys recycled?
 Does the application detect tampered parameters?
Parameter
 Does it validate all parameters in form fields, view state, cookie data, and HTTP
manipulation
headers?
Auditing and  Does your application audit activity across all tiers on all servers?
logging  How are log files secured?
9.6 Software Documentation

a. Business Requirement Document (BRD) duly prepared by Business team
b. Functionality and Specification Document (FSD)
i. Communications to management about the progress of the project, providing intermediate
product visibility
ii. Task-to-task communication
iii. Instruction and reference
iv. Quality assurance support
v. Historical reference
c. System Documentation
i. The functions of the system
ii. The Hardware / Software Functional Partitioning
iii. The Performance Specification
iv. The Hardware / Software Performance Partitioning
v. Safety Requirements
vi. The User Interface
vii. Provide Installation Drawings/Instructions.
d. Security features
i. State the consequences of the following breaches of security in the subject application:
 Loss or corruption of data
 Disclosure of secrets or sensitive information
 Disclosure of privileged/privacy information about individuals
 Corruption of software or introduction of malware, such as viruses
ii. State the type(s) of security required. Include the need for the following as appropriate:
 Physical security.
 Access by user role or types
 Procedure to access control requirements by data attribute
 Procedure to access requirements based on system function
 Sample of certification and accreditation of the security measures adopted for this
application
e. Interface requirements with other systems
Detail technical documentation of the technical aspects of interfacing with the other system.
f. Installation Manual
i. Installation media
ii. System Check
iii. License Agreement
iv. Installation options
v. Installation Location
vi. Installation Steps
g. User Manual
Documentation conveying to the end-user of a system instructions defining the User Interface, Login
procedure, System menu, Change password, Input Procedures and Expected Output etc. for using the
system to obtain desired result.
9.7 Outsourced Software Procurement Policy

a. Respective Division/Department should have BRD to be followed for the purchase of any software.
b. Security aspect will be preferred to select the components of software. Especially the Operating System
needs to be open platform based. Database to be secured & open standard and the front-end interface
may the any tools compatible with OS & Database.
c. Bank should always avoid using pirated software.
d. Base License of all application software need to be documented and preserved properly.
e. Service agreement against purchasing software where applicable to be arranged.
9.8 Software licensing

Most of the software existed are freeware / own developed. The License cost of software’s other than own
developed and free ware are under consideration for most titles and their deployment. It is the duty of IT Division
or concern division/department to keep licensing accurate and up to date. To address this, P&P Department
shall be responsible for purchasing software licenses for the following software categories:
a. Operating System Software
b. Productivity tools package
c. Accessories
d. Database
e. Domain Controlling System
f. Core Banking System
g. BACH system
h. Call Center Solution
i. Mobile Banking Platform
j. Secured Socket Layer (SSL) certificates for web portals
k. VA & PT Tools
l. Domain Hosting and Renewal issues
m. Any other software or system as required

9.9 Legal reference
TBL and its employees are legally bound to comply with the Copyright Act of the Government of Bangladesh and
all proprietary software license agreements. Noncompliance can expose TBL and the responsible employee(s)
to civil and / or criminal penalties.

Chapter 10
10.0 Service Provider Management

There is an increasing reliance on external service providers as partners in achieving the growth targets and as
effective cost alternatives. ICT outsourcing comes in many forms and permutations. Some of the most common
types of ICT outsourcing are in systems development and maintenance, support to DC operations, network
administration, disaster recovery services, application hosting and hardware maintenance.
10.1 Outsourcing
10.1.1 Outsourcing Governance
a. The Board of Directors and Senior Management should form a team or committee regarding risks
associated with ICT outsourcing. Before appointing a service provider, due diligence shall be carried
out to determine its viability, capability, reliability, track record and financial position. Accordingly, a
ICT Outsourcing Committee shall be formed. The responsibility of the committee or team will be as
follows:
i. Evaluate the risks of all existing and prospective outsourcing and the policies that apply to
such arrangements.
ii. Procedural activities for undertaking regular review of outsourcing strategies and
arrangements for their continued relevance.
b. Concern Division/Department and Legal Cell shall ensure that contractual terms and conditions
governing the roles, relationships, obligations and responsibilities of all contracting parties are set out
fully in written agreements. A formal contract between Bank and the outsourcer shall exist to protect
both parties.
c. IT Division, IT Security Unit and concern division/department should develop a contingency plan for
critical outsourced technology services to protect them from unavailability of services due to
unexpected problems of the technology service provider. This may include termination plan and
identification of additional or alternate technology service providers for such support and services.
d. Concern Division/department shall maintain a service catalogue or system generated Dashboard for
all third party services received preserving up-to-date information of each service rendered, service
provider name, service type, SLA expiry date, service receiving manager, service reporting, emergency
contact person at service provider, last SLA review date, etc.
e. ICT outsourcing shall not result in any weakening or degradation of the bank's internal controls. The
Bank shall require the service provider to employ a high standard of care and diligence in its security
policies, procedures and controls to protect the confidentiality and security of its sensitive or
confidential information, such as customer data, object programs and source codes.
f. IT Security Unit and “Review committee of ICT Security Policy” shall monitor and review the security
policies, procedures and controls of the service provider on a regular basis, including periodic
expert reports on security adequacy and compliance in respect of the operations and services
provided by the service provider.
g. Service providers’ needs to develop and establish a disaster recovery contingency framework which
defines its roles and responsibilities for documenting, maintaining and testing its contingency plans
and recovery procedures.
10.1.2 Practices of Outsourcing activities:
a. Objective behind Outsourcing

Controls to reduce the information security risks associated with outsourcing.

b. Scope
Outsourcing providers (also known as outsourcers) include:
i. Hardware and software support and maintenance employee
ii. External consultants and contractors
iii. IT or business process outsourcing firms
iv. Temporary/Contractual employee
c. Risks and security concerns
i. Identification of risks related to external parties
ii. Addressing security when dealing with customers
iii. Addressing security in third party agreements
d. Policy Axioms
i. The commercial benefits of outsourcing non-core business functions must be balanced against the
commercial and information security risks.
ii. The risks associated with outsourcing must be managed through the imposition of suitable
controls, comprising a combination of legal, physical, logical, procedural and managerial controls.
e. Choosing an Outsourcer
Criteria for selecting an outsourcer shall be defined and documented, taking into account the:
i. Company’s reputation and history;
ii. Quality of services provided to other customers;
iii. Number and competence of employee and managers;
iv. Financial stability of the company and commercial record;
v. Retention rates of the company’s employees;
vi. Quality assurance and security management standards currently followed by the company
(e.g. certified compliance with ISO 9000 and ISO/IEC 27001).
10.1.3 Considering factors for Outsourced System
a. Licensing arrangements, code ownership, engine and platform ownership and the protection of
intellectual property rights relating to the outsourced project.
b. Contractual requirements for secure design, coding and testing.
c. Providing the supplier with an approved threat model.
d. Acceptance testing of the deliverable.
e. Supplier provision of evidence that minimum security thresholds were used to establish acceptable
levels of information security.
f. Supplier provision of evidence that the deliverable has been adequately tested against all known
vulnerabilities.
g. Escrow arrangements.
h. The organization’s audit rights over development processes and controls.
i. Documentation of the build environment.
j. Division responsibility for compliance.
10.1.4 Vendor Selection
a. Administrative Division shall form a team comprising of personnel from Functional Departments and IT
Division for vendor selection. Vendor selection process must have conformity with the Procurement
Policy of TBL.
b. Based upon some criteria a weight age matrix will be done for software evaluation. Vendor selection
criteria for application must address the following:
i. Market presence:
The vendor needs to be registered, renowned, high profile market presence.
ii. Years in operation:
The total time length of operation of the vendor in the local or international market

iii. Technology alliances
The foreign vendor should have the technological alliances with local established and renowned
companies. The local partner strength will be derived by the total no. of employee engaged in the
software implementation team, their experience timeline, Company Profile etc.
iv. Extent of customization and work around solutions
The vendor should have the expertise to customize the software application as and when required
basis both by the bank urgent functional requirement or regulatory compliance.
v. Financial strength
The vendor should have adequate financial strength to project rollout
vi. Performance & Scalability
TBL Business team will define functional requirement by analyzing the business process of TBL
which will be supplied to the respective vendor after their live demonstration at TBL. The points
have been given on the basis of vendor response of TBL functionalities in line with their software.
The robustness of the software has been judged based on the i) n-tier architecture of the solution
ii) CMMi level, iii) ISO level etc.
vii. Number of installations
The vendor should have the expertise to successful implementation in local or international market
of the software.
viii. Existing customer reference
This criterion will be considered only by the deal cut of the software vendor with the local bank,
financial institute, other companies, considering the implementation status and the customer
feedback at the institution.
ix. Support arrangement
The points has been given after analyzing the customer feedback of local partner for their customer
support service, how prompt they provide the solution on different problems, up gradation,
modification, etc. of the software.
x. Local support arrangement for foreign vendors
In case CBS and other application vendors like Microsoft who are foreign based must have local
zonal office in Bangladesh for instant support and correspondence.
xi. Weight of financial and technical proposal
The vendor offers with adequate technical support strength needs to be considered in evaluation
of financial and technical proposals.
10.1.5 Vendor Management

a. The Vendor Management Process shall be followed by respective division/department as follows:
a. IT Division shall place requisition or requirement to P&P Department.
b. P&P Department shall process the same as per specification of IT Division and within the
guideline of procurement policy of the bank.
c. IT Security Unit shall monitor critical technology vendors that the bank may do business with.
b. There have to be an oversight program to monitor and assess the outsource service provider’s financial
condition and performance periodically. The conditions of service agreements should be enforced, and
reviewed periodically.
c. There shall be Service Level Agreement (SLA) or Annual Maintenance Contract (AMC) between the
vendor and Bank.
d. Risk assessment shall be conducted by ICT Risk Management Committee before engaging any vendor.
10.2 Service Level Agreement Policy
a. There shall have Service Level Agreements (SLA) with vendors. The Annual Maintenance Contract (AMC)
with the vendor shall be active and currently in-force.

b. Dashboard with significant details for SLAs and AMCs shall be prepared and kept updated.
c. Concern Division/department/branches will ensure that the equipment require servicing/maintenance
are free from sensitive live data. Support of IT Division must be taken in this regard.
d. The requirements and conditions covered in the agreements would usually include performance
targets, service levels, availability, reliability, scalability, compliance, audit, security, contingency
planning, disaster recovery capability and backup processing facility.
e. Service contracts with all service providers including third‐party vendors shall include:
i. Pricing
ii. Measurable service/deliverables
iii. Timing/schedules
iv. Confidentiality clause
v. Contact person names (on daily operations and relationship levels)
vi. Roles and responsibilities of contracting parties including an escalation matrix
vii. Renewal period
viii. Modification clause
ix. Frequency of service reporting
x. Termination clause
xi. Penalty clause
xii. Warranties, including service suppliers’ employee liabilities, 3rd party liabilities and the
related remedies
xiii. Geographical locations covered
xiv. Ownership of hardware and software
xv. Documentation (e.g. logs of changes, records of reviewing event logs)
xvi. Right to have information system audit conducted (internal or external).
10.3 Cross-border System Support
a. The bank shall provide official authorization/assurance to the group who is liable on behalf of the
mother company to ensure data availability and continuation of services for any circumstances e.g.
diplomacy changes, natural disaster, relationship breakdown, discontinuity of services, or others in
applicable cases.
b. The DR Site shall be multi‐layered in terms of physical location and redundancy in connectivity.
10.4 Data Ownership
a. The data related to CBS, Mobile Banking, Card System and any other system in DC and DR (e.g. router
configuration file, firewall configuration file, server patch etc.) will be the sole ownership of Trust Bank.
b. IT Division has to protect and possess all sorts of data of the DC and DR in case of migration of any
technical platform.

Chapter 11
11.0 Alternative Delivery Channels
Alternative Delivery Channel (ADC) is a distribution channel strategy used for delivering financial services
without just relying on bank branches. While the strategy may complement an existing bank branch network for
giving customers a broader range of channels through which they can access financial services. Alternative
Delivery Channel (ADC) can also be used as a separate channel strategy that entirely forgoes bank branches.
The bank’s Digital Banking Division (DBD) shall include the essential ADC channels which are as follows:
a. Use of technology, such as plastic cards, internet or mobile phones, to identify customers and record
transactions electronically and, in some cases, to allow customers to initiate transactions remotely
b. Use of (exclusive or nonexclusive) third-party outlets, such as PayPoints, post offices and small retailers,
that act as agents for financial services providers and that enable customers to perform functions that
require their physical presence, such as cash handling and customer due diligence for account opening
etc.
c. Offer of at least basic cash deposit and withdrawal in addition to transactional fund transfer or payment
services.
d. Structuring of the above so that customers can use these banking services on a regular basis (available 24
hours a day) and without needing to go to bank branches at all.
Examples of branchless banking technologies are the Internet, automated teller machines (ATMs), POS devices,
EFTPOS devices and mobile phones. Each of these technologies serve to deliver a set of banking services and are
part of distribution channels that may be used either separately or in conjunction to form the overall distribution
channel strategy.
The Alternative Delivery Channels of TBL includes:
a. Automated Teller Machine (ATM)

b. Cash Deposit Machine (CDM)
c. Bank POS
d. Pay Points
e. Mobile Banking
f. e-Commerce Transaction
11.1 ATM and POS Transactions
a. Proper physical security and data security should be ensured for ATM and POS transactions. ATM needs
to be installed with following devices:
i. Anti-skimming device to detect the presence of unknown devices placed over or near a card
entry slot.
ii. Tamper-resistant keypads to ensure that customers' PINs are encrypted during transmission
b. Video surveillance activities should be conducted for 24x7 and preserve for at least one year.
c. Centralized online monitoring system for Cash Balance, Loading-Unloading functions, Disorders of
machine, etc. should be installed.
d. There should be a mechanism to detect and send alerts for follow-up response and action.
e. Security personnel will deploy for all ATM devices on 24 hour basis.
f. An inspection schedule have to be maintain all ATM/POS devices frequently to ensure standard practice
(i.e., environmental security for ATM, anti-skimming devices for ATM, POS device surface tempering,

etc.) is in place with necessary compliance. Inspection log sheet shall be maintained in ATM booth
premises and centrally.
g. Necessary manual and training will be provided to merchants about security practices (e.g. signature
verification, device tampering/ replacement attempt, changing default password, etc.) to be followed
for POS device handling.
h. Necessary initiatives (i.e. SMS, Email or any other process) will be taken to educate its customers on
security measures and are to maintain by the customers for ATM and POS transactions.
i. Digital Banking Division shall monitor third party cash replenishment vendors' activities constantly and
visit third party cash sorting houses regularly.
11.2 Internet Banking
Information involved in internet banking facility passing over public networks shall be protected from fraudulent
activity, dispute and unauthorized disclosure or modification. Internet systems may be vulnerable as financial
services are increasingly being provided via the internet. As a counter-measure, security strategy shall be
developed and put in place measures to ensure the confidentiality, integrity and availability of its data and
systems.
11.2.1 Security of Internet Banking
a. Information involved in internet banking passing over public networks should be protected from
fraudulent activity, contract dispute, and unauthorized disclosure and modification.
b. Logical access control techniques may include user-ids, passwords, smart cards or other industry
standards. 2048-bit Certificates encryption with digital certificate should be implemented as required
to ensure data protection.
c. Accuracy, reliability and completeness should be ensured for information processing, storage and
transmission between its clients. Proper tools (e.g. SSL, TLS etc.) should be implemented for processing
and transmission control to ensure system and data integrity.
d. Adequate measures should be placed to plan and track capacity utilization as well as guard against
online attacks including denial-of-service attacks (DoS attack) and distributed denial‐ of-service attack
(DDoS attack).
e. TBL Management may authorize personnel, system auditor or any organization who will undertake
periodic penetration tests of the system with prior approval from the appropriate authority (i.e.
MD/EC/BoD), which may include:
i. Implementation of captcha validation tool to protect against attempt to guess passwords using
password-cracking tools.
ii. Attempting to overload the system using DDoS (Distributed Denial of Service) & DoS (Denial of
Service) attacks.
iii. Attempting to expose system using middleman (man-in-the-middle attack, man-in-the-
browser and man-in-the-application) attacks.
iv. Checking of commonly known holes in the software, especially in the browser and the e-mail
software.
v. Checking the weaknesses of the infrastructure.
vi. Taking control of ports.
vii. Cause application crash.
viii. Injecting malicious codes to application and database servers.
ix. Searching for back doors traps in the programs.

11.2.2 Operation of Internet Banking
a. Account to account fund transfer and different utility bill payment services should be incorporated with
dynamic two factor (2FA) authentication with hardware or software based token system.
b. Session time out for automatic termination should be established with user and re-authentication of
user will be required to resume/maintain the session.
c. Internet Banking Application should have provision to ensure real time security log for unauthorized
access by locking the user id trying more than 03 times.
d. Separate Server need to be used for Internet Banking for the access of the clients / customers from any
location of the world through sufficient security firewalls and policies.
e. Internet banking service should be provided only to clients with system verified email address found in
customer account CRM. Clients with unverified email address won’t be able to apply for internet
banking service.
f. Required system should be developed for monitoring, keep log and report of all system activities,
accesses (including messages received), transmissions and online transactions to subsequently follow
up and address any unusual/ abnormal activities or transactions and errors. Required tools will be
acquired for monitoring systems and networks against intrusions and attacks.
g. High resiliency and availability of online systems should be maintained and supporting systems (such
as interface systems, backend host systems and network equipment).
h. All applications of bank shall have proper record keeping facilities for legal purposes. Bank shall keep
internet Banking Service request form, SMS notification form, email corresponding regarding dispute,
PIN reissue request form all received and sent messages in restricted form.
i. Security infrastructure will properly be tested by IT Division before using the systems and applications
for normal operations. IT Division will be responsible for systems that might be upgraded by installing
patches released by developers to remove bugs, loopholes and upgrade to newer versions which give
better security and control.
11.2.3 Awareness for Internet Banking
a. Digital Banking Division will provide assurance to its clients on protection and authentication of online
access and transactions performed over the internet using printed or web media (e.g. FAQ, brochure,
email etc.).
b. Proper initiatives should be taken to educate clients about threats of and safeguard against them in
online environment using printed or web media (e.g. FAQ, brochure, email etc.).
c. The bank’s official website will maintain a web portal for customers to register for this service and
ensure correct and mandatory information is provided. A process will be uploaded in the portal site.
11.3 Payment Cards
Payment cards exist in many forms; with magnetic stripe cards posing the highest security risks. Sensitive
payment card data stored on magnetic stripe cards is vulnerable to card skimming attacks. Card skimming
attacks can happen at various points of the payment card processing, including ATMs, payment kiosks and POS
terminals.
For payment card services procedure must comply with the industry security standards, e.g. Payment Card
Industry Data Security Standard (PCI DSS) to ensure the security of cardholder's data. The PCI DSS includes
following requirements for security management, policies, procedures, network architecture, software design
and other protective measures.
a. Card Division shall implement adequate safeguards to protect sensitive payment card data.
b. It shall be ensured that sensitive card data is encrypted to ensure the confidentiality and integrity of
these data in storage and transmission.
c. It shall be ensured that the processing of sensitive or confidential information is done in a secure
environment.
d. Secure chips shall be implemented with multiple payment application supported to store sensitive
payment card data.
e. For interoperability reasons, where transactions could only be resulted by using information from the
magnetic stripe on a card, the Bank shall ensure adequate controls are implemented to manage these
transactions.
f. Card Operation team shall perform (not a third party payment processing service provider) the
authentication of customers' sensitive static information, such as PINs or passwords.
g. Card Division and IS Audit team shall perform regular security reviews of the card infrastructure and
processes being used by its service providers.
h. Equipment’s used to generate payment card PINs and keys shall be managed in a secured manner.
i. Card personalization, PIN generation, Card distribution, PIN distribution, Card activation groups shall
be different from each other.
j. Card Division shall ensure that security controls are implemented at payment card systems and
networks. Card division shall ensure industry security standards, e.g. – Payment Card Industry Data
Security Standard (PCI DSS) to ensure the security of cardholder's data.
k. New cards will be activated upon obtaining the customer’s instruction.
l. Dynamic one-time-password (“OTP”) shall be implemented as 2-FA for CNP (Card Not Present)
transactions via internet to reduce fraud risk associated with it.
m. To enhance card payment security, notification to cardholders via transaction alerts including source
and amount for any transactions made on the customers’ payment cards should be provided.
n. Card Division in consultation with RMD and IT Security Unit shall set out risk management parameters
according to risks posed by cardholders, the nature of transactions or other risk factors to enhance
fraud detection capabilities.
o. Mechanism should be developed to secure sensitive card data as per PCIDSS compliance. Card data has
to be encrypted to ensure the confidentiality and integrity of these data in storage and transmission.
p. Card Division may implement solution to follow up on transactions exhibiting behavior which deviates
significantly from a cardholder's usual card usage patterns. Such system may be adopted to investigate
transactions and obtain the cardholder's authorization prior to completing the transaction.
11.3.1 Payment Card Industry Data Security Standard (PCIDSS):
Bank providing the payment card services must comply with the industry security standards, e.g.‐ Payment Card
Industry Data Security Standard (PCIDSS) to ensure the security of cardholder’s data. PCIDSS can be acquired by
sharing or by third party vendor. The PCI DSS includes following requirements for security management, policies,
procedures, network architecture, software design and other protective measures:
a. PINs used in transactions should be processed using equipment and methodologies to ensure that they
are kept secured.
b. Cryptographic keys used for PIN encryption/decryption and related key management should be created
using processes to ensure that it is not possible to predict any key or determine that certain keys are
more probable than other keys.
c. Secret or private Keys should be conveyed or transmitted in a secured manner.
d. Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be
displayed).
e. Unencrypted Key loading to hosts and PIN entry devices should be handled in a secured manner.
f. Randomized Keys should be used in a manner that prevents or detects their unauthorized usage.
g. Keys should be administered in a secured manner.
h. Equipment used to process PINs and keys should be managed in a secured manner.

i. The full contents of any track (track 1 or track 2) from the magnetic stripe (on the back of the card, in a
chip, etc.) must not be stored.
j. The card-validation code or value must not be stored. The personal identification number (PIN) must
not be stored.
11.3.2 Card Data Retention Policy

a. Storage of cardholder data is kept to a minimum in line with legal, regulatory, and business
requirements.
b. Sensitive authentication data is not stored post authorization. Sensitive authentication data consists of
either the full contents of track 1 or 2, the card verification code or value, or the personal identification
number (PIN) or encrypted PIN block.
c. Upon approval from the MD/EC/BoD on a periodic basis, systematically removes and destroys all
cardholder data that has exceeded its retention period and to review and ensure remaining stored
cardholder data to ensure that it remains within the formal retention requirements. For, card data
storing in third party end, written confirmation from TBL is essential to remove or destroying card data.
d. The PAN should be masked wherever it is displayed, whether electronic or on paper. The first six and
last four digits are the maximum number of digits that may be displayed.
e. Wherever the PAN is stored (including logs, removable media, etc.), it is made unreadable by means of
one way hashes/truncation/index tokens/strong cryptography. If hashing and truncation are both used
together controls should be put in place to prevent PAN from being reconstructed via correlation
between the types by possibly using salt.
f. Cardholder data is never stored on removable media or where cardholder data is stored on removable
media and is protected by means of disk encryption, logical access is managed independently of native
operating system access control mechanisms (for example, by not using local user account databases).
Decryption keys are not tied to user accounts.
g. When removable physical storage media (including documents, faxes, and electronic media) are no
longer required (i.e. they have passed their retention periods), they are destroyed as set out in specific
policy set by appropriate authority (i.e. MD/EC/BoD).
11.4 Auxiliary Services

11.4.1 SMS Banking Service
SMS Banking Service enables clients to know their account balances and mini statements instantly by just
sending an SMS. SMS Banking service also provides instant notification regarding ATM, POS and salary
disbursement transactions as and when it happens. SMS banking standards has been included in the TBL ICT
Security Policy by taking following measures:
a. Firstly, customer has to register for this service by filling up a prescribed form and ensure latest mobile
number is updated with the Bank. The mobile number will then be linked to the client’s account.
b. When opening an account in for SMS Banking service, it’s important for the customer and the bank to
make sure that correct and complete information, and that the information is verified and protected.
11.4.2 Phone Banking Service
Phone Banking Service enables clients to know their account balances and mini statements instantly though a
telephonic call. To access this service customer must fill up the Phone Banking Application Form and must
acknowledge the Terms & Conditions for the service.
a. Firstly, customer has to register for this service by filling up a prescribed form.

b. Customers are required to call to a number, then enter account number and validate it by entering
Phone Banking PIN. Once done successfully, customer will be able to hear a recorded voice providing
necessary instructions for hearing the Balance and Mini statement enquiry.
11.5 Contact Center Security

A contact center is central point in an enterprise from which all customer contacts are managed. Contact
Centers, because of the high volume of interaction with unfamiliar voices, are a prime target for security threats.
There are many points of possible failure when it comes to contact center security, from hardware to data to
the people who work there.
a. Proper customer verification process must be ensured to reduce identity theft/fraud. Agents shall ask
random security questions i.e. Father’s/Mother’s/Spouse's Name, Address/Date of Birth or Last Few
Transaction details to verify customers identify.
b. Voice network access should be ensured by device certificate and/or user name and password.
c. Calls restriction should be enforced by device, user, and other criteria, such as time of day.
d. Security devices i.e. Firewall/IPS to be implemented to monitor and filter authorized and unauthorized
VoIP traffic, and track unusual voice activities.
e. Regular OS updates should be implemented for all VOIP devices.
f. Separate VLANs to be used to segment Voice Traffic from Data Traffic.
g. Voice Traffic should be encrypted to protect sensitive customer information.
h. IP-PBX server should be hardened with unnecessary services disabled.
i. SSH Root access should be disabled with SSH login via Secure Key and change default ports.
j. The IP-PBX system should be installed in a secure location with restricted access.
k. VoIP logging should be enabled to monitor activity.

Chapter-12
12.1 Customer Education
With the advent of electronic Banking, customer’s experience of Banking is therefore no longer fully under
control of a Bank. Customers are equipped to do Banking through self-help. The best defense against frauds is
awareness of customer. Fraudsters constantly creating more diverse and complex fraudulent mechanism using
advanced technology and social engineering techniques to access their victims accounts. Therefore it is
imperative for Banks to conduct regular awareness program among consumers.
It is also important to educate other stakeholders, including bank employees, who can then act as resource
persons for customer queries, law enforcement personnel for more understanding response to customer
complaints and media for dissemination of accurate and timely information.
The awareness program can be carried through awareness material, advertisements, promotion campaign and
official website. The following communication channel could be used to engage customers successfully.
a. Advertising campaigns though print and TV media

b. ATM screens, Emails and SMS texts
c. Common website developed with content from all stakeholders
d. Groups, games and profiles on social media
e. Advertisements on online shopping sites
f. Bill boards
g. Online training modules and demos hosted on this site
h. Posters in prominent locations such as petrol pumps, popular restaurants, shopping malls, etc.
i. Interactive guidance in the form of helplines
j. Customer meets and interactive sessions with specialists
k. Talk shows on television/radio
12.2 Customer Awareness Program
a. Concern Division/Department/Branch should develop procedures to identify its customer classification

based on customer type, nature of transaction and understanding capability as per the guideline of
Operations Divisions.
b. Dedicated yearly budget should be allocated yearly for conducting awareness program.
c. Awareness program work plan needs to be prepared and reviewed on regular basis by a committee or
by a team. Term of References of the team or committee should have the following major activities:
 Preparing work plan
 Define objective of the program
 Formulating primary channels for the program
 Formulating program through interactive broadcast media
 Outcome/Effectiveness of each awareness program
12.2.1 Preparing work plan
The work plan needs to cover the followings:

a. Required Resource
b. Timeline of the program
c. Milestones of the program
d. Prepare awareness content
e. Define audience for the program
f. Budget for conducting the program
12.2.2 Define objective of the program
a. Provide information about fraud risk trends, types or controls to target customers or people need to
know.
b. Help consumers to identify areas of vulnerabilities to fraud attempts and make aware of their
responsibilities in relation to fraud prevention.
c. Help to build a strong culture of security and associated risk with better understanding and
commitment.
d. Help to reduce the number of incidents related to direct and indirect loss for the bank.
e. Ensure effectiveness of the program by delivering through appropriate channel.
f. Motivate individuals to adopt recommended guidelines or practices.
12.2.3 Formulating primary channels for the program
Awareness building collaterals can be created in the form of:

a. Leaflets and brochures
b. Emails and SMS texts
c. Safety tips in account statements and envelopes
d. Educational material in account opening kits
e. ATM screens and receipts dispensed by ATM/POS
f. Screensavers
g. Bulletins in Website and electronic newsletters
h. Recorded messages played during waiting period of phone banking calls
12.2.4 Formulating program through interactive broadcast media
a. Advertising campaigns though print and TV media

b. Groups, games and profiles on social media
c. Advertisements on online shopping sites
d. Bill boards
e. DVDs with animated case studies and videos
f. Online training modules and demos
g. Posters in prominent locations such as petrol pumps, popular restaurants, shopping malls, etc.
12.2.5 Outcome/Effectiveness of each awareness program
Continuous improvement cannot occur without knowing how the existing program is working. A well-calibrated
feedback strategy must be designed and implemented. Since the target groups obtain information from a variety
of sources, primary and interactive communication channels may not be adequate. Effective of the program can
be generated in more by introducing the followings:
a. Interactive guidance in the form of helplines
b. Customer meets and interactive sessions with specialists
c. Talk shows on television/radio

Chapter-13
13.1 Human Resources Security Management
This chapter describes how the Bank establishes appropriate processes for the employment of manpower and
resources for managing its security programs efficiently and effectively.
The Bank shall establish necessary processes to ensure that suitable and qualified employee and resources are
hired in order to effectively manage its security investments and initiatives.
13.1.1 Prior to Employment

a) Information Security roles and responsibilities of employees, vendors and any third parties shall be
defined and documented.
b) Roles of employee in ensuring protection of information assets from unauthorized access, disclosure,
modification, destruction or interference shall be clearly stated.
13.1.2 Screening
Human Resources Division (HRD) shall conduct background verification and checks for all candidates upon
employment with the Bank in accordance with relevant laws, regulations, ethics and proportional to the
classification of the information to be accessed. HRD shall observe the following controls when considering a
candidate for employment:
a) Take actions commensurate with the Bank’s business needs, and with relevant legal regulatory
requirements.
b) Take into account the classification(s)/sensitivity of the information to be accessed, and the perceived
risks.
c) Include in the recruitment process, where appropriate, components such as identity verification,
character references and Curriculum Vitae verification based on the sensitivity of the job position.
13.1.3 Terms and Conditions of Employment
Employees as well as third parties to the Bank are obliged to sign the terms and conditions of their employment
or engagement which will clearly state their responsibilities as regards Information Security during their regular
course of work. The following terms shall apply:
a) A Confidentiality Agreement shall be signed by all employees as well as third parties before access is
granted to sensitive information.
b) Legal responsibilities and rights regarding copyright laws or data protection legislation shall apply.
c) Responsibilities of employees, vendors or third parties for handling of information received from other
companies or external parties are stated.
d) At the time of induction, employees shall be given training/orientation on the Information Security
Policy and means to access it for their reading and understanding.
e) All users must acknowledge the information security policies for adherence in writing or electronically.
13.1.4 Information and Cyber Security Awareness Program

Educating on information and cyber security is imperative for a secure cyberspace. All employees shall receive
appropriate awareness training and regular updates of the Bank’s policies and procedures relevant to their job
functions. These trainings are intended to enhance employee awareness in order to recognize information
security problems and incidents, and respond accordingly. The Bank shall provide training to cover the following:

a) HRD and Information Security Department shall maintain an ongoing (for new hires) and annual (for
existing users) security awareness program. The Security Awareness program shall provide multiple
methods of communicating awareness and educating personnel about the importance of data security.
b) HRD and Information Security Department shall ensure that user each user acknowledge the
organizational information security policy.
c) The effectiveness of the information security program shall be measured.
d) Ensuring adherence to the security policies of the Bank with appropriate sanctions.
e) Develop cyber security awareness training contents, taking cognizance of the prevailing cyber threats,
cyber risk, and various attack-vectors.
f) Ensure that the content of the awareness training include information contained in bank’s security
policy, roles and responsibilities of all parties, and emerging cyber –threats.
g) Mandate all Board members and employees to participate the training program.
h) Ensure that third-party/vendor also undergo the Bank’s security awareness program as well.
13.1.5 Termination and Change of Employment
a) Responsibilities for performing employment termination or change of employment shall be clearly

defined and assigned.
b) Employees shall return the assets in their possession on termination of their employment or contract.
c) The reporting manager with support of HRD and IT Support team is responsible to ensure that the
access rights across all applications and systems have been removed immediately on termination of
their employment or contract.
d) The access rights of employees shall be modified immediately upon change of their role. The reporting
manager shall initiate request to IT support Team for changing the access privileges of the user and
update HRD accordingly.
13.1.6 Social Media Policy
a) Employees shall limit personally identifiable information (e.g. Mobile, email, House address, family
details etc.) while using social networking sites like Facebook, Twitter, LinkedIn, Instagram etc. They are
also encouraged not to accept friend/connection request blindly on social sites.
b) Employees shall not post official document to social sites.
c) Employees shall not post/like/share subversive, false, hatred, politically motivated, defamatory,
controversial or otherwise objectionable content, page or group.
d) Employees shall avoid posting status updates/details about current location or
itinerary/vacation/recreational information to reduce identification.
e) Corporate Branding & Market Communication Department (CBMC) shall be responsible for maintaining
official Facebook/Twitter/LinkedIn account.
13.1.7 Social Engineering Policy
a) Employees shall not discuss official matters in public.

b) Employees shall not collect/use any unattended removable storage device.
c) Employees shall not share confidential information with strangers over the phone.
d) Employees shall be suspicious if unknown person contacts for sensitive information.
e) Employees shall never click link within an email/SMS/Messaging App (WhatsApp,
Messenger/Viber/Telegram etc.) and respond to unsolicited email, forward chain email to get
reward/cash.
f) Employees shall be aware of Shoulder Surfing when using ATM, laptop and mobile in public places.
g) Employees shall not use public Wi-Fi to perform transactions or use credentials to access TBL resources.
h) Employees shall not use public charging stations for charging mobiles.

13.2 Sanctions on ICT Security Policy Violations
The goal of ICT security policy is not only to ensure compliance to the requirements but also, to impart discipline.
Internal compliance indicates that the employees are aware and willing to follow the rules and regulations set
out by ICT security policies.
Strict compliance to ICT security policies and guidelines is expected at all times by all employees of the Bank and
appropriate penalties shall be meted out for non-compliance. ICT security policies specifically relate to the under
listed and extend to other associated policies not listed below.
 Acceptable Use Policy

 Access Control Policy
 Internet Access Management Policy
 Email Management Policy
 Password Management Policy
The following represents infraction levels and commensurate sanctions based on severity of the policy
violations.
1. Level I Violators: They shall be verbally cautioned by appropriate authority.
2. Level II Violators: They shall be served a written query and expected to give a written undertaking never to
repeat same.
3. Level III Violators: Shall be issued a stern warning letter (this has a huge bearing on performance appraisal)

Acronyms
2‐FA ‐ Two Factor Authentication
AD -Administrative Division
AMC ‐ Annual Maintenance Contract
AML ‐ Anti‐Money Laundering
BCP ‐ Business Continuity Plan
BRP ‐ Backup and Restore Plan
CBS -Core Banking System
CCTV ‐ Close Circuit Television
CD ROM ‐ Compact Disk Read Only Memory
CERT - Computer Emergency Response Team
CISO - Chief Information Security Officer
CRO - Chief Risk Officer
DC ‐ Data Center
DDOS ‐ Distributed Denial of Service
DLP -Data Loss Prevention
DOS ‐ Denial of Service
DR ‐ Disaster Recovery
DRP ‐ Disaster Recovery Plan
DRS ‐ Disaster Recovery Site
EC -Executive Committee
E‐mail ‐ Electronic Mail
FIs ‐ Financial Institutions
HRD - Human Resources Division
I‐banking ‐ Internet Banking
ICT ‐ Information and Communication Technology
IDS ‐ Intrusion Detection System
IPS ‐ Intrusion Prevention System
IT ‐ Information Technology
ITD - Information Technology Division
JD ‐ Job Description
LAN ‐ Local Area Network
PAN -Permanent Account Number
PCI DSS ‐ Payment Card Industry Data Security Standard
PCs ‐ Personal Computers
PDA ‐ Personal Digital Assistant
PIN ‐ Personal Identification Number
PKI ‐ Public Key Infrastructure
PT- -Penetration Test
P&P -Purchase & Procurement
SDLC ‐ Software Development Life Cycle
SLA ‐ Service Level Agreement
SOC - Security Operations Center
SSL ‐ Secured Socket Layer
UAT ‐ User Acceptance Test
UPS ‐ Uninterrupted Power Supply
User ID ‐ User Identification
VLAN ‐ Virtual Local Area Network
WAN ‐Wide Area Network
TBL - Trust Bank Limited
RMD -Risk Management Division
VA -Vulnerability Assessment
VPN -Virtual Private Network

Annexures

Annexure 1
Service Request Form
Reference No:
Internet Access CBS Access New Hardware/Software Domain/email Access Others
Initiator Details
Employee Name
Email Address
Employee ID
Office Extension
Request Date
Request Details with Business Justification
Business Owner/Supervisor Approval
Department Name HOD Signature and Date
Head, IT Division Signature and Date:

Annexure 2
User Acceptance Test
TEST CASE
TEST REF. TEST MANAGER: DATE:
ACTIVITY CHECKLIST (please attach detailed test scripts)
SN TASK STATUS
REF. TEST SCRIPT PASS FAIL
PAGE
1
2
3
4
5
6
7
REMARKS: SATISFACTORY UNSATISFACTORY
COMMENTS:
NAME COMMENTS SIGN & DATE

Annexure 3
Dispensation Form
Reference: Date:
Section I : Requester Information
Bank Name :
Branch/Division Name :
Requested by :
Requestor's Designation :
Requestor's Telephone :
Request Date :
Section II : Risk Overview
Guideline reference (Clause) and description:
………………………………………………………………………………………….………………………………………………………………………………
Risk Details (Process/Application/System/Product):
………………………………………………………………………………………….………………………………………………………………………………
Justification:
………………………………………………………………………………………….………………………………………………………………………………
Plan of mitigation:
…………………………………………………………………………………….……………………………………………………..…….
Mitigation Date:
Section III : Approvals
The undersigned agree and accept the risk documented on this form.
Name :
Designation :
Comments :
Date :
Signature & Seal :

Annexure 4
Incident Reporting Form
Reference No:
Incident Type: Internet CBS Database Network Hardware Others
Initiator Details:
Name Division/Department
Employee ID Signature Approx. Loss Amount
Incident Date Reporting Date Incident Duration
Details of Incident with Effects of to Business:
Business Unit Affected by the Event/Loss: Network
Name Employee ID Signature and Date
The Control which exists but Failed or Did not exists:
Recommended for Future Reoccurrence:

Annexure 5
Remote VPN Access REQUEST FORM
Third Party/Vendor Details
Name
Email Address
Company Name
Address
Contact Number
Request Date
Access Duration Start Date & Time End Date & Time
TBL Contact &
Designation
Request Details with Business Justification
(Page 1 of 3)

VPN DESTINATION INFORMATION
Server Name IP Address Service Port Application Name
TECHNICAL CONTACTS
The details provided in this section are to facilitate technical communication between TBL and the Connecting
Party in order to implement the new connection.
Contact Information Customer Technical POC TBL Technical POC

Name
Email Address
Primary
Desk Phone
Cell Phone
Alternate Phone/Pager
Name
Email Address
Secondary
Desk Phone
Cell Phone
Alternate Phone
Device name
Hardware
Model
Connection Type
(Page 2 of 3)

For Test Configuration:
TBL End point WAN IP

TBL Side IP Block
Key Management
Hashing Algorithm
Encryption Algorithm
Authentication Algorithm
Phase 1 Proposal
Phase 2 Proposal
Encapsulation
Lifetime
Pre shared Key
Partner End point WAN IP
Partner LAN SIDE IP Block
Protocol/Port
For Production (Primary) Config:
TBL End point WAN IP

TBL Side IP Block
Key Management
Hashing Algorithm
Encryption Algorithm
Authentication Algorithm
Phase 1 Proposal
Phase 2 Proposal
Encapsulation
Pre shared Key
Lifetime
Partner End point WAN IP
Partner LAN SIDE IP Block
Protocol/Port
(Page 3 of 3)

To Comply Board Approved ICT Security Policy Version 4.3 2023

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

To Comply Board Approved ICT Security Policy Version 4.3 2023

Uploaded by

Copyright:

Available Formats

ICT Security Policy

Information Technology (IT) Division

©Trust Bank Limited

Next Revision 15-05-24

Document Classification Internal Use Only

Document Change Control

4.3 16-05-23 CISO Revision & Modification

Revision Date Author Change History

1.2 Information Security Management Framework

1.3 Information Security Management System (ISMS) Objectives

a. Protect the confidentiality, integrity, and availability of TBLs information assets;

a. Technology infrastructure, information and communication systems

1.5 Acceptable Use Policy

1.5.1 Unacceptable Use

©Trust Bank Limited Internal Page 3

1.9 Policy Modification

©Trust Bank Limited Internal Page 4

2.0 ICT Security Management

2.1 Objective of Information Security

2.2 ICT Governance

©Trust Bank Limited Internal Page 5

a. Approving ICT strategy and policy documents

2.2.2 ICT Steering Committee

Formation of the ICT Steering Committee

Major Functions of ICT Steering Committee

©Trust Bank Limited Internal Page 6

Formation of the ICT Security Committee

Major Functions of ICT Security Committee

a. Documents are to be preserved in two ways:

2.4 Internal Information System Audit

2.5 External Information System Audit

©Trust Bank Limited Internal Page 8

©Trust Bank Limited Internal Page 9

3.0 ICT Risk Management

3.1 ICT Risk Governance

3.2 ICT Risk Assessment

3.3 ICT Risk Response

©Trust Bank Limited Internal Page 12

4.0 ICT Service Delivery Management

4.1 Change Management

Change is defined as anything—hardware, software, system components, services, documents, or processes—

4.1.1 Change and Configuration Management Policy

©Trust Bank Limited Internal Page 13

4.2.1 Computer Emergency Response Team (CERT)

4.2.2 Incident Management Policy

©Trust Bank Limited Internal Page 14

4.3 Problem Management

4.3.1 Objective of Problem Management

a. Proactive prevention of Incidents and Problems

4.3.2 Problem Management Policy

a. Any incident that is marked with different problem severity level

4.4 Capacity Management

4.4.1 Capacity and Performance Management

a. Availability and performance requirements

4.4.2 Performance Monitoring of IT Resources

4.4.3 Capacity Planning of IT Resources

©Trust Bank Limited Internal Page 16

IT Resources Capacity Plan

©Trust Bank Limited Internal Page 17

5.0 Infrastructures Security Management

5.1 Infrastructure Security Governance

5.2 Hardware and Software Security Policy

©Trust Bank Limited Internal Page 18