Updated: Jul 13

If you’re aspiring to take advantage of the new Open Banking regulation, the main barrier and cost involved is the CDR Accreditation requirements of Schedule 2, information security requirements.

To become accredited for the Consumer Data Right, the system environment and related business processes need to demonstrate the minimum set of security controls with a SOC 1, SOC 2, or ASAE 3150, independently audited assurance report. The CDR has 24 prescribed requirements like multi-factor authentication, firewalls, protections against malware and data leakage, and related business processes like user access controls and system monitoring.

This assurance report is likely to be the most significant cost of becoming accredited. There's a few key points to consider in which type of report, and the approach to take. For businesses that already have a SOC 1 or SOC 2 report, that's a major head start. That might be a GS 007, ISAE / ASAE 3402, ASAE 3150 (covering the SOC 2 Trust Services Criteria), AT-105 (official SOC 2 standard). If that sounds confusing, all you need to know is that these are all SOC reports with slightly different purposes and issuing bodies. They follow a very similar method of reporting over your controls to satisfy a set of objectives or criteria. It’s important to note that the leading ISO 27001 standard, doesn’t cut it for this accreditation (see: ISO 27001 Stamped Inadequate for Open Banking).

If you don’t have a SOC report already; the fastest way to get accredited and likely the lowest cost approach, would be to issue an ASAE 3150 report specific to the CDR requirements. However, that report is unlikely to be of value beyond the accreditation. If you’re expecting your customers to require an assurance report like SOC in the future or aim to reduce your due diligence requirements, it's worth considering a SOC 2 report that may get more value out of your investment. Keep in mind, you will need to ensure any SOC reporting approach is addressing the CDR requirements specifically.

If you already have a SOC report, further work will be required to ensure it aligns with the more prescriptive requirements of the CDR. For SOC 2 reports that have a similar scope and usually address most (if not all) of the prescribed CDR controls, it’s unlikely to be a major impact to adjust your SOC 2 report accordingly. SOC 1 is likely to require more work. In any case, leveraging your existing SOC reporting is likely to be the best option to address the CDR requirements for the next SOC report you issue under that existing approach.

Whichever SOC reporting approach you take, there’s a few things that need to be addressed. These aren’t always addressed in this way for other SOC reporting purposes.

1. The scope of systems

The scope of the CDR Data Environment includes all systems, people and processes, that collect, store, transmit or otherwise interact with the CDR Data. As part of Schedule 2, Part 1, data recipients are required to define the boundaries of this environment to ensure the following Schedule 2, Part 2 requirements are met for this complete environment.

The scope of other SOC reports should be similar if not the same if they are based on the same product(s) and service(s) as those used for Open Banking. Standard SOC reports follow a similar approach to consider and include all relevant systems, data, infrastructure, people and processes in the scope. With SOC reports the starting point is the scope of services, which determines what customer data and other system components are in scope. For the CDR it starts with the consumer data under the CDR to determine the relevant people, processes and systems.

In any case, the scope needs to meet the requirements of the CDR for accreditation and in some cases may not be completely covered by an existing SOC report.

2. The carve-in approach to outsourced services

The industry-standard approach to SOC reporting is the “carve-out” method. That excludes the controls of third-party service providers supporting the Service Organisation. It doesn’t mean those providers are ignored completely. The controls assessed at the Service Organisation includes how they maintain oversight of their third-party providers, such as risk assessments, monitoring, and reviewing their third-party assurance reports (eg. SOC 2, ISO 27001).

The carve-in approach of the CDR takes that a step further, requiring the data recipient to demonstrate that third-party providers supporting the CDR Data Environment meet the same information security requirements of the CDR for the relevant systems, processes and people that apply. In many cases, like where Amazon, Microsoft or Google, are used to manage the infrastructure environment, this has limited (if any) impact. These providers have their own SOC reports that covers their security practices of the infrastructure services and environment to demonstrate those requirements are met.

However, this carve-in approach is significant for third-parties supporting the CDR Data Environment that do not have SOC reports. That includes many large data centre providers in Australia, as well as other third-parties that support the software development, managed IT services, software products used to support the IT environment, and various other types of services. Some of those third-parties have ISO 27001 certifications or demonstrate information security in other forms, which may have been sufficient in the past. However, the more stringent CDR requirements that deems those methods inadequate could create major headaches for aspiring data recipients relying on those third-parties without SOC reports.

3. The prescribed controls

The CDR requirements is the first time specific control activities have been prescribed in this way for SOC reporting. Usually, the SOC reports have a series of control objectives (SOC 1), the Trust Services Criteria (SOC 2) or follow other frameworks with more flexible control activities. Within that criteria there’s a lot of room for judgement by the auditor, and for the service organisation to implement what they believe to be designed effectively (fit-for-purpose), for their organisation. The CDR is very specific in some areas, for example requiring multi-factor authentication across all in-scope systems.

4. The rest of the CDR

Up to this point, we've focused on the Schedule 2, Part 2 requirements of the CDR. It's important to note that while this is likely to be the most significant barrier and cost involved, there are various other requirements of the CDR. Data recipients need to obtain adequate insurance, operate appropriate privacy practices, support consumers privacy rights, define the boundaries of the CDR Data Environment, and implement and maintain an appropriate governance program with monitoring of the control practices. These may be covered to some extent by existing SOC reports, but further work is required to ensure all the CDR requirements are met.

The key take away

The CDR requirements for aspiring data recipients to achieve accreditation, includes broad, detailed and stringent practices to be applied. The major barrier and cost involved is in providing an independently audited SOC report under SOC 1, SOC 2, or ASAE 3150. It may be a report prepared for this purpose, leverage an existing SOC report, or prepare a SOC report to cover multiple purposes including the CDR. In any case, the CDR requirements are prescriptive and require further assessment and coverage than what is typically included in SOC reports prepared for other purposes.

Data recipients seeking accreditation should discuss their broader assurance strategy and requirements with audit firm that can issue their SOC reports. It's important to understand the best approach for them, and ensure they meet all the CDR requirements to get the most value out of the SOC reports.