When you're a licensed financial service provider in Australia, or even just selling your software/services to those providers, APRA regulations come into the frame.

 

When it comes to APRA regulations, there are two ways they might come into scope for your company:

 

 

If you are a licensed financial service provider like a bank, insurer, or superannuation provider, then you are required to comply with APRA's suite of 'CPS' standards. Each standard has a list of requirements, some that are more prescribed activities, while others are more principles based that allows some judgement and flexibility. 

 

 

If you provide your software or services to APRA regulated customers, you may be indirectly required to comply with parts of the APRA standards. This is because the APRA-regulated company has reliance on your software or services when it comes to their information security, business continuity, and risk management practices. The APRA standards have been revised over the last several years to increasingly apply to the whole supply chain and third-party providers to address those risks.

What's required for APRA Compliance?

 

If you are directly APRA regulated, you need to read, understand, and explicitly satisfy each of the requirements. You are subject to regulator oversight and potential sanctions for breaches of compliance. If you are not directly regulated, you do not need to read, understand and explicitly satisfy the requirements, but your customers may need to apply further assessments and seek assurances over your services to satisfy their own obligations.

 

To read the TL;DR of what this means for software companies selling into APRA-regulated customers, skip to the bottom line below.

 

 

 

An APRA-regulated company is required to have a formal process in place for identifying, assessing, managing and monitoring risks. That includes Board level accountability and oversight, and specifics around defining a risk tolerance for the company, the scope of risks to consider, and methods of treating, reporting and revising the risks. The scope of risks includes the third-party supply chain, but this standard does not go as far as to directly impose any requirements that get passed on to those third-party suppliers in practice. It doesn't require that third-party to have implemented these risk management requirements themselves, so the CPS 220 standard is not imposed on them accordingly. 

 

APRA-regulated companies, like most regulated institutions will typically already have a vendor governance framework which includes due diligence over your software and services, prior to engaging in a contract for services with you. There's also typically an annual review process.

 

 

Business continuity management is a range of practices to protect critical services and ensure they are available and reliable to those that rely on them. For banks, as an example, there are critical services the public relies on like pulling their money out of an ATM. Part of the requirements for CPS 232 is to consider the criticality of third-party suppliers in the overall continuity of critical services. For example, if pulling money out of an ATM relied on your software working correctly or being available, then your software would be considered a critical service that comes into the scope of your APRA-regulated customers business continuity management program.

 

Whether you are APRA-regulated, or considered a critical supporting service to a company that is, requirements may be imposed. This includes conducting business impact assessments, planning recovery time objectives, forming continuity and recovery plans, backup arrangements, and conducting testing to ensure the continuity and recovery plans are effective. If you're APRA-regulated, you need to demonstrate how you've satisfied that regulation directly with the risk of fines or regulator intervention. If you're a supplier, you may not have that direct risk, but your enterprise customers reliant on your services will likely impose it on you in a similar way considering their liability for that.

 

 

Information security has been a key focus of regulators in recent years, and CPS 234 was the major uplift in APRA formalising a minimum set of requirements around this. Similar to other standards it has a list of requirements, starting with Board level accountability, and various governance and monitoring requirements to ensure information security is effective in the organisation.

 

Most notably, CPS 234 was the first of the CPS standards to explicitly require APRA-regulated companies to verify their third-party suppliers, in this case verifying their information security. It starts with a criticality and sensitivity assessment, which is essentially determining a risk level to drive what level of verification is required. For example, if you only handled public data, the security risk would be low/immaterial. However, if you held the account data of the APRA-regulated companies customers, that risk could be quite high, and require them to conduct rigorous verification of your information security practices. 

 

 

 

CPS 230 is the newest in the list, released July 2022. Operational risk management pulls together the focus areas of CPS 220 - Risk Management, and CPS 232 - Business continuity management, in a more formal approach to managing operational risk. It requires a formal risk management function, business continuity management practices, operating effective internal controls, and management and reporting of adverse operational events. It also places a large focus (almost half the standard) on third-party suppliers, like CPS 234, that will see APRA-regulated companies responsible for going further to monitor and manage their vendors, and to be able to formally demonstrate that. 

 

 

For software companies that work with, or intend to work with, APRA-regulated customers, these standards will likely impact what's expected of them. Global industry standards like SOC 2, ISO 27001, and HIPAA, cover all of the above topics, and are generally seen as a gold-standard solution to satisfying regulated customers compliance requirements. These don't address all of the specifics of each APRA regulation, so more work is needed if you are directly APRA regulated. But these standards provide a strong baseline, independent verification, and something that can be formally shared with customers to demonstrate how they have satisfied their obligations in the areas of risk management, business continuity management, information security, AND operational risk management.