public document request for proposal project name: for …
TRANSCRIPT
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]
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
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.
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.
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
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.
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.
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
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:
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]
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.
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.
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.
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
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,
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.
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.
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
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.
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.
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.
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
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
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.
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.
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
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.
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.
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
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.
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
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.
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.
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
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
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.
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.
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.
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:
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;
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
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;
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
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:
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.
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
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
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:
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.
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
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).
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
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
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
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
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
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
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
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
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: _______________________
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
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.
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:
_________________________________
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
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 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 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 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 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 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 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 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 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 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 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.
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;
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.
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.
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;
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.
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.
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)
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.