public document request for proposal project name: for …

83
PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: IT Infrastructure Tech Refresh, Application Development and Support for IBF e-Services RFP.IT.2021.0002 The Institute of Banking & Finance 10 Shenton Way #13-07/08 MAS Building Singapore 079117 Tel: 62208566 Fax: 62244947 Email: [email protected]

Upload: others

Post on 28-Apr-2022

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

PUBLIC DOCUMENT

REQUEST FOR PROPOSAL

Project Name:

IT Infrastructure Tech Refresh, Application Development and Support for IBF e-Services

RFP.IT.2021.0002

The Institute of Banking & Finance 10 Shenton Way

#13-07/08 MAS Building Singapore 079117

Tel: 62208566 Fax: 62244947

Email: [email protected]

Page 2: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 2 of 83

CONTENTS

1. INTRODUCTION ................................................................................................... 3

2. BACKGROUND ..................................................................................................... 3

3. PROJECT VISION .................................................................................................. 4

4. OBJECTIVE ........................................................................................................... 4

5. SCOPE OF SERVICES ............................................................................................. 5

6. PROJECT DELIVERABLES & SCHEDULE .................................................................. 8

7. EVALUATION CRITERIA ........................................................................................ 9

8. SUBMISSION DETAILS .......................................................................................... 9

9. BRIEFING ........................................................................................................... 11

10. RIGHTS TO THE PROJECT DELIVERABLES ............................................................ 11

11. EXPENSES .......................................................................................................... 11

12. PAYMENT .......................................................................................................... 11

13. CONFIDENTIALITY.............................................................................................. 11

14. SECURITY CLEARANCE ....................................................................................... 12

15. INDEMNITY AGAINST A THIRD PARTY ................................................................ 12

16. ACCEPTANCE OR NON-ACCEPTANCE OF PROPOSAL ........................................... 12

17. TERMINATION ................................................................................................... 13

18. DELAY IN PERFORMANCE .................................................................................. 13

19. SUB-CONTRACTING AND ASSIGNING ................................................................. 14

20. GOVERNMENT REGULATIONS ............................................................................ 14

21. NOTIFICATION OF UNSUCCESSFUL BID ............................................................... 14

22. ENQUIRIES ........................................................................................................ 14

ANNEX 1: REQUIREMENT SPECIFICATIONS ..................................................................... 15

1. GENERAL REQUIREMENTS ......................................................................... 15

2. REQUIREMENT SPECIFICATION .................................................................. 31

ANNEX 2: PROPOSAL TEMPLATE .................................................................................... 44

ANNEX 3: DOCUMENTATION ......................................................................................... 76

Page 3: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 3 of 83

1. INTRODUCTION

1.1 The Institute of Banking and Finance (“IBF”) is issuing this Request for Proposal (“RFP”) to identify

suitable entity(ies) (hereinafter referred to as the “Vendor”) to submit proposals for the provision of IT

Infrastructure Tech Refresh, Application Development and Support for IBF e-Services. The proposal shall

include replacement of aging hardware, software; and migration of services.

2. BACKGROUND

2.1 The Institute of Banking and Finance Singapore (IBF) was established in 1974 as a not-for-profit industry

association to foster and develop the professional competencies of the financial industry. IBF represents

the interests of close to 200 financial institutions including banks, insurance companies, securities

brokerages and asset management firms. In partnership with the financial industry, government

agencies, training providers and the trade unions, IBF is committed to equip practitioners with

capabilities to support the growth of Singapore’s financial industry.

2.2 IBF is the national accreditation and certification agency for financial industry competency in Singapore

under the Skills Framework for Financial Services, which were developed in partnership with the

industry. The Skills Framework for Financial Services sets out the job descriptions, critical work functions,

key tasks and skills for 157 financial services job roles. It is designed to help financial practitioners to plan

for their career progression and to identify skills needed in current or new job role, while supporting

financial institutions in talent attraction, performance management and skills development. Individuals

who complete the IBF-accredited skills training programmes against the Skills Framework for Financial

Services and meet the relevant criteria may apply for IBF Certification.

2.3 Under Workforce Singapore’s Adapt and Grow initiative, IBF is the appointed programme manager for

the administration of professional conversion programmes for the financial industry. As programme

manager, IBF will partner financial institutions to re-skill employees for expanded roles and opportunities

in growth areas.

2.4 IBF also provides personalised career advisory and job matching services to Singapore Citizens and

Singapore Permanent Residents exploring a new role in, or career switch into the financial industry,

under IBF Careers Connect.

2.5 IBF Portal & eServices is the core system for IBF operations and single online platform to streamline

processes and enhance engagement amongst the stakeholders. It consists of:

a) Web Content Management System (https://www.ibf.org.sg) – to maintain and publish IBF website

contents.

b) Portal e-Services (https://eservices.ibf.org.sg) – digital services for FIs / FTPs / Individuals to transact

with IBF on matters such as submission of programme recognition and funding, examination

registration, certification application, integration with SARAS Exam System, etc.

Page 4: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 4 of 83

2.6 IBF eServices modules as listed in Diagram 1:

Diagram 1: IBF Portal e-Services Modules

3. PROJECT VISION

3.1 IBF’s vision for this project aims to make improvements to the current digital assets and architecture for

IBF eServices, and to prepare IBF to meet the digital aspiration and be enabled with Future-Ready digital

solution.

4. OBJECTIVE

4.1 IBF invites Vendors to submit proposal / quotes for the design, supply, installation, configuration,

migration, testing and commissioning of IBF eServices Infrastructure Tech Refresh and Application

Development/Maintenance.

4.2 Awarded Vendor shall complete the project which includes Tech Refresh, taking over of Infrastructure

Managed Services and Application Development/Maintenance within two (2) months upon award.

4.3 The Vendor shall propose improvement to the current IBF eServices to improve performance and

security, meet IBF’s digital aspiration and delight users, and the proposed solution shall allow for data

analytics capabilities and interfaces (APIs) for information exchanges.

4.4 The Vendor shall propose hardware replacements and architecture that are equivalent or better,

scalable, secured, with necessary secure network provisioning policy, network segmentation and access

control policy.

Page 5: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 5 of 83

4.5 The Vendor shall propose industry standard methodology (e.g. Agile, DevOps, DevSecOps) to achieve

efficient development cycles that allow faster innovation with continuous improvement driven by user

needs and delight the users.

4.6 The Vendor shall propose a migration plan to seamlessly transit all legacy to new replacement appliances

with minimal disruption to IBF operations and end users. The Vendor shall always ensure interoperability

between hardware from different manufacturers and adherence to security, governance and

compliance. Every stage of migration must have audit trail documented.

4.7 The Vendor shall appoint a dedicated project team consisting of qualified Change Manager, Project

Manager, Solution Architect and Security Architect to ensure the smooth delivery of this project.

4.8 The Vendor shall propose a handing-over/taking-over strategy with outgoing vendor and ensure a

smooth and comprehensive taking-over with proper documentation for IBF acceptance. During the

execution of this process, disruption to IBF eServices should be minimal.

4.9 The proposed hardware, software and architecture shall support at least 100 concurrent IBF visitors at

any given point of time and allow scaling-up while upkeeping optimal performance.

4.10 The Vendor shall manage and provide the necessary hardware/software, resources, tools and processes

to setup, configure and perform troubleshooting that may arise during the implementation of this

project.

4.11 The Vendor shall ensure all infrastructure, data, application and related design, development and

delivery are developed with Security-by-Design.

4.12 The Vendor shall appoint a dedicated Risk Manager throughout the project and conduct a

comprehensive risk assessment, identify and describe high risk and key risk areas and propose

recommendations to remediate the identified risks/gaps to IBF for approval, prior to the start of the

project.

5. SCOPE OF SERVICES

5.1 Category 1 – Infrastructure Tech Refresh, Hosting, Licences and Maintenance

a) Assessment of existing Infrastructure and Application Architecture

b) Supply of Hardware, Software, Licences and Professional Services for full technical refresh on

Private Hosting (Scalable Hyper-converge Infrastructure, equivalent or better)

c) Supply of Managed Services

d) Maintenance with SLA of 99.5% uptime for Hardware, Software, Hosting services

e) Supply of Migration services

f) Supply of Public DNS Hosting Services

Page 6: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 6 of 83

g) Windows & VMware patches and updates

h) Antivirus, malware patches and updates

i) Firmware updates/upgrades

j) DR and BCP services

k) Project Management to provide weekly update on progress

l) Professional services to setup and configure hardware/software must be perform by engineers

certified by respective product principal

m) Onsite survey to calibrate and fine tune to achieve specification requirement

n) System configuration documentation & training for Administrators and Users

o) Onsite Resident engineer(s) reporting to IBF appointed IT representative to configure,

troubleshoot, perform remedy and break fix till system commission and acceptance by IBF

p) All required licences to operate the proposed equipment and hardware break fix maintenance

from original equipment manufacturer

q) Professional services to setup and configure hardware/software/tools must be perform by

engineers certified by respective product principal

5.2 Category 2 – Application Development and Maintenance

a) Assessment and improvement of existing Application Architecture

b) Setup tech refreshed environment and migration of existing services (.Net and SharePoint)

c) Patching and updates for Operating System and any software/tools

d) Perform periodic security assessment and remediation

e) SLA of 99.5% availability for services

f) DR and BCP services

g) Assess current digital asset and propose solution to meet IBF’s digital aspiration with Future-

Ready digital solution.

h) Project Management to provide periodic update on progress

i) Professional services to setup and configure software/tools must be perform by engineers

certified by respective product principal

5.3 Vendors are invited to quote for Category 1 and Category 2 and related services to meet IBF needs.

5.4 The Vendor shall fulfil all requirements stated in Annex 1: Requirement Specifications.

5.5 The proposal shall quote for:

a) Category 1 for an initial maintenance Contract Period for five (5) years; and

b) Category 2 for an initial maintenance Contract Period for two (2) years with an option to extend

it each year for the next two (2) years on the same terms and conditions, and any other terms

that may be mutually agreed by the IBF and the Vendor in writing.

Page 7: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 7 of 83

5.6 The Vendor shall include the migration of IBF Web Content Management System (IBF Portal), but with

consideration that it may be decommissioned within the next twelve (12) months. The cost involved for

WCMS should be kept minimal.

5.7 This RFP shall be conducted in three (3) phases. (Refer to Para 6. Project Deliverables and Schedule).

5.8 The Vendor is required to submit a proposal with reference to ‘Submission Details’ under Paragraph 8,

and using the template under Annex 2: Proposal Template.

Page 8: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 8 of 83

6. PROJECT DELIVERABLES & SCHEDULE

6.1 The Vendor shall complete the project deliverables based on the stipulated timeline:

Phase Project Deliverables Timeline

1 Pre-migration Planning, Acceptance and Execution

a) Evaluation and understanding of existing (AS-IS) Infrastructure and Application Architecture and submission of Detailed Execution Plan for IBF’s acceptance.

b) Detailed Execution Plan to consist of TO-BE architecture, Schedule, Risk Management Plan, Security Plan, Migration Plan, Testing Plan, Key Performance Metrix etc.

c) Gap analysis between IBF's current state Infrastructure and Application Architecture and the proposed Future State Architecture.

d) Derive a Master Plan for IBF to monitor the implementation and manage the deliverables.

e) Derive a Risk Management Plan on approach to identify high risk and key risk areas and management of risk, with the tools and procedures to be used to identify, assess, mitigate and report risks throughout the project duration

f) Upon acceptance of Detailed Execution Plan, communicate to key stakeholders including IBF’s incumbent vendor(s).

g) Setting up of Hosting, Hardware, Software, Licences Installation, Hardening and Security Testing

h) Test-migration of IBF Portal & eServices into new infrastructure to be performed with all key performance metrics met with data fidelity testing. This includes connectivity testing to all interfaces and external systems (SARAS, eNETS, H2H etc).

i) Pilot testing to be performed with IBF Business Teams.

j) Security Review and Compliance to be reviewed by IBF Risk and Governance Team and any deviation highlighted and submitted to IBF management for review

6 weeks

Page 9: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 9 of 83

2 Migration, Go-live and Post-Migration Monitoring

a) Full-Dress Rehearsal and mitigation of any residual risk

b) Data Migration, cut-over of Services and verification

c) Go-Live

d) Monitoring of Services

2 weeks

3 Handing-over and Taking-over of Services

a) Derive and propose a measurable and quantifiable plan to IBF on what constitutes a successful project outcome

b) Discussion and agreement of handing-over/taking-over plan and schedule with outgoing vendor.

c) Knowledge transfer and Documentation

On-going

Note: In view of the COVID-19 situation, vendor to ensure the activities conform to all guidelines and precautionary measures in accordance with the advisories issued by MOH, MOM, MTI and other relevant Singapore government agencies.

6.2 IBF reserves the right to award the project by phases based on the proposals submitted. The

appointment of the Vendor shall also be subject to review for re-appointment at the end of each phase.

6.3 All deliverables described in section 6.1 shall be submitted to IBF for approval and Vendor may be

required to present the deliverables.

7. EVALUATION CRITERIA

7.1 The following are the criteria and weightage (%) used to evaluate all proposals received by IBF for this

RFP:

a) Ability to provide a proposal that fulfils IBF’s project objectives and scope of services (50%);

b) Vendor’s experience and track record (20%);

c) Price competitiveness (30%).

7.2 IBF may evaluate based on the proposals submitted by Vendors and any other information provided by

Vendors at the request of IBF, pursuant to the proposal submission.

7.3 As part of the evaluation process, shortlisted Vendors may be required to present their credentials and

proposals to IBF Management.

8. SUBMISSION DETAILS

8.1 The submitted proposal shall comprise:

Page 10: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 10 of 83

a) An executive summary of the company’s understanding of IBF’s project objectives and scope of

services.

b) Details of proposal including project planning, execution and reporting.

c) Experience and track record:

i. Provide a brief on the qualifications, relevant certifications and experiences of the staff(s)

assigned to the project and describe their respective roles in the project team. Please

provide the curriculum vitae (“CV”) of the assigned staff as supporting documents to the

brief.

ii. The assigned staff must be able to communicate fluently in English and be physically present

in all meetings and workshops in Singapore during the Phase 1 of the project.

iii. Provide a brief on the company’s demonstrated experience and track record on related

projects to improve or optimise a client’s enterprise architecture.

iv. Provide two client references for feedback on services delivered for related past projects.

d) Proposed fees:

i. Provide quotations for fees using the ‘Proposal Template’ under Annex 2.

ii. Fees quoted shall be in Singapore Dollars only and exclude GST. All fees quoted shall be final.

e) Signed ‘Non-Disclosure and Security Awareness Undertaking’ under Annex 2 Part V as confidential

information may be provided by IBF during the RFP process.

f) Fully completed and signed ‘IBF IT Service Provider Checklist’ under Annex 2 Part VI.

8.2 The submitted proposal shall include the reference ‘RFP.IT.2021.0002’ and must be clearly marked as

‘Provision of IT Infrastructure Tech Refresh, Application Development and Support for IBF e-Services’.

8.3

8.4 All proposals submitted will remain confidential. IBF reserves the right not to accept late submissions.

8.5 In the event that IBF seeks clarifications on the proposal, the Vendor shall provide full and

comprehensive responses within one (1) day of notification.

8.6 IBF reserves the right to cancel or modify in any form, this RFP for any reason, without any liability to IBF.

1.1 One (1) soft copy (in PDF format) of the proposal submission shall reach IBF no later than 18 Mar

2021, 5pm. Please send the proposal submission to the following email address:

Attention: IBF Governance

Email: [email protected]

Page 11: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 11 of 83

9. BRIEFING

9.1 Companies that are interested to bid for this project will be invited to attend a briefing session. Please

email [email protected] to indicate interest no later than 25 Feb 2021, 5pm. The interested

Vendor may submit a list of questions for clarification during the briefing.

9.2 The briefing session will be held on 01 Mar 2021 at 10am via web conferencing and meeting details will

be sent upon receipt of interest. Vendors shall indicate the number of people attending the briefing,

their names, designations and contact details to receive the web conferencing invite.

9.3 Signed ‘Non-Disclosure and Security Awareness Undertaking’ under Annex 2 Part V to be duly completed

and submitted via email to [email protected] by 01 Mar 2021 5pm to receive list of current IBF

eServices inventory.

10. RIGHTS TO THE PROJECT DELIVERABLES

10.1 Materials, findings, studies and reports arising from work on the various tasks in this project are strictly

and solely the properties and rights of IBF. Reproduction, in whole or in part, of any of these materials,

findings, studies and reports by the successful Vendor, its associates, representatives or any third party

deemed to be connected to the successful bid, in any context is strictly prohibited and liable to legal

action by IBF.

11. EXPENSES

11.1 The Vendor shall bear all out-of-pocket expenses incurred.

11.2 Withholding tax or taxes of any nature, if any, shall be borne by the successful Vendor.

12. PAYMENT

12.1 IBF shall work out the payment schedule with the appointed Vendor.

13. CONFIDENTIALITY

13.1 The Vendor shall ensure the absolute confidentiality of the data and information provided by IBF or any

other organisation identified by IBF for this project and shall not, under any circumstances, release or

communicate through any means, in whole or in part, any information to any third parties. All

correspondence and communication with all external parties, pertaining to matters relating to this

project, shall be made only through IBF. The Vendor will be required to sign a ‘Non-Disclosure and

Security Awareness Undertaking’ under Annex 2 Part V.

Page 12: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 12 of 83

13.2 IBF may require an unsuccessful Vendor to return all materials that IBF provided during the period from

the issue of this RFP to the acceptance of the successful proposal.

14. SECURITY CLEARANCE

14.1 The Vendor shall subject all their personnel who will be involved in the performance of the Services to

security clearance by IBF before commencing their work. IBF reserves the right to reject any of the

Vendor’s personnel and the Vendor is responsible for finding replacements immediately and at the

Vendor's own expense.

14.2 The Vendor shall observe the secure usage and handling of all IBF’s information. All the Vendor’s

personnel shall sign an Undertaking to Safeguard Official Information to protect IBF’s information against

unauthorised disclosures by the Vendor’s personnel during the course of their work. The Vendor shall

ensure that all its personnel and subcontractors are informed that failure to comply with the undertaking

would be a criminal offence.

14.3 All the Vendor’s personnel shall fully comply with any written instructions from IBF regarding security

matters.

15. INDEMNITY AGAINST A THIRD PARTY

15.1 The Vendor shall indemnify and hold harmless IBF and its partners and employees from and against any

foreseeable loss, expense, damage or liabilities (or actions that may be asserted by any third party) that

may result from any third party, claims arising out of or in connection with the project or any use by the

Vendor of any deliverable item under this project and will reimburse IBF for all costs and expenses

(including legal fees) reasonably incurred by IBF in connection with any such action or claim.

16. ACCEPTANCE OR NON-ACCEPTANCE OF PROPOSAL

16.1 IBF shall be under no obligation to accept the lowest or any proposal received. It generally does not

correspond with any Vendor regarding the reasons for non-acceptance of a proposal.

16.2 IBF reserves the right to award the contract in parts or in full.

16.3 The issue of a Letter of Acceptance by IBF accepting the proposal or part of the proposal submitted by a

Vendor shall create a binding contract on the part of the Vendor to supply the specified deliverables in

the proposal to IBF.

Page 13: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 13 of 83

17. TERMINATION

17.1 IBF shall, after giving 7 days written notice to the Contractor, have the right to suspend or terminate this

Contract if IBF is affected by any state of war, act of god or other circumstances seriously disrupting

public safety, peace or good order of the Republic of Singapore. Neither party shall be liable to the other

by reason of such suspension nor shall termination save that IBF pay the Contractor the price of the

Goods or Services that have been performed and accepted by IBF. The Contractor shall refund the

balance of any payments or deposits made after deducting any outstanding sums owing by IBF to the

Contractor by reason of this Clause 17.

17.2 In addition to any other rights to terminate this Contract or any rights to cancel parts of the Services

under this Contract, IBF shall have the unilateral right to terminate this Contract without assigning any

reasons whatsoever by giving the Contractor 30 days’ written notice. For the avoidance of doubt, the

Contractor shall not be entitled to any compensation or damages whatsoever in relation to such a

termination. The Contractor shall only be entitled to payment for any Services provided and accepted up

to the end of the 30 day notice period.

18. DELAY IN PERFORMANCE

18.1 If there is delay in the performance of the Services or the supply of Goods due to any acts of God, force

majeure, riots and civil commotion, strikes, lock-outs or other causes or perils beyond the Contractor's

control, then in any such case the Contractor shall, for the duration of any such circumstances, be

relieved of the obligation to perform the Services or supply the Goods thereby affected. Any part of the

Services or Goods that are not so affected shall continue to be performed in accordance with this

Contract.

18.2 Subject to Sub-Clause 18.1, if the Contractor fails to complete the performance of Services or supply of

Goods by the date(s) specified in this Contract, IBF shall have the right –

a) to cancel all or any part of such Services or Goods from this Contract without compensation to the

Contractor and to obtain the same (including similar or equivalent goods and services in the case

where the exact goods and services are not available) from other sources and all increased costs

incurred shall be deducted from any moneys due or to become due to the Contractor or shall be

recoverable as damages; or

b) to deduct any moneys due or to become due to the Contractor or require the Contractor to pay a

sum calculated at the rate of 0.5% of the Contract Price for each day of delay (including Sundays and

Public Holidays), as liquidated damages until the delayed Services or Goods are fully performed or

supplied; up to a maximum amount of liquidated damages equivalent to 10% of the Contract Price.

Page 14: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 14 of 83

18.3 For the avoidance of doubt, if IBF opts to impose liquidated damage under Sub-Clause 18.2(b) and

regardless of whether the maximum amount of liquidated damages has been reached, IBF shall still be

entitled to exercise:

a) its rights under Sub-Clause 18.2(a); provided that the liquidated damages already imposed shall be

offset against any increased costs recoverable under Sub-Clause 18.2 (a); and

b) Any rights to terminate this Contract; provided that the liquidated damages already imposed shall

be offset against any increased costs recoverable under the clauses allowing for termination.

19. SUB-CONTRACTING AND ASSIGNING

19.1 The Contractor shall not sub-contract or assign the whole or any part of this Contract without the written

consent of IBF. The Contractor shall be fully responsible for all acts or omissions of any sub-contractors

or assignees and the acts or omissions of any such third parties shall be deemed to be the acts or

omissions of the Contractor.

20. GOVERNMENT REGULATIONS

20.1 The Contractor shall, at its own costs, obtain and maintain all licences, permits, authorisations or

certifications required without any restrictions or qualifications whatsoever so as to enable the

Contractor to fulfil all its obligations under the Contract.

21. NOTIFICATION OF UNSUCCESSFUL BID

21.1 Notification will not be sent to unsuccessful Vendors.

22. ENQUIRIES

22.1 All enquiries about this RFP may be addressed to:

23. Khoo Chee Huat, Manager, IT

24. Email: [email protected]

Tel: +65 6305 5607

Page 15: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 15 of 83

ANNEX 1: REQUIREMENT SPECIFICATIONS

1. GENERAL REQUIREMENTS The proposal shall consist of, but not limited to the following:

1.1. General

1.1.1 The Vendor shall take into consideration of minor adaptations which may need to be implemented

without any additional financial implications to IBF during the implementation period.

1.1.2 The Vendor shall note that the evaluation of the Proposal is based on the merit of the proposal

submissions such as the completeness on proposal submission to facilitate proper evaluation of the

Proposal. Failure to do so may result in the Proposal to be rejected.

1.1.3 The Vendor shall submit details of materials and professional services for proposal including the effort,

resources and bill of materials listing all hardware/software description, quantities, part numbers,

accessories, unit cost breakdown in Singapore dollars.

1.1.4 Vendors shall be financially strong and stable. Vendors are to share with IBF their past and existing

relevant industry track records of providing similar projects.

1.2. Project Organisation and Personnel

1.2.1 The Vendor shall provide an organization chart for the project, showing names, reporting lines and

responsibilities. The details shall also include a schedule of the key personnel indicating duties to be

performed. The organization chart shall include the project team members as specified in the

specification. A full-time project manager shall be appointed and be responsible for ensuring smooth

delivery of the project.

1.2.2 The Vendor shall submit the curriculum vitae (CV) and particulars of the project team members including

name, designation, appointment, qualification like industry certifications, relevant experience and track

records and ensure that they possess the relevant technical knowledge to carry out their role and

function. IBF reserve the rights to request for change of personnel after award if the personnel is unable

to perform the role to the required service level.

1.2.3 Vendor shall not change any project personnel without approval from IBF appointed representative.

1.2.4 In the event of resignation of any key project personnel, it shall be the responsibility of the Vendor to

provide a suitable interim replacement while sourcing for a full-time replacement.

1.2.5 All personnel will need to sign a non-disclosure agreement with IBF. By signing the agreement, the

Recipient agrees to keep secret and confidential and not to copy, reproduce, disseminate, transmit,

Page 16: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 16 of 83

distribute, publish or otherwise disclose to any third parties, whether before or after the completion of

the purpose described, any Confidential Information except in accordance with the terms of this

Agreement. The Recipient shall only be permitted to use the Confidential Information exclusively for the

Purpose. Any disclosure of the Confidential Information must be strictly limited to those employees,

agents, advisers and sub-contractors who reasonably have a need to know such Confidential Information

to enable them to carry out their duties at IBF.

1.3. Proposal

1.3.1 The Vendor shall submit the proposal documents to demonstrate the ability to perform the work as

specified and provide the necessary hardware, software, systems and professional services to meet the

required specification.

1.3.2 Propose a quality plan of IT infrastructure tech refresh on the network architecture, ensuring industry

best practices and security measures.

1.3.3 The proposed replacement hardware should meet the following requirements:

a) Ease of Deployment: Ability to deploy the proposed replacement hardware with best practice

deployment methodology to enable a fast and stable deployment

b) Flexibility and Scalability: The proposed hardware replacement shall grow with the organization

without being redesigned.

c) Resiliency and Security: The proposed hardware should provide high availability that is robust

enough to keep the network operating even under unplanned network outages and cyberattacks.

d) Easy to Manage: Reduce complexity of IT infrastructure through simplified ease of operation,

automation, real-time monitoring and notification of alerts, self-healing mechanism.

e) Future Proof: Ability to implement advanced technologies in the future without much difficulty.

1.3.4 Propose a sound implementation plan with a qualified team of personnel demonstrated being capable

to work towards meeting the target deadlines of stages, involving network installation, system

performance tests, commission, system warranty period, user acceptance tests and to coordinate the

activities well with the phases of the project and milestones.

1.4. System Implementation

1.4.1 The Vendor shall provide a weekly progress report and conduct weekly progress meeting with IBF

representative to update progress of the implementation unless otherwise stated by IBF.

1.4.2 The Vendor shall work and coordinate with the IBF appointed Suppliers and/or Contractors, including

incumbent vendor(s) in the setup of IT infrastructure.

1.4.3 The Vendor shall work with IBF on risk assessment and security assessment to comply with IBF security

requirements after the RFP is awarded.

Page 17: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 17 of 83

1.4.4 The Vendor shall warrant and guarantee all materials, equipment delivered and installed under this RFP

to be new, free from defects and that the works and all its parts shall operate and perform as stated in

tender specification till Performance Guarantee Period.

1.4.5 During implementation phase, the mounting/dismounting of new and legacy equipment, cables and the

tidy and management, documentation of cables will be the responsibility of the Vendor.

1.4.6 The Vendor shall ensure that the migration plan would seamlessly transit for all legacy to new

replacement appliances with no disruption to IBF operations and minimal impact to end users.

1.4.7 The Vendor shall ensure the data integrity with necessary security in place and adhere to IBF’s data

governance and retention policy.

1.4.8 The Vendor shall ensure all historical data and live data are migrated and 100% validated for data

integrity and propose a process for IBF users to verify with ease.

1.4.9 The propose solution shall ensure all data and models residing in the existing IBF analytics server are

migrated.

1.5. Completion Milestone

1.5.1 Once the Vendor has completed all hardware/software installation, migration, commissioning and

decommissioning and meet operational and security requirement set in the RFP, the appointed project

manager shall produce statistics, results or reports to demonstrate that the system is operational and

secured, and requirements stated in the RFP are met to the satisfaction of IBF. Any cost for rectifications,

security scans to meet requirements shall be performed by the vendor and at no additional cost to IBF.

These statistics and results are to be kept as part of the documentation and justification for project

completion sign-off before proceeding to maintenance phase.

1.5.2 The Vendor shall include, in the documentation provided to IBF, the list of all the assets including

systems, hardware, software, middleware, firmware, operating system, storage equipment, network

equipment and network attached equipment such as printers. The Vendor shall also include in the

documentation the systems and network architecture.

1.6. Performance Guarantee Period

1.6.1 The performance guarantee period shall begin three (3) months after completion milestone is reached

and accepted by IBF. The Vendor shall render replacement parts, diagnostic services,

security/performance rectification and any other works and services required to make good all defects

to the System at no additional cost to IBF.

1.6.2 The performance guarantee period shall be deemed successfully completed once the vendor has

completed all the configurations, passed all functional and security tests and documentation with

acceptance from IBF, and maintained no less than 99.95% service availability within three (3) month.

Page 18: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 18 of 83

System Availability = [Operating Hours - System Downtime] / [Operating Hours] x 100%.

1.6.3 In the event of equipment failing on any features after 3 rounds of repair, the vendor shall replace the

equipment with a new unit of equivalent or better model no additional cost. The replaced equipment

shall be subjected to similar quality, reliability and security test.

1.6.4 Any unsatisfactory performance, fault or defects in the system including all accessories and fixtures

arising from whatever cause shall be promptly rectified at no additional cost to IBF.

1.6.5 The following Service Level Agreement shall be adhered to at all times with on-site support, during and

after the performance guarantee period.

Severity

Type Description Response Time Resolution Time

Critical Defect / Problem that affect the

Application Systems such that

required operational objectives

cannot be achieved. These

include:

▪ Unauthorised access to the

data or system’s functions

▪ Defacement of System or

any malicious attacks by

hackers

▪ Security of one of more IT

systems have been

compromised

▪ Majority of users are unable

to perform business

functions

▪ Several IT systems are

concurrently unavailable

(e.g. failure of authentication

directory, failure of common

/ shared hardware

component)

24 Hours x 7 Days

Dedicated Helpdesk

Number

Unlimited calls (Including

Sundays and public

holidays)

Respond by voice or email

within 15 min upon receipt

of support service call.

Thereafter, status

reporting every 1 hour till

resolution completed

All incidents to resolve

within 4 hours to rectify

the problem or implement

workaround solution such

as Loaner unit with

Engineer resource.

For critical incident,

vendor is to

a) shut down the entire

website, disable access to

all folders and

b) put up a maintenance

page on the homepage of

IBF.

c) Resolve within 4

working hours.

High

Defect / Problem that affect a

particular form of operation but

do not affect any operational

objectives as there exists

temporary workaround solution.

24 Hours x 7 Days

Dedicated Helpdesk

Number

All incidents to resolve

within 8 hours to rectify

the problem or implement

workaround solution such

Page 19: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 19 of 83

Severity

Type Description Response Time Resolution Time

Example:

▪ Exceptional business rule/s

was/were not taken care of

in program(s), which results

in incorrect System

Application response(s)

however there exists a

temporary workaround

solution that eventually still

meets user needs

▪ Unusual slowness

experienced in one or more

public facing websites or

eServices

▪ Disruption of Business

Operations which is not time

critical

Unlimited calls (Including

Sundays and public

holidays)

Respond by voice or email

within 15 min upon receipt

of support service call.

Thereafter, status

reporting every 2 hours till

resolution completed

as Loaner unit with

Engineer resource

Medium Affects a particular process or

system for which there are

existing alternatives to bypass

the problem

Example

• Payment gateway is

down

Within 30 hours

Status reporting upon

resolution

Within 1 working day

Low Defect / Problem that have

minimum or no impact to the

business flow and Application

System usability

Within 1 hours

Status reporting upon

resolution

Within 3 working days

1.6.6 The Vendor shall render the proposed appliance fully operational within the resolution time, failing

which the Vendor shall provide a permanent or temporary replacement or loaner unit.

1.6.7 A permanent hardware replacement must be of equivalent (or better) specifications if Return Material

Authorization (“RMA”) is not possible. All labour, parts and licence of hardware and software shall be

included.

Page 20: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 20 of 83

1.7. System Commissioning

1.7.1 The Vendor shall submit the test plans for approval by IBF two (2) weeks before conducting the

Acceptance Tests. The test plans shall include comprehensive test scenarios and test cases, pass criteria

and procedures. IBF has the rights to modify the test plan when necessary.

1.7.2 The Vendor shall be responsible to create test cases for User Acceptance Test (UAT) for all system

implemented, complying to the RFP requirements. The appointed project manager shall submit to the

IBF for review and acceptance indicating expected pass/fail test responses and results.

1.7.3 All test results shall be properly documented with screenshots, where applicable, by the Vendor. If the

test results from the UAT are unsatisfactory, the Vendor shall perform rectification works and re-conduct

the UAT till acceptance. Upon successful completion of UAT, the Vendor shall obtain a UAT sign-off.

1.7.4 Once the system has successfully passed all tests results based on agreed test plan, the Vendor shall

issue a written notice to IBF representative for final system acceptance signoff.

1.8. Documentation

1.8.1 The Vendor will provide and maintain up to date documentation for all Standard Operating Procedure,

System configurations, hardware asset, software licenses and any documents within this RFP scope.

1.8.2 The Vendor shall provide and maintain a comprehensive set of user manuals and/or support guides to

IBF. The user manuals and support guides shall be subjected to the review and approval by IBF.

1.8.3 All documents submitted shall be in good, understandable and concise English. To facilitate better

understanding, diagrammatic representation such as flowchart, network diagrams etc shall be used.

1.8.4 Regular updates of the documents are necessary to keep them up to date and relevant. Version control

shall be used to keep track of the amendments.

1.8.5 The documents shall be considered accepted by IBF only when signed off by all authorized stakeholders.

1.8.6 All documents produced by the Vendor in fulfilling this Contract, shall become the property of IBF. IBF

reserves the right to reproduce, at no cost whatsoever, any documentation supplied with the proposed

System for its own use. Prior approval must be obtained from IBF for any reproduction and distribution

of documents produced by the Vendor.

1.8.7 Please refer to Annex 3 for the list of required documentations to be submitted to IBF for review by the

Vendor at a mutually agreed date between the Vendor and IBF. All documentation shall be accepted by

IBF as a criterion for System Commissioning.

Page 21: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 21 of 83

1.9. Comprehensive IT Maintenance, Warranty, Support and Maintenance Services

1.9.1 The Vendor shall provide all back-to-back maintenance, warranty and support services with respective

product principals on all the supplied hardware, software and accessories proposed in this RFP.

1.9.2 The Vendor shall ensure comprehensive coverage for Hosting, Hardware, Software, Managed Services,

Managed Security, Application Development Maintenance Support and all necessary components as

part of this RFP.

1.9.3 The Vendor shall provide all the hardware/software/accessories maintenance and license certificates

that indicate IBF as the owner of these entitlements and clearly indicate the start and end date.

1.9.4 During the comprehensive IT maintenance period, the on-site support and resolution time stated in the

Service Level Agreement shall apply and Vendor shall render the proposed appliance fully operational

within the resolution time, failing which the Vendor shall provide a permanent or temporary

replacement or loaner unit.

1.9.5 The Vendor shall provide temporary loaner unit with qualified engineer in the event of hardware failure

and migrate and restored back to last known good configuration from the faulty hardware to the

temporary loaner unit, and back to the permanent unit.

1.9.6 A permanent hardware replacement must be of equivalent (or better) specifications if Return Material

Authorization (“RMA”) is not possible. All labour, parts and licence of hardware and software shall be

included.

1.9.7 The Vendor shall provide unlimited local phone & email support for fault reporting and troubleshooting.

A ticketing system with dashboard and edit rights must be issued to identified IBF users to track all

reported issues.

1.9.8 The Vendor shall arrange to conduct Preventive Maintenance (including but not limited to inspection,

testing and satisfactory execution of all diagnostics) by OEM once every six (6) months on a day and time

to be mutually agreed upon. Notwithstanding the foregoing the Vendor recognizes IBF’s operational

needs and agrees that IBF shall have the right to require the Vendor to adjourn any scheduled preventive

maintenance.

1.9.9 IBF reserves the right to:

a) Shift supplied systems to an alternative site of its choice.

b) Expand the capacity/enhance the features/upgrade the system supplied, either from the vendor

or other IBF appointed vendor(s).

Provided such changes do not prevent proper maintenance, from being perform or unreasonably

increase the Vendor cost of performing maintenance services.

Page 22: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 22 of 83

The warranty terms would not be considered as violated if any of (a) or (b) above takes place. Should

there be a fault in the operations of the system, the vendor, would not unreasonably assume that the

causes lie with those components/software not acquired from them.

1.9.10 IBF has the option to renew the maintenance contract annually.

1.10. Asset Disposal

1.10.1 The Vendor shall be responsible for the disposal of the old decommissioned IT hardware including asset

consolidation, verification, proper inventory, destruction and disposal. Certificate(s) of disposal will be

issued to IBF for record purpose.

1.10.2 All Data stored in the decommissioned IT hardware that cannot be securely wiped shall be physically

destroyed before disposal. The disposal is to be done in a secure manner and with a certificate of

destruction and disposal inventory for audit purposes.

1.10.3 Destruction equipment shall be maintained in good working condition and meet the following standards:

a) Magnetic storage media (e.g. hard disks) that are faulty and cannot be overwritten: Degauss

using NSA evaluated degaussers which have been evaluated to be capable of erasing both

longitudinal and perpendicular magnetic disk storage devices with coercivity of up to 5000

Oersteds. The degaussed storage media shall subsequently be completely shredded by a built-for-

purpose HDD shredder or incinerated at a commercial incinerator.

b) Magnetic storage media (e.g. hard disks), functional: Degaussing as per above, or DoD 5220.22-

M secure overwriting.

c) Non-magnetic storage media (e.g. optical media such as CDs and DVDs, or solid-state media such

as memory cards and thumbdrives): Physical destruction into particles that have nominal edge

dimensions of 5 mm and surface area not larger than 25 sq mm.

1.10.4 The Vendor shall work with IBF representative and comply with the asset disposal process and

procedures with document sign-off.

1.11. Computer or End-Points

1.11.1 The Vendor shall take note of the following security best practices when handling IBF Information. The

appointed personnel should only work on company issued computers installed with appropriate security

controls. Such technical computer security controls may include but are not limited to:

a) Full device encryption

b) 2-factor pre-boot authentication

c) Access control mechanisms

d) Account lockout upon a maximum number of unsuccessful login attempts

e) Memory-resident malware detection software with updated malware database

f) Firewall software with updated firewall rules and policies

Page 23: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 23 of 83

g) Host Intrusion Protection and Host Integrity Checks with updated policies

h) Updated and patched operating system and authorised applications

i) Disabling all guest accounts and other unnecessary user-accounts

j) Disabling USB ports, Ethernet, wireless (Wi-Fi), Bluetooth, Infra-red, FireWire ports, floppy drives,

DVD drives and other connection ports if not required

k) Disabling auto-run

l) Screensaver “time-out” requiring user re-authentication

m) Setting boot sequence to internal (primary) storage only (i.e. preventing boot from

external/removable storage media and network); and

n) Not using unauthorised software, storage media, network equipment and peripherals

o) No production data at all times

1.12. Audit Requirements

1.12.1 The audit trails for all interactions in the System including unauthorized access of data or systems’

functions, administrator/super user account activities, staff’s activities shall be logged by the systems.

The audit trails information shall cover minimally the following:

a) User account information

b) Type and duration of interactions

c) Date and time of all interactions

d) Information that is amended including updates to configurable parameters

e) The IP address of the computer used to access various Systems

1.12.2 The Vendor shall ensure that the audit trail is not amended by anyone and shall provide details on the

fulfilment of this requirement

1.12.3 The system shall allow generation of account administration reports that include minimally, the following:

a) All user accounts

b) Changes in access rights

c) Status of user accounts (i.e. inactive, active, terminated)

d) List of users with designated access privileges

1.12.4 The Vendor shall keep all audit trails and reports for a minimum period of three (3) years. The Vendor

shall cater sufficient storage to store the audit trails and reports.

1.12.5 The Vendor shall work with IBF to identify the audit trails and reports to be provided on a real-time basis

to IBF’s Security Information and Event Management (SIEM) solution. The Vendor shall also provide the

relevant audit trails and reports to IBF as and when requested.

1.13. System Requirements

Performance

Page 24: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 24 of 83

1.13.1 The maximum response time of the system to navigate from one screen to another after user had clicked

on the button or other input device shall not exceed five (5) seconds 95% of the time. This requirement

shall be tested during the User Acceptance Test with IBF provided network.

Availability

1.13.2 The System shall be available on a twenty-four (24) hours per day, seven (7) days per week, three

hundred and sixty five (365) days per year basis ( 24 x 7 x 365) except for scheduled routine system

maintenance or downtime in which IBF is to be notified at least one (1) week in advance to inform users.

Reliability

1.13.3 The System shall be able to recover all data stored up to the last successfully completed transaction

before a failure occurs without manual intervention by the users

1.13.4 Failure of any single transaction shall not affect the integrity of the existing data and the failed

transaction shall not be captured in the database.

1.13.5 The System shall be designed to prevent a single point of failure in bringing down the whole System.

1.13.6 The Vendor shall propose an automated performance monitoring tool to ensure that the System meets

the SLAs and to proactively identify problem areas and take corrective actions before services are

affected.

1.13.7 The proposed tool shall alert the duty or assigned Facilities Management engineer/ System

Administrator at the external Data Centre when the System reaches 70% minimum and 85% maximum

threshold of breaching capacity thresholds such as CPU, database disk space, RAM etc. and any service

unavailability. Vendor shall ensure the alerts are sent to IBF appointed personnel and maintain the list

of IBF personnel in the alert list.

1.13.8 The System shall be load tested with the proposed tool periodically to ensure minimally the following.

a) Optimal performance to meet the Service Level Agreements (SLAs)

b) Scalability (i.e. large increase in the number of concurrent users during peak period in the PROD

environment)

c) 24X7 availability

1.14. Configuration Management

1.14.1 All changes to the configurations of the proposed platform shall be tracked and documented for easy

reference and audit purposes.

1.14.2 The Vendor shall ensure that all the critical functions such as creating master system passwords and

cryptographic keys are jointly implemented by more than one authorised staff.

Page 25: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 25 of 83

1.14.3 The Vendor shall ensure that no single authorised staff knows the whole encryption keys are or have

access to all the components making up these keys. All cryptographic keys which include master keys,

key encrypting keys or data encryption keys shall be created, stored, distributed or changed using

industry best practices.

1.14.4 The Vendor shall be responsible to implement contingency plans and fall back procedures to roll back

the changes should there be any occurrence of errors or issues.

1.15. Future Growth

1.15.1 The System shall cater to current user base, data storage and performance with a projection of 10%

increase annually.

1.16. Housekeeping, Archival and Restoration

1.16.1 The Vendor shall propose a Housekeeping, Archival and Restoration Plan for data, source codes, audit

logs etc.

1.17. System Operation

1.17.1 The Vendor shall be responsible to work with all relevant stakeholders such as IBF users, Facility

Management (FM) staff at external Data Centre etc to ensure a successful roll-out of the project for all

phases, as well as during the maintenance phase.

1.17.2 The System shall be able to notify the designated technical team when there are failures in the batch

jobs through communication media, minimally via emails.

1.17.3 The operating hours of the System shall be configurable by IBF. In the event of scheduled

maintenance resulting in the System being not accessible by the users, IBF shall be able to put up

appropriate message to inform the users.

1.18. Release Management

1.18.1 The Vendor shall conduct system integration testing (SIT), unit testing, quality assurance with sign-off

before the conduct of UAT in the UAT environment with the end users. Upon acceptance, it shall be

deployed to pre-production environment with regression testing conducted, deployment packaged

validated by minimally a Team Leader before deployment to the PROD environment for ALL deployments

including bug fixes, enhancements, patches, etc.

1.18.2 The Vendor shall provide detailed deployment plans for IBF’s review and approval before deployment of

source codes to UAT, Pre-Production and PROD environments.

1.18.3 The Vendor shall provide a status update of each deployment to IBF and end users.

Page 26: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 26 of 83

1.19. Data Governance

1.19.1 IBF has full ownership of all data in the System. All data disclosure to third parties, retention and disposal

by Vendor shall be subjected to IBF’s approval.

1.19.2 The Vendor shall ensure that the data is protected against loss, corruption, unauthorised access, use,

amendments etc. and only authorised staff has access to the data in UAT, Pre-PROD and PROD

environments. All data migration must be tested fully before seeking approval by IBF.

1.19.3 The Vendor shall ensure that all staff signed the Confidentiality and Non-Disclosure Agreement (CNDA)

not to access, use, share, divulge or retain data unless this is required in discharging their duties during

their employment. The CNDA is binding even if the staff has resigned or is transferred to another project

team or after the termination or expiry of the Contract. Non-compliance could result in legal action being

taken against the Vendor by IBF.

1.20. Application Maintenance and Support Services

1.20.1 Application maintenance and support services shall commence after the expiry System Warranty.

1.20.2 IBF has the option to renew the maintenance contract annually.

1.20.3 IBF may raise IT Service Requests (ITSR) or Change Requests for the appointed Vendor to enhance or

modify the System during the application maintenance and support period. The number of man-days

and the duration of this option is to be mutually agreed between IBF and the appointed Vendor.

1.21. IT Support

1.21.1 The Vendor shall propose IT Support structure that address all 1st Level, 2nd Level, 3rd Level and 4th

Level support.

1.21.2 The Vendor shall ensure any incidents, issues, requests from IBF will be logged in a ticketing system with

email acknowledgement send to the reporting user. IBF shall have access to the ticketing system to re-

assign user/engineer, update severity/status/due dates and all necessary information.

1.21.3 The support hours for the System are from Singapore Time 8.00 am to 6.00 pm from Mondays to Fridays

(excluding public holidays in Singapore)

1.21.4 The Vendor shall ensure the tickets are updated in a timely manner as IBF user responses may be via

different mediums (email, phone call, text messages etc).

1.21.5 The Vendor shall ensure the appointed Project Manager or respective Team Lead manages the ticketing

system and issues are tagged with the correct severity, or otherwise instructed by IBF.

1.21.6 The ticketing system must be available at all times and necessary backup to be performed. All data and

information residing in the ticketing system pertaining to this project are properties of IBF and IBF

Page 27: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 27 of 83

reserves the right to request for the data during the project period and upon termination or suspension

of this contract.

1.21.7 All data in the ticketing system shall be deemed confidential as exchanges of information and screen

capture will be logged in the system.

1.21.8 The Vendor is responsible for first level functional and technical support for all defects and issues

encountered in the use of the System and to log all issues reported. The Vendor shall ensure issuance of

ticket to the user with a reference number for easy tracking.

1.21.9 The Vendor shall proactively monitor the status of all issues logged by the users. There shall be regular

updates to the users on the status until closure.

1.22. System Delivery and Acceptance

Testing of System before delivery

1.22.1 The Vendor shall conduct system integration testing (SIT), unit testing, quality assurance with sign-off

before the conduct of User Acceptance Testing (UAT) in the UAT environment with the end users at the

end of development, which includes bugfixes, service requests, Change Requests, data patches, security

patches etc.

1.22.2 The Vendor is responsible and shall possess capability to set up off-site development and unit testing

environments at its own preferred location, with all the necessary licenced tools at no cost to IBF.

1.22.3 The Vendor shall have process in place to conduct UAT smoothly in a timely manner. UAT test cases, test

plans and test environment must be ready and briefed to IBF users to ensure success of the UAT.

1.22.4 The Vendor shall allow the testers to test off-site and track all issues or bugs reported during the testing

using an online tracking tool. The Vendor shall rectify all issues or bugs promptly and report the status

to IBF regularly.

Acceptance by IBF

1.22.5 The System Deliverables is deemed accepted by IBF only when it has been approved by IBF as having

met the requirements of IBF’s stakeholders with no defects or bugs.

1.23. Exit Management

1.23.1 This shall be applicable in the event that the System is to be handed over to a new Vendor for

maintenance or termination of the Contract.

1.23.2 The Vendor shall propose and submit an Exit Plan within one (1) week from the date of being notified of

contract termination or two (2) calendar months before the expiry of the Contract; unless an alternative

date is mutually agreed between the IBF and the Vendor. The Exit Plan and the detailed schedule shall

be subjected to the IBF’s approval.

Page 28: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 28 of 83

1.23.3 The Exit Plan shall include but not be limited to the following:

a) Processes and procedures (for example, operational, security, business functions etc.)

b) Roles and responsibilities

c) definition of major milestones

d) Schedule for completing / hand-over of outstanding tasks

e) Contact list of Vendors providing 2nd level escalation support

f) All documentations related to this project

g) Cost implication of handling any proprietary Contractor’s tools with respect to licensing

h) Conduct briefing to the new Vendor

i) Allow shadowing by the new Vendor (for example, the new Vendor will be on-site to

observe how the Vendor execute specific tasks, reviewing of systems logs)

1.23.4 The exit transition period shall be managed and supervised by IBF.

1.23.5 The Vendor shall complete all outstanding tasks and activities required of the Vendor, including

rectification of all unresolved PROD or UAT issues. For outstanding tasks that may extend beyond the

Contract Period, IBF shall decide if such tasks should be handed over to the new Vendor.

1.23.6 The Vendor shall complete defect management and corrective maintenance for all defects discovered

during the Contract Period before handing over to the new Vendor.

1.23.7 The Vendor shall also perform an end-of-contract baseline update, which shall contain all the changes

to the System that have been made during the Contract Period. The Vendor shall in accordance with the

requirements of configuration management ensure completeness and proper configuration

management of this baseline and submit it to IBF for auditing and acceptance.

1.23.8 The Vendor shall be responsible to conduct a detailed hand-over, inclusive of briefing and training

sessions, of the complete system to IBF or/and the new Vendor. The hand-over shall be conducted

concurrently with the ongoing support required of the Vendor without affecting the Service Levels. Any

cost incurred during the period of hand-over will be borne by the Vendor.

1.23.9 The Vendor shall ensure on a best effort basis that the new Vendor is able to take-over the System with

minimal disruption to support and operations of IBF.

1.23.10 The Vendor shall provide updates to existing documentation. This documentation shall be subjected to

approval by IBF.

Page 29: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 29 of 83

1.23.11 The Vendor shall hand-over all necessary documentation of the database, application software and

records of problem resolution required for the effective maintenance of the System.

1.23.12 The Vendor shall ensure that all expected deliverables and documentation are properly handed over to

IBF.

1.23.13 In the last two (2) calendar months of the System Warranty Period or the Maintenance Contract, the

Vendor shall oversee the new Vendor and personnel designated by IBF in performing the daily operations

of the System.

1.24. Training

1.24.1 The Vendor shall provide at least two (2) hands-on training of the System to IBF’s internal users and all

stakeholders.

1.25. Project Management

1.25.1 Project Office

a) If the Vendor does not already have a Project Office in Singapore, the Vendor shall, if required to do so under the Requirement Specifications or otherwise in writing by IBF, establish a Project Office in Singapore at its own expense. The Project Office is to coordinate the performance of this RFP and serve as the common service location for IBF to contact for the provision of all the Goods or Services.

b) If required under the Requirement Specifications or otherwise agreed in writing by IBF, more than one Project Office shall be set up.

1.25.2 Project Manager

a) The Vendor shall designate a Project Manager and the Project Manager shall be primarily responsible for directing and coordinating all the Vendor’s obligations under this RFP. The Project Manager shall be deemed to be the Vendor’s agent in all dealings with IBF and all actions of the Project Manager shall be binding on the Vendor.

b) IBF Representative(s) shall have direct access to the Project Manager at all times during the performance of this RFP and if the Project Manager is absent from Singapore for any duration, the Vendor shall designate another employee or team member with relevant experience to perform his duties and functions.

c) If required under the Requirement Specifications or otherwise agreed in writing by IBF, more than one Project Manager shall be designated.

1.25.3 Implementation Plan

Page 30: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 30 of 83

Unless otherwise agreed by IBF in writing:

a) within 7 days from the date of the Letter of Acceptance and/or Purchase Order, the Vendor shall produce a Final Implementation Plan showing the time schedule and sequence of events necessary for the provision of the Goods or Services.

b) The Final Implementation Plan shall be not be acceptable unless it meets the timelines and/or stipulated completion dates set out in the Requirement Specifications (and the Purchase Order concerned).

1.25.4 Progress Reports & Meetings

a) to the Vendor shall provide monthly written reports on progress and status of completion of

the Services and delivery of the Goods in a format approved in writing by the IBF Representative(s). The IBF Representative(s) may, at IBF Representative’s sole discretion, request for such reports in monthly, fortnightly or weekly intervals; and may change the intervals from time to time. The submission and receipt of these reports shall not in any way prejudice the rights of IBF to make any claims against the Vendor if the terms of this RFP are not met.

b) The Vendor shall ensure the regular reports includes minimally the following: i. any incidents encountered (this is a summary and is separate from the actual incident

reports); ii. service tickets raised;

iii. service level iv. operations monitoring (e.g. the network utilisation monitoring, storage utilisation

monitoring); v. security issues encountered;

vi. new and/or updates to risks and/or risk mitigating measures.

c) The Vendor shall propose the format and information to be included in the regular reports for IBF Representative(s) acceptance.

d) IBF Representative(s) shall have the right to call for progress meetings from time to time and/or on regular weekly or other intervals as determined by IBF Representative(s). During such meetings, the Project Manager shall attend and report to IBF Representative(s) on the completion of the Services and delivery of the Goods. The progress meetings shall be held at venues chosen by IBF Representative(s).

e) The Vendor shall notify IBF Representative(s) of any expected delay in the performance of this RFP. The Consultant shall refer immediately to IBF Representative(s) any matter likely to impede the provision of the Goods or Services; provided that such notices shall not excuse the Contractor from meeting its obligations under this RFP.

Page 31: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 31 of 83

2. REQUIREMENT SPECIFICATION

The proposal shall consist of solution equivalent or better from the current IBF Portal & eServices

hosting, infrastructure, architecture, application, security and performance. It shall consist of, but not

limited to the following:

2.1. Next Generation Firewalls

2.1.1 The Vendor shall propose Internet line of at least 100mbps.

2.1.2 The Vendor shall propose, supply, deliver, implement, test, commission and migrate existing Firewalls to

new replacement for Tier1 and Tier 2 firewalls with Management Centre to centrally manage all Next-

Generation Firewall appliances.

2.1.3 The proposed Tier-1 Next-Generation Firewall replacement shall be configured with equivalent or better

settings to protect Internal network from External Sites and Internet with the following requirement:

a) IPS will be turned on to prevent internal network devices from being compromised.

b) App Control will be turned on to allowed approved traffic to Internet or External Sites

c) URL Filtering will be turned on to prevent internal devices from connecting to malicious or

unauthorized websites.

2.1.4 The proposed Tier-2 Next-Generation Firewall replacement shall be configured with equivalent or better

settings to segment LAN and Application Subnet based on Trust Level with the following requirement

a) IPS will be turned on to prevent App/DB servers from being compromised

b) Lower Trust Subnet should not have access to Higher Trust Subnet. E.g. LAN subnet should not

have access to DB subnet.

c) Client will need to access the Web Server and Web Server will initiate connections to App Server.

App Server will then access the DB server to get relevant information to be presented to the Web

Server.

2.1.5 The proposed solution shall include and not limited to the following:

a) Firewall Throughput

b) Threat Prevention

c) Concurrent Session

d) New Session per Second

e) IPSec with VPN Throughput

f) Interface (1G)

g) Interface (1G fiber)

h) Interface (10G fiber)

i) Power Supply

Page 32: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 32 of 83

2.1.6 The Vendor shall ensure all existing firewall rules and configurations are reviewed and approved by IBF

Representative(s), followed by migration to the new appliances, tested and accepted by IBF

2.1.7 Untrusted network should not have access to internal network. If it is required, strict Firewall Rules

control and security scanning shall be enforced.

2.1.8 Web Application Firewall shall be in place.

2.1.9 The proposed solution shall be applied with public CA certification and firewall logs to be retained in the

appliance for a minimum of six (6) months.

2.1.10 The proposed Next-Generation Firewall appliance shall be of better performance with security features

such as Threat Prevention, Unified Threat Management, SSL/SSH decryption etc, and support IPS

features on the proposed Enterprises Security Platforms appliance and antivirus and anti-spyware.

2.1.11 The proposed Enterprises Security Platforms must allow policy rule creation for application

identification, user identification, threat prevention, Uniform Resource Locator (URL) filtering, traffic

management Quality of Service (QoS) per policy and scheduling in a single unified rule and not in multiple

data-entry locations in the management console.

2.1.12 The proposed Enterprises Security Platforms shall have the hardened Operating System (OS) and built as

a firewall appliance (i.e. not on generic server hardware) and shall handle traffic in a single pass stream-

based manner with all features turned on. It shall be optimized for layer 7 application level content

processing and have special Application-Specific Integrated Circuit (ASIC) to handle signature matching

and processing in a single pass parallel processing architecture.

2.1.13 The Management Plane (handling Admin Consoles, Reporting, etc.) and the Data Processing Plane

(handling Firewall Policies, IPS, Anti-Virus, Anti-Spyware Scanning, etc.) shall be separated such that

when the Management Plane were to hang, it could be separately restarted without disrupting the on-

going traffic data processing functions. The proposed Enterprises Security Platforms shall be

administered locally on the appliance without additional management or logging software.

2.1.14 The proposed Enterprises Security Platforms must be in the Leaders Quadrant in the latest Gartner Magic

Quadrant for Enterprise Network Firewalls.

2.1.15 The proposed Enterprises Security Platforms shall support policy-based Network Address Translation

(NAT) and Port Address Translation (PAT) and able to operate in routing/NAT mode.

2.1.16 The proposed Enterprises Security Platforms overall solution shall be available in High Availability

Configuration. The proposed Enterprises Security Platforms solution shall support active/active and

active/passive HA configuration, capable of detecting link and path failure in addition to device failure,

support encryption of HA heartbeat and control traffic.

Page 33: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 33 of 83

2.1.17 All the Firewall, IPS, Anti-Virus, Anti-Spyware, URL Filtering, Data Filtering logs must be automatically

correlated. All these types of logs shall contain User ID and Application information pertaining to the

corresponding events. The Vendor will be required to with IBF appointed Security (SIEM/SOC) vendor

for log forwarding.

2.1.18 The proposed solution shall support the protection against Advanced Persistent Threats (APT) and shall

not further degrade Threat Prevention Throughput of the Next Generation Security Platform when the

APT prevention feature is turn on.

2.1.19 When any false positive malware, DNS or URL are detected, the proposed Enterprises Security Platforms

are able to provide the option of the ability to create whitelist or blacklist and update to the appliances.

2.1.20 The proposed solution shall have the ability to provide a comprehensive APT analysis report.

2.1.21 The proposed Enterprises Security Platforms shall have SSL/SSH Decryption be able to:

a) identify, decrypt and evaluate SSL & SSH traffic in an outbound and inbound connection, block SSL

sessions with expired/untrusted server certs to prevent users from unknowingly connecting to a

vulnerable site.

b) restrict certificate extensions to limit the purposes for which the generated certificate will be used

to prevent users from unknowingly connecting to a vulnerable site.

c) identify, decrypt, evaluate SSH traffic in an outbound and inbound connection and deny SSH

tunneling to prevent any unauthorized tunnel traffic, block SSL and SSH sessions for unsupported

modes (version, cipher suites). The decryption of SSL traffic should not be limited to default port

TCP 443 only.

2.2. Hosting Server Rack and Core Switches

2.2.1 The Vendor shall propose Hosting Rack (full server rack 45Ux600x1200, equivalent or better) and

solution with core Switches that supports hyperconverged with at least 25Gbps connectivity.

2.2.2 The Vendor shall configure the Core switch, Distribution switch and Access/Management switch to

support high availability with redundancy, and redundant power supplies and fans.

2.2.3 The proposed Core switch shall have sufficient switching capacity to ensure optimal performance.

2.2.4 The proposed Core switch shall come with 48 x 25Gbe ports, distribution switch (25g) and

Access/Management switch (24ports RJ45 with 10g module uplink).

2.2.5 The proposed transceiver module (short range), fibre cable should be OM4.

Page 34: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 34 of 83

2.2.6 The Vendor shall study, advise and re-configure the existing network to a three Tier architecture (or

appropriate architecture as proposed to and approved by IBF), Core, Distribution and Access/Mgmt. All

existing access switches shall be terminated on newly proposed distribution switches.

2.2.7 The proposed to a have monitoring system to analyse events that impacts network health.

2.3. Servers

2.3.1 The proposed solution shall be based on a hyperconverged solution where the infrastructure system

consists of software-centric architecture that tightly integrates compute, storage and network resources.

2.3.2 The propose solution shall:

a) support hypervisor technologies, VMware to enable full flexibility for IBF to run applications in the

best performing and most cost-efficient way, and provide minimally N+1 resilience such that in

the event of a node (server) failure, or maintenance downtime, there will be no loss of

performance and no data loss.

b) allow data to follow virtual machines from ANY host to ANY other host in the cluster as they are

migrated. This ensures we have full flexibility and freedom to migrate VMs anywhere we see fit

without taking on the risk of increasing read latency or network activity over time.

c) have each VM’s most frequently accessed data must reside on the same node as said VM on an

ongoing basis (regardless of where it is moved to) to ensure maximum performance

d) leverage ALL nodes within the cluster when rebuilding data subsequent to a disk failure – this is to

ensure fast-as-possible rebuild times regardless of disk size as well as mitigating the performance

impact of the rebuild process

e) leverage only commodity hardware components (there must be no proprietary hardware in the

proposed solution)

f) ensure flexible solution customization, various node types / models must be available (including

storage only nodes, flash only nodes) and it must be possible to choose different CPU and memory

configurations, and the ability to mix node types/models within a single cluster such that VMs can

be live migrated between different models

g) able to demonstrate user initiated non-disruptive upgrades for controller software, hypervisor and

firmware without the requirement for ANY external manufacturer provided support

h) be able to scale out or scale up without any limitations

i) ensure efficient use of storage, must support data deduplication, compression and erasure coding

on per data store basis

j) allow monitoring of platform resource usage and cluster health with proactive flagging of issues

and assisted root cause analysis

k) allow viewing of performance metrics across the full logical stack within a single pane-of-glass.

Within this single view it should be possible to simultaneously view data at the cluster, VM, host,

datastore and individual disk levels

Page 35: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 35 of 83

l) provide automatically generated capacity planning estimates using trending analytics applied to

actual system data. This capability can be delivered either natively or through a 3rd party product.

All costs relating to this functionality MUST be included in the proposal submission

m) hypercoverged should connect to core switch

2.4. Hosting, Back-up, Disaster Recovery and Business Continuity

2.4.1 The Vendor shall provide hosting located in Singapore only, within a reputable Tier 3 or Tier 4 data center

and shall ensure the proposed solution support for high availability with redundancy. The data center

shall also have robust physical access controls to ensure that unauthorised personnel cannot access IBF

systems and assets at the data center. All physical access shall be logged and record to be kept for at

least one (1) year and provided to IBF upon request.

2.4.2 All services shall be hosted on IBF dedicated servers and not on public cloud.

2.4.3 The propose solution shall have in place and support IBF’s business continuity plan (“BCP”) to manage

operational disruptions. The Vendor shall be responsible and be involved in all BCP activities.

2.4.4 The DR hosting location propose shall not be within or in proximity as the primary hosting Data Center.

2.4.5 The Vendor shall ensure the proposed IT systems, data backup and recovery procedures are sufficiently

robust. Where a system failure results in a probable loss or damage of the IT systems or data, the

Vendor shall be responsible for the recovery of the IT systems, as well as the recovery of any lost data,

the restoration and repair of any damaged data and the correction of any erroneous data to the extent

possible, within fourteen (14) working days from the date on which the system failure occurs.

2.4.6 The proposed solution shall adhere to 3-2-1 backup rule.

2.4.7 The proposed solution shall have Recovery Point Objective (RPO) of not more than 1 hour, and

Recovery Time Objective (RTO) of not more than 24hours, and the DR site should have optimal

performance and speed to minimise operational impact to users. IBF reserves the right to make

changes to the RTO/RPO.

2.4.8 All hosting and off-site backup shall adhere to IBF security requirements and the Vendor shall ensure

the data resides in Singapore only.

2.4.9 The Vendor shall provide relevant and adequate support when IBF conducts business continuity and/or

disaster recovery tests, up to a maximum of three (3) tests per year. IBF may conduct these tests

according to its internal schedule and may not inform the vendor prior to the tests.

2.5. APIs, Connectivity and Schedule Jobs

Page 36: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 36 of 83

2.5.1 The Vendor shall ensure all APIs, interfaces and connectivity to other services (e.g. payment gateway,

exams systems, exams online, CRM, H2H etc.) are migrated, validated and accepted by IBF users.

2.5.2 The Vendor shall ensure all schedule jobs are migrated and functioning as expected.

2.6. Security

2.6.1 The Vendor shall propose a Security Management Plan to address personnel security, system security,

access security, security incident management etc.

2.6.2 All access to the system shall be made via IBF appointed Privilege Access Management (PAM) system.

The Vendor shall ensure integration with IBF PAM during the implementation phase.

2.6.3 Transport Layer Security (TLS) version 1.2 or later shall be implemented for secure transmission of all

data online.

2.6.4 All Data transmissions such as data-in-transit, data-at-rest shall be encrypted.

2.6.5 All transfer of data through scheduled batch jobs shall utilise secure protocols such as Secure File

Transfer Protocol (SFTP) and encrypted during transmission

2.6.6 All network traffic shall be routed through a designated and correctly configured firewall before exiting

or allowing access to the network or subnet

2.6.7 The System shall be protected against all known security vulnerabilities inclusive of OWASP (Open Web

Application Security Project) Top 10 web application security risks

2.6.8 The Vendor shall submit the following reports at no cost to IBF:

a) Vulnerability assessments conducted for System including review of source codes and third party’s

packages.

b) Security penetration testing either by third party Contractor appointed by IBF or by the appointed

Contractor (CREST Certified, equivalent or better) to identify all security gaps; and

c) Rectification of all identified security gaps.

2.6.9 The Vendor is responsible to ensure that there is no unauthorized installation of software on all servers.

Approval from IBF shall be sought for installation of new software.

2.6.10 Directory browsing on all servers shall not be allowed to prevent server setup information being

divulged.

Page 37: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 37 of 83

2.6.11 All items including third party libraries, source codes, software updates or patches etc. provided or

installed must be scanned against virus. In the event that this due diligent was not performed, the Vendor

shall recover all lost or corrupted data, removing virus from all infected items as a result of this virus

infection at no costs to IBF.

2.6.12 The Vendor shall ensure that the System is protected against any threats, attacks or virus attacks by

having proactive security in place such as Intrusion Prevention System, Virus scanner, Malware Scanner

etc and ensure there is a patch management in place to prompt installation of security and software

patches.

2.6.13 Vendor shall be responsible for the overall security posture of the System and ensure there is proactive

security measures in place and perform the full investigation and remediation in the event of potential

security breaches. For avoidance of doubt, security breaches encompass all aspects including and not

limited to virus, malware, trojan, data loss, internal/external threats etc.

2.6.14 The Vendor shall work with IBF appointed SIEM vendor for logs sending/transfer.

2.6.15 The Vendor shall ensure that all information pertaining to IBF’s environment shall not be divulged to any

party without authorization from IBF. The vendor shall take all necessary security measures to ensure

the integrity, confidentially, availability and traceability of data. All security related incidents shall be

reported to IBF on the same working day.

2.6.16 The Vendor shall support IBF fully on annual audit and any audit requirements as informed by IBF.

2.6.17 The Vendor shall provide the latest industry/professional certification (e.g. ISO 27001, ISO22301, OSPAR,

SOC2 etc) upon submission of the proposal and upon request by IBF and IBF appointment auditors in a

timely manner.

2.6.18 The Vendor shall submit the necessary recognized assurance reports (e.g. SOC2 reports, ISO27001) upon

request by IBF or IBF appointed auditors in a timely manner.

2.6.19 The Vendor shall ensure compliance in terms of patches and upgrades, VAPT and other compliances as

decided by IBF.

2.6.20 The Vendor shall provide expert advice on evaluation, selection, and implementation of security

features, administrative procedures and appropriate controls as per IBF security policies.

2.6.21 The Vendor shall propose and maintain industry-standard hardening template (such as CIS Benchmark)

to IBF and ensure the proposed solutions (i.e. Operating System, Servers, appliances etc) and any

future additions are hardened in accordance with template.

Page 38: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 38 of 83

2.7. Public Domain Name System Hosting Service

2.7.1 The Vendor shall propose a Public DNS Hosting Service that is equivalent or better than current, with

ability to allow IBF to administer the Public DNS record.

2.7.2 The Vendor shall migrate all existing Public DNS records and configurations.

2.8. Operating Systems, Software Licences, Security Certificates

2.8.1 The Vendor shall evaluate the existing system architecture and application architecture, and propose

up-to-date (including and not limited to) Operating Systems (Windows), hypervisor licences (VMware),

software licences, security certificates (SSL Certs etc), drivers and plugins etc to ensure the smooth

operation of IBF eServices.

2.8.2 The Vendor shall propose the latest version and patches for the following, equivalent or better:

a) Microsoft Windows Server 2019 Datacenter

b) VMware version 7.0

c) SQL Server 2019 v15.x

d) and any other required system, firmware etc.

2.8.3 The Vendor shall ensure the proposed solution and resources caters for elasticity and future growth such

as on-demand creation and removal of servers, creation of sandboxes etc.

2.8.4 The proposed solution shall ensure High Availability and supports Disaster Recovery and Business

Continuity Planning and annual BCP exercise at no additional cost to IBF

2.8.5 The Vendor shall ensure all components are licenced and secure to use. No free version is to be used.

2.8.6 The Vendor shall ensure the proposed Operating Systems and Hypervisor licences are catered for future

growth.

2.8.7 All licences procured for use in fulfilling this Contract, shall be owned by IBF.

2.9. Application Development

2.9.1 The Vendor shall propose a scalable development approach with modern and future-ready platform and

CI/CD/CT (Continuous Integration/Continuous Development/Continuous Testing) implementation

approach.

Page 39: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 39 of 83

2.9.2 The Vendor shall ensure the existing application, integration and connectivity are migrated, tested in the

proposed platform.

2.9.3 The Vendor shall manage and maintain the development approach and platform in supervision of IBF

Representative.

2.9.4 The Vendor shall provide onsite resources to provide consultation, assistance and training to various IBF

departments in adopting of the development approach and ensure business units understand and are

aligned with the new proposed approach to achieve optimal outcome.

2.9.5 The Vendor shall provide enablement sessions, training contents and associate tools and keep it updated

timely as part of knowledge repository to enable self-learning within IBF.

2.9.6 The proposed platform shall support or consist minimally:

a) Development of applications using modern methodology such as Agile (equivalent or better).

b) Deployment on proposed hardware and architecture and scalable to support future-ready

architecture (e.g. containers)

c) Application architectures with micro services

d) Development using multiple technologies, but not limited to .Net, Java, Python etc.

e) Automate the release and delivery of applications, change requests, enhancements, bug-fixes and

shorten the delivery lifecycle, streamlining manual processes and accelerate digital initiatives with

security, quality and reliability in place.

f) automate unit testing, functional testing and non-functional testing (e.g. performance test,

security test)

g) common comprehensive reporting dashboard as part of “continuous measurement” to enable IBF

to monitor the quality and speed of implementation.

h) Work with IBF appointed vendors and integrate with IBF’s platform like DDOS, WAF, SOC/SIEM,

PAM etc to meet security and compliance requirements as and when required.

i) Setup approval-based automation for code deployment as per the process/workflow defined by

IBF.

2.9.7 The Vendor shall ensure backup, recovery and disaster recovery/business continuity of the platform as

decided by IBF, and ensure the platform is safe from any security vulnerabilities and adherence to any

compliance as decided by IBF.

2.9.8 Continuously look-out for any new tools with new or upgraded features.

2.10. Framework and Standards

2.10.1 The vendor shall follow the ISO 27001 requirement as IBF accepted framework standards as following:

Page 40: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 40 of 83

A14 System acquisition, development and maintenance

A14.1 Security requirements of information systems

A14.1.1

Information security requirements analysis and specification

The information security-related requirements should be included in the requirements for new information systems or enhancements to existing information systems. Identification and management of information security requirements and associated processes should be integrated into the early stages of information systems projects. Purchase of system or critical service shall meet the following requirements. • Functional testing of critical system (new or upgraded system) • User (functions) testing (new or upgraded system or service) • VAPT (new or upgraded system) • Gaps & failures and corrections (new or upgraded system) • System Security & Backup Plan • Vendor risk Assessment meeting legal and compliance requirements before contract sign up

A14.1.2

Securing application services on public networks

The information involved in application services passing over public networks should be protected from fraudulent activity, contract dispute and unauthorized disclosure and modification as following;- a) Application service arrangements between partners should be supported by a documented agreement which commits both parties to the agreed terms of services b) Risk Assessment or Data Impact Assessment should be done before data transfer to prevent data leak or disclosure c) Implementation of effective controls (cryptographic methods for TLS, SSL, AES256, Digital signatures etc) to ensure secure data transfer d) Resilience requirements against attacks should be considered, which can include requirements for protecting the involved application servers or ensuring the availability of network interconnections required to deliver the service.

A14.1.3

Protecting application services transactions

The information involved in application service transactions should be protected to prevent incomplete transmission, misrouting & unauthorized message alteration. Information security considerations for application service transactions should include the following. a) the use of electronic signatures by each of the parties involved in the transaction; b) Ensure authentication information of all parties are valid and verified; c) Privacy associated with all parties involved is retained; d) communications path between all involved parties is encrypted; e) protocols used to communicate between all involved parties are secured;

Page 41: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 41 of 83

e) Storage of the transaction details is secure & encrypted and not publicly access

A14.2

Security in development and support processes

Ensure that information security is designed and implemented within the development lifecycle of information systems

A14.2.1 Secure development policy

Secure SDLC shall be followed in all projects (refer to NIST Secure Software Development Framework (SSDF) 1) security requirements in the design phase; 2) security checkpoints within the project milestones; 3) secure repositories; 4) security in the version control; 5) required application security knowledge; 6) developers’ capability of avoiding, finding and fixing vulnerabilities.

A14.2.2 System change control procedures

Changes to systems within the development lifecycle should be controlled by the use of formal change control procedures. The change control procedures should include but not be limited to: a) maintaining a record of agreed authorization levels; b) ensuring changes are submitted by authorized users; c) reviewing controls and integrity procedures to ensure that they will not be compromised by the changes; d) identifying all software, information, database entities and hardware that require amendment; e) identifying and checking security-critical code to minimize the likelihood of known security weaknesses; f) obtaining formal approval for detailed proposals before work commences

A14.2.3

Technical review of applications after operating platform changes

When an operating platforms or a system is upgraded (major), business-critical applications should be reviewed and tested as following;- a) review of application control and integrity procedures b) Retest including code scan, VAPT before implementation c) Updated business continuity plans if needed All record including VAPT, Scan and test should be available for review/audit

Page 42: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 42 of 83

A14.2.4

Restrictions on changes to software packages

Modifications to software packages should be discouraged, limited to necessary changes and all changes should be strictly controlled. If changes are necessary, the original software should be retained and the changes applied to a designated copy. All changes should be fully tested and documented, so that they can be reapplied, if necessary, to future software upgrades. If required, the modifications should be tested and validated by an independent evaluation body contract sign up

A14.2.5 Secure system engineering principles

Security should be designed into all architecture layers (business, data, applications and technology) balancing the need for information security with the need for accessibility as following;- 1)Minimise attack surface area; the principle of minimising attack surface area restricts the functions that users are allowed to access, to reduce potential vulnerabilities. 2) Establish secure defaults; application must be secure by default 3) The principle of Least privilege 4) Defence in depth; 5) Separation of duties; Separation of duties can be used to prevent individuals from acting fraudulently 6) Avoid security by obscurity; There should be sufficient security controls in place to keep the application safe without hiding core functionality or source code 7) Fix security issues correctly; determine the root cause of the problem

A14.2.6 Secure Development Environment

Security should be designed into all architecture layers (business, data, applications and technology) balancing the need for information security with the need for accessibility as following;- 1)Minimise attack surface area; the principle of minimising attack surface area restricts the functions that users are allowed to access, to reduce potential vulnerabilities. 2) Establish secure defaults; application must be secure by default 3) The principle of Least privilege 4) Defence in depth; 5) Separation of duties; Separation of duties can be used to prevent individuals from acting fraudulently 6) Avoid security by obscurity; There should be sufficient security controls in place to keep your application safe without hiding core functionality or source code 7) Fix security issues correctly; determine the root cause of the problem

A14.2.7 Outsourced development

Where system development is outsourced, the following points should be considered in all IBF projects; a) licensing arrangements, code ownership and intellectual property rights related to the outsourced content; b) contractual requirements for secure design, coding and testing practices; c) provision of the approved threat model to the external developer; d) acceptance testing for the quality and accuracy of the deliverables; e) provision of evidence that security thresholds were used to establish minimum acceptable levels of security and privacy quality;

Page 43: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 43 of 83

f) provision of evidence that sufficient testing has been applied to guard against the absence of both intentional and unintentional malicious content upon delivery; g) provision of evidence that sufficient testing has been applied to guard against the presence of known vulnerabilities; h) contractual right to audit development processes and controls; i) effective documentation of the built environment used to create deliverables;

A14.2.8 System security testing

Testing of security functionality should be carried out during development. Such tests should initially be performed by the development team. Independent acceptance testing should then be undertaken to ensure that the system works as expected and only as expected. The extent of testing should be in proportion to the importance and nature of the system. All test record should be available for audit & review

A14.2.9 System acceptance testing

Any system or service must be tested before deployment. The System acceptance testing should include testing of information security requirements and adherence to secure system development practices. Security tools such as code analysis tools or vulnerability scanners should be used to verify the remediation of security-related defects. System should only go live after implementation of mitigation and re-scan of the system.

A14.3 Test data

A14.3.1 Protection of test data

The use of operational data containing personally identifiable information or any other confidential information for testing purposes should be avoided. The following guidelines should be applied to protect operational data when used for testing purposes: a) the access control procedures, which apply to operational application systems, should also apply to test application systems; b) there should be separate authorization each time operational information is copied to a test environment; c) operational information should be erased from a test environment immediately after the testing is complete; d) the copying and use of operational information should be logged to provide an audit trail

Page 44: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 44 of 83

ANNEX 2: PROPOSAL TEMPLATE

Project Name:

IT Infrastructure Tech Refresh, Application Development and Support

for IBF e-Services

RFP.IT.2021.0002

Name of Corporate Entity:

_____________________________

For Internal (IBF) Use only

Date Received:

Officer-in-charge:

Page 45: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 45 of 83

USEFUL NOTES

(A) Submission of Proposal

To assist us in reviewing your proposal in the shortest time possible, please provide the requested information completely and accurately. If the space provided is insufficient, a separate sheet may be used. Where information is not yet available or not applicable, please indicate accordingly.

(B) Structure of the Quotation

The complete proposal consists of 5 parts:

Part I – Company Data

Part II – Details of Proposed Project

Part III – Project Costs & Fees

Part IV – Acceptance of Terms and Conditions

Part V – Non-disclosure and Security Awareness Undertaking (Third Parties)

Part VI – IBF IT Service Provider Checklist

(C) IBF reserves the right to conduct interviews and on-site visits during the review of the proposal.

(D) The Company in submitting this proposal undertakes not to divulge or communicate to any person or party any confidential information, including but not limited to any documents that may be forwarded from IBF to you subsequently, without having first obtained the written consent of IBF.

PART I – COMPANY DATA

1. GENERAL

(a) Company Name: ___________________________________

(b) Mailing Address: _____________________________________________

2. OWNERSHIP: Information on Paid-Up Share Capital & Shareholders

3. CLIENTELE LIST

Please provide a list of your company’s key clients.

4. SIGNIFICANT ACHIEVEMENTS, AWARDS & CERTIFICATIONS (where applicable)

Please indicate significant achievements, awards and certifications received by company or staff.

Page 46: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 46 of 83

5. SUPPORTING DOCUMENTS REQUIRED

• A copy of the latest updated ACRA search.

• Full set of the latest audited financial / management report for the last 1 year.

• Any other relevant reports or information available.

Part II – Details of Proposed Project

1. Project Approach

[Describe your overall approach to the following task areas. Your response to this form should not exceed three pages.]

• How would you go about gathering requirement?

• How would you go about gathering information from us?

• How would you approach this project?

• What would be the major things you would do in this project?

2. Project Schedule and Workplan

Provide a detailed project implementation plan that includes:

• A Gantt chart showing beginning and end dates of all tasks (the actual project start date will be determined during contract negotiations)

• A table listing vendor staff assignments and proposed labour hours for all tasks

• A brief description of each task and its work products

• A description of each proposed deliverable Insert pages as needed to allow space for your Gantt chart and workplan. [TEXT WITHIN THESE BRACKETS IS TO BE DELETED IN YOUR RESPONSE.] 2. Key Project Staff Background Information

Page 47: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 47 of 83

3. Key Project Staff Members

[Complete the following table for each of the key project staff members. Use your word processor’s copy and paste commands to create additional copies of this table as necessary. Please allow one page for each table. At a minimum, key staff must include your proposed project manager and key contributors to this project.

Staff member name

Position in the company

Length of time in position

Education

Previous work experience

Technical skills and qualifications for the project position

4. Vendor's experience and track record

Summarise your firm’s qualifications and how your firm is uniquely qualified to undertake this project. Your proposal summary is not to exceed two pages. You are also allowed to provide one work sample showing substantially similar work to demonstrate your credentials for this work.

5. Client Reference

Please list 2 contactable clients for whom you have provided services relevant to this RFP.

Client name

Reference name

Title

Phone number

Email addresses

Page 48: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 48 of 83

6. Statement of Compliance

The proposal should reflect the full understanding of all sections within the RFP. In respect of the following RFP documents, Vendor shall provide explicit point-by-point responses of compliance or non-compliance in the form of a compliance table as set out below:

Page 49: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 49 of 83

7. Scope of Services

S/No Proposal Details Able to Deliver?

(Yes/No)

If yes, please provide brief description and cite the relevant section of your

proposal here

If no, please provide reasons

1 Ability to provide a proposal that fulfils IBF’s project objectives and scope of services

A Proposal demonstrates understanding of IBF's project objectives and scope of services

B Evaluation and understanding of existing (AS-IS) Infrastructure and Application Architecture and submission of Detailed Execution Plan for IBF’s acceptance.

C Detailed Execution Plan to consist of TO-BE architecture, Schedule, Risk Management Plan, Security Plan, Migration Plan, Testing Plan, Key Performance Metrix etc.

Page 50: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 50 of 83

S/No Proposal Details Able to Deliver?

(Yes/No)

If yes, please provide brief description and cite the relevant section of your

proposal here

If no, please provide reasons

D Gap analysis between IBF's current state Infrastructure and Application Architecture and the proposed Future State Architecture.

E Derive a Master Plan for IBF to monitor the implementation and manage the deliverables.

F Derive a Risk Management Plan on approach to identify high risk and key risk areas and management of risk, with the tools and procedures to be used to identify, assess, mitigate and report risks throughout the project duration

Page 51: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 51 of 83

S/No Proposal Details Able to Deliver?

(Yes/No)

If yes, please provide brief description and cite the relevant section of your

proposal here

If no, please provide reasons

G Upon acceptance of Detailed Execution Plan, communicate to key stakeholders including IBF’s incumbent vendor(s).

H Setting up of Hosting, Hardware, Software, Licences Installation, Hardening and Security Testing

I Test-migration of IBF Portal & eServices into new infrastructure to be performed with all key performance metrics met with data fidelity testing. This includes connectivity testing to all interfaces and external systems (SARAS, eNETS, H2H etc).

Page 52: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 52 of 83

S/No Proposal Details Able to Deliver?

(Yes/No)

If yes, please provide brief description and cite the relevant section of your

proposal here

If no, please provide reasons

J Pilot testing to be performed with IBF Business Teams.

K Security Review and Compliance to be reviewed by IBF Risk and Governance Team and any deviation highlighted and submitted to IBF management for review

L Migration, Go-live and Post-Migration Monitoring

a) Full-Dress Rehearsal and mitigation of any residual risk

b) Data Migration, cut-over of Services and verification

c) Go-Live

d) Monitoring of Services

Page 53: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 53 of 83

S/No Proposal Details Able to Deliver?

(Yes/No)

If yes, please provide brief description and cite the relevant section of your

proposal here

If no, please provide reasons

M Handing-over and Taking-over of Services

a) Derive and propose a measurable and quantifiable plan to IBF on what constitutes a successful project outcome

b) Discussion and agreement of handing-over/taking-over plan and schedule with outgoing vendor.

c) Knowledge transfer and Documentation

2 Vendor's experience and track record

A Credentials of project team members

B Company’s demonstrated experience and track record on Projects of similar business nature and capacity.

C Feedback provided by references on services delivered for past projects of similar capacity: i) Please provide two client references with the contact numbers and email addresses of the referees cited

3 Ability to meet project timeline

A Ability to meet project timeline as stated in RFP Section 6 - Project Deliverables & Schedule

Page 54: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 54 of 83

Part III – Project Costs & Fees for Category 1 (Mandatory to quote)

a) Costing to be listed in readable Excel Format b) Costing to be in Singapore Dollars excluding GST c) The quotation provided to be categorised as below:

1. Hardware Costing

S/No Item Description Qty* (a)

Unit Price (b)

Amount (a) x (b) = (c)

Discount (d)

Net Price (c) – (d) = (e)

Any Assumptions/Comments

Total

2. Software/Licence Costing

S/No Item Description Qty* (a)

Unit Price (b)

Amount (a) x (b) = (c)

Discount (d)

Net Price (c) – (d) = (e)

Any Assumptions/Comments

Total

3. Hosting Costing

S/No Item Description Qty* (a)

Unit Price (b)

Amount (a) x (b) = (c)

Discount (d)

Net Price (c) – (d) = (e)

Any Assumptions/Comments

Total

4. Professional Services Costing

Page 55: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 55 of 83

S/No Item Description Man-Days (a)

Per Man-Day Costing (b)

Amount (a) x (b) = (c)

Discount (d)

Net Price (c) – (d) = (e)

Any Assumptions/Comments

Total

5. Support and Maintenance Costing

S/No Item Description Qty* (a)

Unit Price (b)

Amount (a) x (b) = (c)

Discount (d)

Net Price (c) – (d) = (e)

Any Assumptions/Comments

Total

6. Add-on/Optional Costing

S/No Item Description Qty* (a)

Unit Price (b)

Amount (a) x (b) = (c)

Discount (d)

Net Price (c) – (d) = (e)

Any Assumptions/Comments

Total

7. Optional Change Request/Service Request Costing

S/No Item Description Man-Days (a)

Per Man-Day Costing (b)

Amount (a) x (b) = (c)

Discount (d)

Net Price (c) – (d) = (e)

Any Assumptions/Comments

Total

Page 56: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 56 of 83

Part III – Project Costs & Fees for Category 2 (Mandatory to quote)

a) Costing to be listed in readable Excel Format b) Costing to be in Singapore Dollars excluding GST c) The quotation provided to be categorised as below:

1. Professional Services Costing

S/No Item Description Man-Days (a)

Per Man-Day Costing (b)

Amount (a) x (b) = (c)

Discount (d)

Net Price (c) – (d) = (e)

Any Assumptions/Comments

Total

2. Application Support and Maintenance Costing

S/No Item Description Qty* (a)

Unit Price (b)

Amount (a) x (b) = (c)

Discount (d)

Net Price (c) – (d) = (e)

Any Assumptions/Comments

Total

3. Add-on/Optional Costing

S/No Item Description Qty* (a)

Unit Price (b)

Amount (a) x (b) = (c)

Discount (d)

Net Price (c) – (d) = (e)

Any Assumptions/Comments

Total

4. Optional Change Request/Service Request Costing

Page 57: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 57 of 83

S/No Item Description Man-Days (a)

Per Man-Day Costing (b)

Amount (a) x (b) = (c)

Discount (d)

Net Price (c) – (d) = (e)

Any Assumptions/Comments

Total

Page 58: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 58 of 83

Part III – Summary Price Schedule (Mandatory to quote)

a) Costing to be listed in readable Excel Format b) Costing to be in Singapore Dollars excluding GST

Category 1

S/No Item Description One-Time Cost

Year 1 Cost Year 2 Cost Year 3 Cost Year 4 Cost Year 5 Cost Comments, if any

Assumptions, if any

1 Hardware Costing

2 Software/Licence Costing

3 Hosting Costing

4 Professional Services Costing

5 Support and Maintenance Costing

Total Costing

A Add-on / Optional Total Costing

B Optional Change Request/Service Request Total Costing

Page 59: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 59 of 83

Category 2

S/No Item Description One-Time Cost

Year 1 Cost Year 2 Cost Year 3 Cost Year 4 Cost Comments, if any

Assumptions, if any

1 Professional Services Costing

2 Application Support and Maintenance Costing

Total Costing

A Add-on / Optional Total Costing

B Optional Change Request/Service Request Total Costing

Page 60: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002

Page 60 of 83

Part IV – Acceptance of Terms and Conditions Should your firm require any exceptions to any specifications, terms, or conditions of this RFP or offer substitutions, please explicitly state the exception(s), reasons(s), and language substitute(s) (if any) in this section of the proposal response. Failure to take exception(s) shall mean that the proposer accepts the conditions, terms, and specifications of the RFP. If your firm takes no exception to the specifications, terms, and conditions of this RFP, please indicate so. Signed By: _______________________ Name: _______________________ Title: _______________________ Date: _______________________

Page 61: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002

Page 61 of 83

Part V – Non-Disclosure and Security Awareness Undertaking (Third Parties)

IMPORTANT NOTES

1. The Institute of Banking and Finance (“the Organisation”) is legally required to comply with the provisions of the Personal Data Protection Act (No. 26 of 2012) (“the Act”). Failure to comply with the Act may result in penalties being issued against the Organisation.

2. To ensure compliance with the Organisation’s internal policies in relation to the Act, all third party contractors and/or service providers are required to sign this Undertaking.

3. This Undertaking shall be signed before the commencement of work and/or services for the

Organisation.

A. CONTRACTOR / SERVICE PROVIDER’S DETAILS

1. Name of Contractor /

Service Provider’s

Company (“Service

Provider”):

2. Company UEN No:

3. Contact Number:

4. Address:

5. Email Address:

6. Nature of Work / Service

provided to Organisation

(“Purpose”):

B. UNDERTAKING

1. Access to Personal Data, non-public and sensitive information (“Confidential Information”) may be required in the performance of the Service Provider’s Purpose. “Personal Data” shall have the meaning given to it in the Act, and refers to information about an identified or identifiable individual, where the individual refers to a natural person, whether living or deceased. It covers all forms of personal data, whether in electronic or non-electronic form. 2. Should the Service Provider have access to such Confidential Information, the Service Provider undertakes that it shall not under any circumstances, release or disclose such Confidential Information to any third party or third party organisation. The Service Provider shall protect such Confidential

Page 62: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002

Page 62 of 83

Information and will employ all reasonable efforts to maintain the confidentiality of such Confidential Information.

3. The Service Provider shall implement such security measures as are reasonably necessary to protect the Confidential Information against unauthorised access, collection, use, disclosure, copying, modification, disposal or any other form of processing (as defined under the Act). 4. The Service Provider shall immediately notify the Organisation of any suspected or confirmed unauthorized access, collection, use, disclosure, copying, modification, disposal or any other form of processing (as defined under the Act) and/or misuse of Confidential Information. Without prejudice to any other rights and remedies that the Organisation may have, the Service Provider shall at its own expense render all necessary assistance to the Organisation to investigate, remedy and/or otherwise respond to such unauthorised access, collection, use, disclosure, copying, modification, disposal or any other form of processing (as defined under the Act). 5. The Service Provider shall immediately inform the Organisation if any Confidential Information is lost or destroyed or becomes damaged, corrupted or unusable. Without prejudice to any other rights and remedies that the Organisation may have, the Service Provider shall restore such Confidential Information at its own expense. 6. Before the Service Provider discloses Personal Data of any third party individuals to the Organisation, the Service Provider undertakes to obtain all necessary consents required under the Act for the Organisation to collect, use and/or disclose such personal data. 7. The Service Provider undertakes to comply with any and all obligations that apply to it under the Act and all subsidiary regulations that may be enacted from time to time under the Act. C. CONSEQUENCES OF BREACH OF UNDERTAKING

The Service Provider acknowledges that:

1. In the event of any breach or neglect of its obligations under this Undertaking, the Organisation may exercise its right to refuse the Service Provider access to the Organisation’s premises and facilities. 2. If the Service Provider should breach any provisions of this Undertaking, the Organisation may suffer immediate and irrevocable harm for which damages may not be an adequate remedy. Hence, in addition to any other remedy that may be available in law, the Organisation is entitled to injunctive relief to prevent a breach of this Undertaking. 3. Without prejudice to any other clause(s) in this Undertaking, the Service Provider shall bear all liability and shall fully indemnify the Organisation against any and all actions, claims, proceedings (including proceedings before the Personal Data Protection Commission (“PDPC”)), costs (including costs of complying with any remedial directions and/or financial penalties that may be imposed by the PDPC on the Organisation), damages, legal costs and/or other expenses incurred by the Organisation or for which the Organisation may become liable due to any failure by the Service Provider or its employees or agents to comply with any of its obligations under this Undertaking.

Page 63: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002

Page 63 of 83

4. Even after the Service Provider ceases its Purpose at the Organisation, it agrees that the obligations herein shall continue.

Name of Service Provider: _________________________________

Service Provider’s Company Stamp:

_________________________________

Name of Representative of Service Provider:

_________________________________

Signature of Representative of Service Provider:

_________________________________

Date:

_________________________________

Page 64: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002

Page 64 of 83

Part VI – IBF IT Service Provider Checklist

Name of Service Provider

Date Completed

Name of Respondent

Designation / Title

Contact Number

Email Address

Signature

Company Stamp

For the Institute of Banking and Finance (“IBF”) use only:

Name of Reviewer

Designation / Title

Contact Number

Email Address

Page 65: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002

Page 65 of 83

Instructions

1. This security checklist should be completed by senior officers who have direct knowledge of the information systems and operations. The information provided in this checklist should be reviewed by their superiors.

2. For each guideline description, place an “X” in the appropriate column to indicate whether the financial institution is fully compliant, partially compliant, or not compliant. Otherwise, place an “X” in the NA column.

3. If full compliance has not been achieved, explain in the Comments column why, and how and when remedial action would be made.

4. Evidence of Vulnerability Assessment and Penetration Testing, Configuration Assessment for Cloud systems, and Incident Management Plan to be attached together with this submission.

5. System and Organization Controls Report (preferably SOC 2 plus) and Outsourced Service Provider Audit Report (OSPAR) will have to be attached together with this submission.

Page 66: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

Page 66 of 83

S/N

Risk Category

Full

Co

mp

lian

ce

Par

tial

Co

mp

lian

ce

No

n-

com

plia

nce

N.A.

Comments

1 Usage Risk

1.1

Recent released version of Transport Layer Security (minimally

TLS version 1.2 or later) is implemented to provide

communication security.

(Adopted from MAS TRM E.2.5)

1.2 Application and database are physically hosted in Singapore.

1.3

The service provider has established a disaster recovery

contingency framework which defines its roles and responsibilities

for documenting, maintaining and testing its contingency plans

and recovery procedures.

(Adopted from MAS TRM 5.1.7)

1.4

A data backup strategy is developed for the storage of critical

information on a regular basis.

(Adopted from MAS TRM 8.4.1)

1.5 Periodic testing and validation of the recovery capability of

backup media is carried out.

(Adopted from MAS TRM 8.4.3)

Page 67: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

Page 67 of 83

S/N

Risk Category

Full

Co

mp

lian

ce

Par

tial

Co

mp

lian

ce

No

n-

com

plia

nce

N.A.

Comments

1.6 Service provider provide logging is available to IBF via download or through a web application for:

• User to role/privilege mapping

• User activity

• Administrative activity

1.7

Service Provider has achieved compliance certifications. (please

indicate certification, e.g. PCI Compliance, STAR, SAS70/SSAE16‐

3)

1.8

Service Provider has completed the Cloud Security Alliance (CSA)

self-assessment or Consensus Assessments Initiative

Questionnaire (CAIQ).

1.9 Service Provider conforms to a specific industry standard security

framework, e.g. NIST Cyber Security Framework or ISO 27001.

1.10 Service Provider has a dedicated Information Security office or

staff.

Page 68: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

Page 68 of 83

S/N

Risk Category

Full

Co

mp

lian

ce

Par

tial

Co

mp

lian

ce

No

n-

com

plia

nce

N.A.

Comments

1.11 Service Provider has not suffered any significant breaches in the

last 5 years.

1.12 All components of the disaster recovery plan are reviewed at

least annually and updated as needed.

1.13 Service Provider has a formal incident response plan.

2 Application Risk

2.1

Mobile and Desktop application do not store data on devices.

(e.g. PII, confidential data)

2.2 Service Provider complies with GDPR and PDPA.

2.3 Annual Vulnerability Assessment and Penetration Test (VAPT) is

performed.

2.4

Penetration testing is conducted prior to the commissioning of a

new modules/enhancements which offers internet accessibility

and open network interfaces.

(Adopted from MAS TRM 6.2.4)

Page 69: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

Page 69 of 83

S/N

Risk Category

Full

Co

mp

lian

ce

Par

tial

Co

mp

lian

ce

No

n-

com

plia

nce

N.A.

Comments

2.5 Application supports role-based access control (RBAC) for end-

users.

2.6 Application and infrastructure support role-based access control

(RBAC) for system administrators.

2.7 Application and infrastructure support password/passphrase

aging.

2.8 Audit logs minimally include the following: login, logout, actions

performed, and source IP address.

2.9 Service Provider has existing policies and/or procedures guiding

how security risks are mitigated until patches can be applied.

2.10 Vulnerabilities discovered in the systems or applications are

remediated prior to release.

3 Data Security Risk

3.1 Data resides physically in Singapore.

Page 70: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

Page 70 of 83

S/N

Risk Category

Full

Co

mp

lian

ce

Par

tial

Co

mp

lian

ce

No

n-

com

plia

nce

N.A.

Comments

3.2

Service Provider to promptly remove or destroy data stored at

the service provider’s systems and backups in the event of

contract termination and provide a certification.

(Adopted from MAS TRM 5.2.4)

3.3

The data loss prevention strategy and encryption take into consideration the following:

(Adopted from MAS TRM 9.1.2)

a) Data at endpoint - Data which resides in notebooks, personal

computers, portable storage devices and mobile devices;

b) Data in motion - Data that traverses a network or that is

transported between sites; and

c) Data at rest - Data in computer storage which includes files

stored on servers, databases, back-up media and storage

platforms.

3.4 Service Provider does not have access to IBF’s data.

3.5 The Service Provider is able to isolate and clearly identify IBF's

data and other information system assets for protection.

(Adopted from MAS TRM 5.2.3)

Page 71: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

Page 71 of 83

S/N

Risk Category

Full

Co

mp

lian

ce

Par

tial

Co

mp

lian

ce

No

n-

com

plia

nce

N.A.

Comments

3.6

Measures are implemented to protect sensitive or confidential

information such as personal, account and transaction data

which are stored and processed in systems.

(Adopted from MAS TRM 9.0.2)

3.7

IBF is properly authenticated before access to online transaction

functions and sensitive personal or account information is

permitted.

(Adopted from MAS TRM 9.0.2)

3.8

Only encryption algorithms which are of well-established

international standards are adopted.

(Adopted from MAS TRM 12.1.3)

3.9

Monitoring or surveillance systems are implemented so that the

organisation can be alerted of any abnormal system activities,

transmission errors or unusual online transactions.

(Adopted from MAS TRM 12.1.5)

Page 72: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

Page 72 of 83

S/N

Risk Category

Full

Co

mp

lian

ce

Par

tial

Co

mp

lian

ce

No

n-

com

plia

nce

N.A.

Comments

3.10 Service Provider has a data privacy policy.

3.11 Sensitive data is encrypted in transit (e.g. system to client).

3.12

Service Provider has an existing documented media handling

process covering, but not limited to, end-of-life, repurposing,

and data sanitisation procedures.

3.13 Service Provider owns the physical hosting location (e.g. data

centre) where IBF’s data will reside.

3.14 Service Provider has obtained Systems and Organisation Controls

(SOC) 2 Type II certification for the hosting location.

3.15

Service Provider has implemented a physical barrier in the

hosting location to fully enclose the physical space preventing

unauthorised physical contact with any of the devices inside.

3.16 Service Provider has physical security controls and policies in

place to protect the hosting location.

Page 73: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

Page 73 of 83

S/N

Risk Category

Full

Co

mp

lian

ce

Par

tial

Co

mp

lian

ce

No

n-

com

plia

nce

N.A.

Comments

3.17

Employees of Service Provider are not allowed or able to take

home any assets in any form (including any hardware, software

or data) belonging to IBF.

4 IT Service Management

4.1 Service Provider provides Service Level Agreement (SLA).

4.2

Service Provider to support and assist in audit activity by

providing necessary documents upon request.

(Adopted from MAS TRM 5.1.3)

4.3

The Service Provider is required to employ a high standard of

care and diligence in its security policies, procedures and

controls to protect the confidentiality and security of IBF's

sensitive or confidential information, such as personal data,

computer files, records, object programs and source codes.

(adopted from MAS TRM 5.1.4)

4.4

IBF is kept informed of any major incident.

(Adopted from MAS TRM 7.3.9)

Page 74: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

Page 74 of 83

S/N

Risk Category

Full

Co

mp

lian

ce

Par

tial

Co

mp

lian

ce

No

n-

com

plia

nce

N.A.

Comments

4.5 IBF is kept informed of any enhancement to the system.

4.6

A root-cause and impact analysis are performed for major

incidents which result in severe disruption of IT services.

(Adopted from MAS TRM 7.3.10)

4.7

Employees of Service Provider are subjected to close supervision,

monitoring and access restrictions.

(Adopted from MAS TRM 11.1.2)

4.8

Service Provider’s access privileges to support/maintain the

system are regularly reviewed to verify that privileges are

granted appropriately and according to the ‘least privilege’

principle.

(Adopted from MAS TRM 11.1.4)

4.9 Service Provider has a documented and currently followed

change management process (CMP).

4.10 Service Provider has monitoring in place for Next-Generation

Persistent Threats (NGPT).

Page 75: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

Page 75 of 83

S/N

Risk Category

Full

Co

mp

lian

c

e P

arti

al

Co

mp

lian

c

e N

on

-

com

plia

nc

e

N.A.

Comments

4.11 Service Provider monitors for intrusions on a 24x7x365 basis.

4.12 A separate management network is used for the

administration of the system or service.

Page 76: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 76 of 83

ANNEX 3: DOCUMENTATION

1 Project Management Plan (PMP)

The plan shall, at a minimum, include the following items for both the development and maintenance phases:

(a) Project description;

(b) Work Breakdown Structure;

(c) Project Schedule;

(d) The basis in which the Vendor appoints the sub-contractor such as infrastructure architect or

application/web designer, the relationship between the Vendor and the sub-contractor, the procedures

used by the Vendor to manage the sub-contractors and problem escalation approach;

(e) Project Resources of the Vendor and sub-contractor including project team structure, reporting

structure, roles and responsibilities, contact information etc.;

(f) Progress Report;

(g) Problem resolution including Escalation Matrix for reporting of issues;

(h) Project Communication Plan; and

(i) Project assumptions, constraints and risks (internal and external);

2 Quality Assurance Plan (QAP)

The plan shall, at a minimum, include the following:

(a) Quality assurance methodology;

(b) Procedures and tools to ensure quality of deliverables; and

(c) Documentation of Test plan, scripts and results;

3 Risk Management Plan (RMP)

The plan shall, at a minimum, include the following:

(a) Approach to managing risk;

Page 77: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 77 of 83

(b) Tools and procedures used to identify, assess, mitigate and report risks throughout the project duration;

and

(c) Risk priority assessment.

4 Stakeholder Interviews and Usability Study Report

At the end of the Usability Study, the Vendor shall discuss and present the findings and recommendations to

IBF which include the following:

(a) Findings from qualitative and/ or quantitative user surveys and/or research on IBF’s key users on their

needs, expectations, concerns, and areas for improvements in System design and in the delivery and

quality of information when they visit the System;

(b) Findings identified from the overall usability assessment of the current websites;

(c) Report of research studies conducted;

(d) Information architecture of the new System;

(e) Content inventory of the new System;

(f) One (1) design mock-ups of the System; and

(g) Presentations to IBF on the findings and recommendations for the new System for approval prior to the

development of the new System.

5 Functional Requirement Specification

The specification shall, at a minimum, include the following:

(a) All the use cases documented to show how the users interact with the System and potential error

messages. To include at a minimum a description of every input (stimulus) into the System, every output

(response) from the System including potential error messages and reports and all functions performed

by the System in response to an input or in support of an output.

(i) Description of data to be entered into the System;

(ii) Capture of all screen shots in the System;

(iii) Description of operations performed by each screen;

(iv) Description of work-flows performed by the System;

(v) Description of system reports or other outputs; and

(vi) System access rights.

Page 78: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 78 of 83

(b) Compliance with any applicable regulatory requirements such as the Personal Data Protection Act

(PDPA)

The Functional Requirements Specification is designed to be read and understood by IBF staff with no prior

technical knowledge.

6 Technical Design Specification

The specification shall, at a minimum, include the following

(a) Technologies used;

(b) Enterprise Architecture inclusive of business, data/information, application (software) and technical

(network) architecture. For technical architecture, detailed physical and logical network diagrams are

required;

(c) Database design with primary and foreign keys and data model, dictionary inclusive of entity

relationship diagrams; and

(d) Interfaces with other existing Systems.

7 Security Vulnerabilities Assessment, Penetration and Test Reports

The report shall, at a minimum, include:

(a) Vulnerability assessment report

(b) Security Penetration Test Report of all the known vulnerabilities.

(c) Code Vulnerability Scan Report

(d) Test report to ensure that all the defects or gaps identified in Security Penetration Test Report had been

rectified.

8 Programs Specifications and Source Codes

(a) The Program Specifications shall, at a minimum, include:

(i) Input descriptions;

(ii) Output descriptions;

(iii) Data Structure descriptions; and

(iv) Program descriptions.

(b) There should be comments in source codes for easy traceability and maintainability.

Page 79: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 79 of 83

9 Security Management Plan (SMP)

The report shall, at a minimum, include:

(a) Measures taken for access control and to meet audit requirements;

(b) Measures taken to mitigate all identified security risks;

(c) Measures implemented at each tier of the three-tier architecture (i.e. presentation, business logic and

data tiers) or Model View Controller architecture; and

(d) Classification of all data,

10 Performance Test Plan (PTP)

The plan shall, at a minimum, include testing to ensure that the following technical requirements are met:

(a) Systems Performance;

(b) Systems Availability; and

(c) Systems Reliability.

11 Data Transformation and Migration (DTM) Plan

The plan shall, at a minimum, include the following:

(a) Before one-time DTM

(i) DTM approach;

(ii) The estimated duration;

(iii) Work Breakdown Structure (WBS) with all activities listed, duration of each activity, clear

responsibilities assigned to the Vendor’s staff, interdependencies of the activities etc;

(iv) Verification to ensure that the data is not corrupted and the number of records residing in the

new database tables tallied with the records in the source systems;

(v) Exception and error-handling process;

Page 80: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 80 of 83

(vi) Mapping of data fields;

(vii) Critical Success Factors and Critical Path;

(viii) Contingency Plan;

(ix) DTM Test Plan which includes test scenarios, expected and actual outcomes; and

(x) The actual data size to be migrated.

(b) After one-time DTM

(i) Status of the migration exercise;

(ii) Reconciliation of the records migrated and loaded to the database tables;

(iii) Handling of exceptional or failed data; and

(iv) DTM Test Report.

12 Data Mining and Analytics (DMA) Design Plan

The design plan of the DMA shall, at a minimum, include:

(a) Security, access rights and privacy concerns of data;

(b) The approach to feed data from existing Systems into the new System;

(c) Approach for error reporting such as standard data consistency, format checks and resolution etc;

(d) Scalability required for future needs such as additional data sources;

(e) Provide a compatible Business Analytics/Intelligent tool to support predictive analytics and other

analytical purposes;

(f) Reports, dashboards and data extraction should not be on live or operational data for performance

reasons; and

(g) Capturing of all audit trail information.

Page 81: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 81 of 83

13 Software and Licence Inventory List (SIL)

The list shall, at a minimum, include:

(a) All the software and licences used for the System including third party libraries, packages etc.; and

(b) To identify all the software that required licenses.

14 User Acceptance Test Plan and Test Report

The plan and report shall, at a minimum, include the following:

(a) Scope, purpose and duration of UAT;

(b) Test scenarios, scripts, detailed chronological steps and data for testing;

(c) Expected and actual test outputs;

(d) Mapping of the test scenarios and cases to both Functional and Design Specifications;

(e) Approach for logging of all issues and problems encountered by users; and

(f) Turn-around time for closure of issues and problems by Vendor.

15 User Guide

The guide shall, at a minimum, include the following:

(a) Summary of the System;

(b) Glossary (Definitions/Acronyms);

(c) Step by step instructions on using the System;

(d) Trouble-shooting steps;

(e) Generation and printing of reports;

(f) How to use Help; and

(g) How to access the System.

Page 82: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 82 of 83

16 Deployment Plan

The plan for both UAT and Production environment shall, at a minimum, include the following:

(a) Comparison of old and new source codes (if applicable);

(b) Time and duration of deployment;

(c) Database design for new or amended existing database tables;

(d) New source codes created such as batch scripts, packages, modules etc;

(e) All the deployment steps in sequential order; and

(f) Testers’ involvement for verification after the deployments.

17 Maintenance and Operations Manual

The manual shall, at a minimum, include the following:

(a) Step by step installation, configuring, deploying and validating instructions;

(b) New System configurations, changes made and reasons for changes are documented for easy

references in the future and for audit purposes;

(c) Handling of batch job failures;

(d) Housekeeping, archival and restoration approach; and

(e) Troubleshooting procedures.

18 IT Service Report

The report shall, at a minimum, include the following:

(a) The status of all issues logged/ service tickets raised;

(b) Progress of existing defects fixing including root cause analysis;

(c) Any incidents encountered (this is a summary and is separate from the actual incident reports

(d) Service Level)

Page 83: PUBLIC DOCUMENT REQUEST FOR PROPOSAL Project Name: for …

RFP.IT.2021.0002 Page 83 of 83

(e) operations monitoring (e.g. the network utilisation monitoring, storage utilisation monitoring); and

(f) security issues encountered.