On 21 June 2013, the Monetary Authority of Singapore (“MAS”) issued revised Technology Risk Management Guidelines (“TRM Guidelines”). The TRM Guidelines consolidate past circulars on endpoint security and data protection, and information systems reliability, availability, and recoverability. They have also been enhanced to better address existing and emerging technology risks. All financial institutions (“FIs”) will be required to abide by the TRM Guidelines, which came into effect immediately. The MAS has also issued various Notices which define a set of legal requirements relating to technology risk management for FIs. These include requirements for a high level of reliability, availability, and recoverability of critical IT systems and for FIs to implement IT controls to protect customer information from unauthorised access or disclosure. The Notices will take effect as from 1 July 2014.
In addition to the TRM Guidelines and the Notices, the MAS has also issued the following: • Checklist for TRM Guidelines;
- Response to Public Feedback for the Consultation Paper on the TRM Guidelines;
- Instructions on Incident Notification and Reporting to the MAS;
- Incident Report Template;
- FAQs on the Notices on Technology Risk Management; and
- Response to Public Feedback for the Consultation Paper on the Notices on Technology Risk Management.
This Update takes a look at the Notices and the FAQs. We will also be putting together a general primer for clients which will be available on request later.
The documents listed above may be obtained from the MAS website (www.mas.gov.sg).
Requirement to identify critical systems
The Notices require all FIs to put in place a framework and process to identify critical systems. These refer to systems, the failure of which will cause significant disruption to the operations of the FI or materially impact the FI’s service to its customers. In its FAQs, the MAS gives the following examples of critical systems:
- Automated Teller Machine systems;
- Online banking systems; and
- Systems which support payment, clearing, or settlement functions.
Requirement to maintain list of critical systems
FIs will be required to carry out an assessment of their systems to identify which of them fall under the definition of “critical systems” as defined in the Notices. Not all FIs operate critical systems and the MAS notes in its FAQs that it is possible that after an assessment, none of an FI’s systems falls within the definition. Where an FI does identify critical systems, it should also document and maintain a list of such systems.
FIs must also implement IT controls to protect customer information from unauthorised access or disclosure.
Downtime and Recovery
Maximum total outage permissible
The Notices stipulate that an FI must make all reasonable efforts to maintain high availability for its critical systems. It must ensure that the maximum unscheduled downtime for each critical system that affects its operations or service to its customers does not exceed a total of four hours within any period of 12 months. In its FAQs, the MAS gives the following example of how total outage for any period of 12 months will be calculated:
- FI recorded outage A of 3 hours in 1 July 2013.
- FI recorded outage B of 0.5 hours in 20 December 2013.
- Assuming there are no other incidents between 21 December 2013 and 30 June 2014, the total system downtime for the 12- month period from July 2013 to June 2014, is 3.5 hours.
- Starting 1 July 2014, the total system downtime becomes 0.5 hours as outage A can only be accrued for 12 months.
- If FI encounters an outage C between July and December 2014, the total system downtime would be calculated as, “0.5 hours + outage C” until outage B expires on 19 December 2014.
Recovery time objective of four hours
FIs are required to establish a recovery time objective (“RTO”) of not more than four hours for each critical system. The RTO is the duration of time, from the point of disruption, within which a system must be restored. FIs should validate and document, at least once every 12 months, how they perform their system recovery testing and when the RTO is validated during the system recovery testing.
Discovery and Notification of IT Security Incidents
Requirement to notify the MAS within one hour
Upon discovery of an event (“relevant incident”) that involves a security breach, such as hacking of, intrusion into, or denial of service attack on, a critical system, or a system which compromises the security, integrity, or confidentiality of customer information, an FI must notify the MAS as soon as possible and in any event no later than after one hour after making the discovery. The FAQs explain that unlike a RTO, time starts running from the point of discovery of the system malfunction and not from the point of disruption. Hence, for example, if an incident occurs at T, but the FI only discovered it at T+1, then the FI must report the incident to the MAS by T+2. However, the RTO starts counting from T and the system must be recovered by T+4.
Need to establish procedures for detention and notification
The FAQs also explain that FIs are expected to establish clear internal procedures for the swift detection and identification of relevant incidents. They are required to notify the MAS promptly after they have ascertained that the nature and magnitude of an IT incident amounts to a relevant incident, and should establish an internal reporting and escalation process to ensure that they report to the MAS in a timely manner.
Incidents which need not be notified
The FAQs clarify that an FI is not required to notify the MAS of an IT security incident if it did not have a severe and widespread impact on its operations or materially impact its service to its customers. Accordingly, FIs are not required to notify the MAS of attempted intrusions that fail, nor system or component failures which have been recovered through a “high availability” configuration and do not affect the proper functioning of the system.
FIs should record the unscheduled downtime for each critical system that affects the FI’s operations or service to its customers as part of its system availability monitoring, and the MAS may request for such records during its ongoing supervision.
Submission of Root Cause and Impact Analysis Report
Content of root cause and impact analysis report
Where a relevant incident has occurred, FIs are required to submit a root cause and impact analysis report to the MAS within 14 days from its discovery. If necessary, FIs may request for an extension of the submission deadline. The report must contain the following information:
- An executive summary of the relevant incident;
- An analysis of the root cause which triggered the relevant incident;
- A description of the impact of the relevant incident on the FI’s compliance with laws and regulations applicable to it, its operations, and its service to its customers; and
- A description of the remedial measures taken to address the root cause and consequences of the relevant incident.