Analysis of APRA Info Paper on Cloud: 2015 vs 2018

This article represents my own view points and not the views of my employer, Amazon Web Services.

This is an analysis of the changes between the 2015 and 2018 versions of APRA's primary guidance to Australian regulated financial entities about the use of cloud. It compares the most important changes between the two versions, with a brief comment as appropriate. The two papers are:

2015 Information Paper: Outsourcing Involving Shared Computing Services (Including Cloud)

2018 Information Paper: Outsourcing Involving Cloud Computing Services

In summary, the 2018 paper is an update of the 2015 paper and not an entirely new set of rules. The latest paper is a clear acknowledgement that risk management maturity has improved both at service providers and within regulated entities. It provides clarity on the risk categories and notification process, and adds additional details especially on control implementation and the shared responsibility model.

1) Improved Risk Management Maturity

2015:“APRA’s review of these arrangements has identified some areas of weakness, reflecting risk management and mitigation techniques that are yet to fully mature in this area.”

and

“In light of weaknesses in arrangements observed by APRA, it is not readily evident that risk management and mitigation techniques for public cloud arrangements have reached a level of maturity commensurate with usages having an extreme impact if disrupted”

2018:“Service providers have strengthened their control environments, increased transparency regarding the nature of the controls in place, and improved their customers’ ability to monitor their environments. APRA-regulated entities have also improved their management capability and processes for assessing and overseeing the services provided.”

and

“However, for extreme inherent risk, APRA expects an entity will be able to demonstrate to APRA’s satisfaction, prior to entering into the arrangement, that the entity understands the risks associated with the arrangement, and that its risk management and risk mitigation techniques are sufficiently strong.

Comment: This is a great way to start the new paper. APRA clearly acknowledges that service providers and regulated entities have both improved since 2015. Most importantly, APRA has signaled that they now believe that regulated entities (in conjunction with service providers) “will be able to” demonstrate sufficiently strong risk management to migrate and operate extreme risk workloads (such as Systems of Record) to the cloud.

2) Same Risk Categories but More Detail:

Extreme Risk

2015: “Use of shared computing services that, if disrupted, can have an extreme impact: Hosting systems of record holding information essential to determining obligations to customers (such as customer identity, current balance/benefits and transaction history).”

2018: “Extreme Inherent Risk: Heightened inherent risk arrangements which could, if disrupted, result in an extreme impact. Extreme impacts can be financial and reputational, potentially threatening the ongoing ability of the APRA-regulated entity to meet its obligations. Examples of extreme inherent risk include public cloud arrangements involving systems of record which maintain information essential to determining obligations to customers and counterparties, such as current balance, benefits and transaction history. For usage of this nature, APRA would expect that entities can demonstrate that their risk management and mitigation techniques and capabilities are sufficiently strong.”

Low Risk

2015: “Use of shared computing services with low risk: Examples of shared computing usage with low risk include: shared facilities, with each entity’s IT assets located on separate hardware; and shared infrastructure hosting the following: applications and data stores with low criticality and sensitivity (as classified by the APRA-regulated entity); non-production environments (e.g. test and development) populated with desensitized data; and websites that deliver publicly available information.”

2018: “Low Inherent Risk: Arrangements which could, if disrupted (where disruption includes a compromise of confidentiality, integrity or availability of systems and/or data) present a low or negligible impact to business operations and the ability of the regulated entity to meet its obligations. Examples of cloud computing usage with low risk: applications and data stores with low criticality (a measure of the impact of a loss of availability) and sensitivity (a measure of the impact of a loss of either confidentiality or integrity) as classified by the APRA-regulated entity; non-production environments (e.g. test and development) populated with desensitized data; and websites that deliver publicly-available information.”

Comment: It is important to note that none of the risk definitions for Low, High or Extreme risk arrangements have substantially changed. The largest change to the risk descriptions is to Extreme risk, which now benefits from additional detail about systems of record, and also guidance on what APRA expects. This description of Low risk adds detail consistent with APRA's overall definition of materiality, which centers on the business impact if disrupted. (Note there were almost no changes to the Heightened Inherent Risk ("High") category.)

3) Clearer Guidance on the Consultation Process:

Extreme Risk

2015:“Regulated entities are required to consult with APRA prior to entering into an outsourcing arrangement involving a material business activity where offshoring is involved.”

and

“Similarly, when the use of shared computing services involves heightened inherent risks, APRA encourages prior consultation, regardless of whether offshoring is involved.“

2018:“Regulated entities are required to consult with APRA prior to entering into an outsourcing arrangement involving a material business activity where offshoring is involved... For cloud initiatives with extreme inherent risk, it would be appropriate for regulated entities to engage with APRA once a firm proposal has been identified, and initial approval to proceed has been given by the appropriate governance authority.”

and

“For uses involving extreme inherent risk, APRA encourages early engagement. This provides APRA with the ability to provide feedback on any areas of potential concern prior to the APRA-regulated entity committing large amounts of resources to the initiative. Proposals with extreme inherent risk will be subject to a greater level of scrutiny by APRA, both initially and as the initiative progresses.”

Heightened Risk

2015:“Regulated entities are required to consult with APRA prior to entering into an outsourcing arrangement involving a material business activity where offshoring is involved.”

and

“Similarly, when the use of shared computing services involves heightened inherent risks, APRA encourages prior consultation, regardless of whether offshoring is involved.“

2018:“Regulated entities are required to consult with APRA prior to entering into an outsourcing arrangement involving a material business activity where offshoring is involved... For initiatives with heightened inherent risk, engagement with APRA would typically occur after the APRA-regulated entity has completed its internal governance processes, and the initiative has been fully risk-assessed and approved by the appropriate governance authority.”

and

“Formal consultation for initiatives with heightened inherent risk would typically take place after the regulated entity has completed its internal governance processes, and the initiative has been fully risk-assessed and approved by the appropriate governance authority.”

Comment: The refinement to the consultation process is the most significant change in the 2018 Info Paper. The change to the consultation process for Extreme Risk Material systems is notable, with APRA indicating they should not be involved until after “initial approval to proceed” is granted by the entity's governance authority. The change to the consultation process for Heightened Inherent Risk arrangement is the largest change: in 2015 it was consult “prior” and in 2018 it is now consult “after” entities complete their internal governance, risk-assessment and approval.

4) Improved Definition of Resiliency and Service Provider Contingency

2015: “continuity of service strategy, including resilience, recovery and provider failure considerations”

and

“It is important to distinguish recovery from resilience when considering the use of shared computing services. Resilience refers to techniques that ensure IT assets remain available in the event of the failure of individual components. Recovery refers to the capability to ensure that the IT environment can meet business recovery objectives in the event that IT assets have become unavailable. In general, resilience reduces the likelihood of IT assets becoming unavailable, whereas recovery reduces the impact of an incident that has compromised availability. APRA-regulated entities need to maintain recovery capability regardless of the level of resilience in place.“

2018: “continuity of service strategy, including high-availability, recovery and provider failure considerations”

and

“It is important to distinguish between high-availability and recovery capability when considering the use of cloud computing services. High-availability refers to techniques which reduce the likelihood of IT assets becoming unavailable in the event of failure of individual components. Recovery refers to techniques to restore IT assets to a known state following a compromise of integrity or availability, thereby reducing the impact of a business disruption. Both high-availability and recovery capability aim to ensure that the business can continue to meet objectives in the event of disruption to IT assets. APRA-regulated entities need to maintain recovery capability regardless of the level of high-availability in place. In addition, contingency plans are also relevant in the case of provider failure for material arrangements.”

and

“In addition, contingency plans are also relevant in the case of provider failure for material arrangements”

Comment: This is another important change, since it was a source of confusion for some entities. It aligns to the regulator's view that Resiliency is composed of High-Availability and Recovery and Contingency, which are three separate focus areas. The 2018 definitions match the industry's generally accepted use of each term. The recognition of High-Availability (which was only a single footnote in the 2015 paper) is beneficial to customers who engineer resilient systems in the cloud. Most importantly, APRA confirms that regulated entities must have a contingency plan related to service provider failure - which is not a requirement to engineer high-availability or recovery to avoid service provider failure. Yes, you should plan for service provider failure but it only has to be a contingency plan.

5) Clarity on Information Security Controls

2015:“security management including: roles/responsibilities, security solutions deployed, vulnerability and patch management, incident detection and response; encryption key management and the boundaries isolating the APRA-regulated entity from other parties.”

2018: “maintaining data quality, information security (such as identity and access management, incident detection and response management, data loss prevention, vulnerability management, configuration management, encryption and key management) and the ongoing monitoring of control effectiveness.”

Comment: This is of interest to IT security teams. It reflects a move away from “security solutions” as a generic term and is more specific especially with the use of industry standard terms like “identity and access management”. The recognition that both “encryption” and “key management” (rather than “encryption key management”) are important because management of the encryption process is just as important as management of the keys.

6) Clear Definitions of IaaS, PaaS, and SaaS

2015: (None)

2018:“IaaS: Infrastructure as a service. This service typically involves the sharing of physical hardware arrangements involving storage, servers, networking or virtualisation.”

and

“PaaS: Platform as a service. This service typically involves providing operating systems, middleware, database or runtime services.”

and

“SaaS: Software as a service. This refers to the provision of software for business users. Examples include customer relationship management, enterprise applications (e.g. payroll, human resource management, and general ledger) and productivity applications (e.g. word processing, spreadsheets, email).”

Comment: This is a routine change but reflects the regulator's acceptance of the industry's terms for what in 2015 APRA called “shared computing”.

7) Additional Observation About Organisational Capabilities

2015: (none)

2018: “observed weakness: changes in required organisational capability are not sufficiently understood or addressed.”

Comment: This is a subtle addition but underscores why AWS has a specific focus on People in the AWS Cloud Adoption Framework. AWS calls that section “Organizational Change Management, which helps you manage the impact of business, structural, and cultural changes caused by cloud adoption.”

8) Additional Clarity on APRA Access

2015: (none)

2018:“APRA access and ability to act: The APRA outsourcing standards require APRA-regulated entities to include an APRA-access clause in the outsourcing agreement. This includes access to both documentation and information, and the right for APRA to conduct onsite visits of the service provider.”

Comment: This was another source of confusion for some entities, and the extra detail in 2018 helps the industry meet APRA's expectations. At AWS, customers have the option to enroll in an Enterprise Agreement, “which gives customers the option to tailor agreements that best suit their needs. For additional information on Enterprise Agreements please contact your AWS representative.”

9) New Section on Implementation of Controls and the Shared Responsibility Model

2015: (none)

2018: “Implementation of controls: The nature of cloud computing services necessitates the allocation of responsibility for the implementation of controls between the provider and the client. This is commonly referred to as the shared responsibility model.”

and

“This normally involves evaluations initiated by the APRA-regulated entity (resourced internally and via independent expertise) as well as the leveraging of audit reports initiated by the service provider, conducted by an independent third party. Common examples include Service Organisation Control reports (SOC 1/2/3) and ISO27001/2, ISO 27017, CSA STAR, NIST Cyber Security Framework.”

and

Table on Page 18

Comment: The phrase “shared responsibility model” is used by APRA six times in the 2018 paper. AWS originated this term as early as 2013, and I am pleased to see AWS's model used as the basis for APRA's newest chapter on how entities and service providers should be clear about the implementation of controls.