For those of you who don’t work in financial services and may not know the structure associated with APRA’s publications, there are Prudential Practice Guides (PPGs) and Prudential Standards (APSs or CPSs). A PPG provides guidance on what APRA considers to be sound practice in particular areas. PPGs discuss legal requirements but are not themselves legal requirements. Simply put, this is APRA telling you what you should be doing without making it enforceable.

On the other hand, APSs and CPSs are regulatory instruments and are therefore enforceable.

Until now, those working within a cyber security team at an Australian financial services company had PPG 234 – Management of security risk in information and information technology (released in 1 February 2010) as their only reference point as to what APRA were expecting from them in regard to their cyber security controls. But things have moved on a fair bit since 2010. Don’t get us wrong, PPG 234 is still used today as the basis for many ‘robust’ conversations with APRA.

APRA’s announcement

That leads us to the Insurance Council of Australia’s Annual Forum on 7th March 2018. It was at this esteemed event that APRA Executive Board Member Geoff Summerhayes delivered a speech which noted:

“APRA views cyber risk as an increasingly serious prudential threat to Australian financial institutions. To put it bluntly, it is easy to envisage a scenario in which a cyber breach could potentially damage an entity so badly that it is forced out of business.

“….What I’d like to address today is APRA’s view on the extent to which the defences of the entities we regulate, including insurers, are up to the task of keeping online adversaries at bay, as well as responding rapidly and effectively when – and I use that word intentionally – a breach is detected”

Summerhayes then went on to announce the release of the consultation draft of CPS 234 – Information Security. Yeah, actual legislative requirements on information security.

So what does it say?

Overall there are a lot of similarities to PPG 234 but the ones that caught our eye based upon our experience working within financial services were:

Roles and responsibilities

  • “The Board of an APRA-regulated entity (the Board) is ultimately responsible for ensuring that the entity maintains the information security of its information assets in a manner which is commensurate with the size and extent of threats to those assets, and which enables the continued sound operation of the entity”. – Interesting stake in the ground from APRA that Boards need to be clear on how they are managing information security risks. The next obvious question is what reporting will the Board need from management for them to discharge those duties?

Information security capability

  • “An APRA-regulated entity must actively maintain its information security capability with respect to changes in vulnerabilities and threats, including those resulting from changes to information assets or its business environment”. – Very interesting. There is a lot in this provision. First, there is a push to a threat based model, which we fully endorse (see our recent blogpost: 8 steps to a threat based defence model). Next, there is a requirement to have close enough control of your information assets to determine if changes to those assets somehow adjust your threat profile. Definitely one to watch. That brings us nicely to the following:

Information asset identification and classification

  • “An APRA-regulated entity must classify its information assets, including those managed by related parties and third parties, by criticality and sensitivity. Criticality and sensitivity is the degree to which an information security incident affecting that information asset has the potential to affect, financially or non-financially, the entity or the interests of depositors, policyholders, beneficiaries, or other customers”. – This really is a tough one. From our experience, many companies say they have a handle on this for their structured data with plans in place to address their unstructured data. In our experience however, very few actually do anything that would stand up to scrutiny.

Implementation of controls

  • “An APRA-regulated entity must have information security controls to protect its information assets, including those managed by related parties and third parties, that are implemented in a timely manner”. – Coming back to the previous point, there is now a requirement to have a clear line of sight of the sensitivity of data, this just adds to the requirement to build effective control over that data.
  • “Where information assets are managed by a related party or third party, an APRA-regulated entity must evaluate the design and operating effectiveness of that party’s information security controls”. – Third party security assurance is no longer a nice to have folks! Third party risk is referenced a couple of times in the draft, and so definitely seems to be a focus point. This will be very interesting as many companies struggle getting to grips with this risk. The dynamic of having to face into actual regulatory obligations however, is a very different proposition.

Incident management

  • “An APRA-regulated entity must have robust mechanisms in place to detect and respond to information security incidents in a timely manner. An APRA-regulated entity must maintain plans to respond to information security incidents that the entity considers could plausibly occur (information security response plans)”. – We love this section. A very important capability that often gets deprioritised when the dollars are being allocated. Whilst the very large banks do have mature capabilities, most do not. Pulling the ‘Banks’ industry benchmark data from our NIST maturity tool we see that for the NIST domain Respond, the industry average is sitting at 2.39. So in maturity terms it is slightly above Level 2 – Repeatable, where the process is documented such that repeating the same steps may be attempted. In short, many have a lot to do in this space.

Testing control effectiveness

  • “An APRA-regulated entity must escalate and report to the Board or senior management any testing results that identify information security control deficiencies that cannot be remediated in a timely manner, to enable an assessment and potential response by the Board or senior management to mitigate the exposure, as appropriate”. – Yep, we also love this. Putting formal requirements around the basic principle of ‘fix what you find’! The key message from us to Boards and senior management is make sure you are clear on what is in/out of scope for this testing and why.
  • “Testing must be conducted by appropriately skilled and functionally independent specialists”.- The Big 4 audit firms will be very excited about this one!

APRA Notification

  • “An APRA-regulated entity must notify APRA as soon as possible, and no later than 24 hours, after experiencing an information security incident”. –  Eagle-eyed readers will spot that this reflects mandatory data breach obligations that recently came into force under the Privacy Act on 22 February. The Privacy Act requires entities that experience a serious breach involving personal information, to notify the OAIC and affected individuals ‘as soon as practicable’ after identifying the breach. Another example of how companies now have to contend with notifying multiple regulators, on different time-frames. 

Conclusion

CPS 234 is just a draft, and ultimately the final product may be vastly different. Nevertheless, we feel APRA’s approach is a positive step to drive awareness of this significant risk, and one which will hopefully be used to baseline the foundational cyber security capabilities noted within. Well done, APRA!

Consultation on the package is open until 7 June 2018. APRA intends to finalise the proposed standard towards the end of the year, with a view to implementing CPS 234 from 1 July 2019.

Link to the consultation draft.


If you enjoyed this and would like to be notified of future elevenM blog posts, please subscribe below.