The current regulatory environment that financial services institutions (FSIs) are operating under tends to constrain the move to public cloud environments. Often this is due to concerns that the move may cause regulators to downgrade a financial institution’s risk rating. In Singapore, there are several compliance regulations to be considered for FSIs moving into an outsourced or cloud environment, including deliberate controls that need to be put in place.
Controls can be divided into administrative (also called procedural or management controls), technical, and physical controls. All three types of controls are called for by the Monetary Authority of Singapore (MAS) Technology Risk Management (TRM) Guidelines, and all are necessary for a strong controls approach. They can be broken down as follows.
Administrative controls include all the management structures, processes, and procedures in place to ensure that the right things are done. These include having the right governance in place, ensuring the correct command structure is in place and in use, ensuring reports are generated and reviewed, and ensuring processes such as revoking employee rights when they leave are in place. Other examples are incident response processes, security awareness, and training.
Technical controls include user authentication, logical access controls, antivirus software, and firewalls. Authentication and encryption are mentioned more than once in the MAS and TRM guidelines mention, and such technical controls will need to be strongly enforced in the public cloud.
Physical controls are self-explanatory and mainly aimed at data centre security. Ensuring only the right people have access, for the right reasons and with approval is essential. For very critical systems, the physical controls such as secure rooms for access to terminals, and physical segregation of systems from the Internet can ensure the highest levels of security.
To illustrate how the use of controls in the public cloud would work in a regulated financial institution, three example workloads are considered. These workloads include:
A non-sensitive workload will not be of concern to a regulator but will still require many of the control areas to be in place, though some at a basic level. Examples of non-sensitive workloads could be:
- A website that provides information and does not collect personal or transactional data;
- An application that works only with publicly available information such as Twitter or Facebook data;
- Development or testing servers working only with anonymized data.
Where sensitive data is involved, a more robust level of control will need to be implemented. Examples of sensitive workloads could be:
- A company system that contains employee data but not customer or transactional data. There is a duty to protect such data but most or all could be discovered from other sources such as LinkedIn;
- A system that contains transactional data, but no client data, though if it were compromised, information on trading patterns and volumes could be deduced.
Where confidential information is involved, a high level of control will need to be shown. This includes increased levels of security, monitoring, and more frequent risk reviews and level reporting. Such confidential systems will almost always need to be architected to be highly available. Examples of confidential workloads could be:
- A settlement system that contains client and transactional data;
- A wealth management system that contains client identifying data and details of their holdings.
To learn more about controls and read about specific controls required for non-sensitive, sensitive and confidential workloads, download our white paper.