The SOC 2 Plus CDR approach to accreditation requires a few tweaks from the standard SOC 2 reporting approach.
The Consumer Data Right is a regulation that allows service providers to make use of the consumer data collected by the banks, with other industries to follow in the months and years ahead. This is subject to accreditation to ensure the privacy and security of consumers data. One of the major and most limiting aspects of accreditation is the requirement for an assurance report. This report needs to be independently audited by a chartered accountancy firm, following the Service Organisation Control (SOC) standards.
The SOC standards have various confusing acronyms, reflecting the different jurisdictions and purposes of these reports. You might have seen references like ASAE/ISAE 3150/3402, SSAE 16/18, ATC-105 and 205. In America it was simplified as “SOC 1” and “SOC 2” to reflect the two main purposes of SOC reports; the first to verify the integrity of financial data, the second on technology risk objectives; security, confidentiality, availability, processing integrity and privacy. In the context of CDR accreditation, a SOC report can be used as long as it demonstrates the required processes and controls from the CDR Schedule 2.
Our other post Why SOC 2 Plus CDR explains why we recommend using the SOC 2 reporting framework for your CDR Accreditation.
How to align your SOC 2 with CDR Schedule 2
Paraphrasing our partner, A-LIGN, a CPA firm and top 25 global cybersecurity company that’s issued thousands of SOC 2 reports; The CDR assurance report is really just another SOC 2 report. In some areas, the CDR Schedule 2 is more prescriptive of the requirements than SOC 2, and vice versa.
In the areas that Schedule 2 is less specific than SOC 2 (eg. Part 1), we follow the more clearly defined practice of SOC 2. In the areas that it’s more specific, the standard flexibility afforded by the Trust Services Criteria (that doesn't prescribe controls), allows us to align to the more prescriptive CDR requirements.
There's five (5) areas where we tweak our usual SOC 2 approach:
We map your controls to SOC 2 and CDR Schedule 2
Our software automatically maps your unique set of controls across multiple standards, including SOC 2 and the CDR. This means there’s no duplication of effort. We include a mapping table in Section V of the SOC 2 report so the ACCC can see exactly how Schedule 2 Part 1 and 2 are being met (or noting if there’s any gaps).
Align your control descriptions to Schedule 2, Part 2
Most SOC 2 reports already include MFA, white listing approved software, and a security incident response capability, for example. But SOC 2 does not prescribe these so you can issue a SOC 2 report with strong password settings, a security policy that requires approval of all software, and a general incident management function. To do the SOC 2 Plus CDR approach, we hold you to that “higher” standard that’s prescribed by the CDR.
Follow SOC 2 for the Schedule 2 Part 1 Requirements
The CDR Schedule 2, Part 1 has requirements for security governance, an information security capability, controls assessment program, and to manage and report security incidents. These are not clearly defined or prescribed in the CDR. They are well-established areas of coverage in SOC 2, which makes it easy to follow the common industry practices that are widely published and described in other SOC 2 reports.
Define the boundaries of the CDR Data Environment
The SOC 2 scope and system description that goes into the final report, always specifies the scope of your systems and data in the format required by the CDR (infrastructure, software, data, people and processes). We just need to ensure the description is either; (a) based solely on the CDR data environment, or (b) specifies how the data environment is a subset of the broader scope, and articulate the boundaries accordingly. We have updated our SOC system description template to guide you on how this should be laid out.
Apply the carve-in approach to service providers
Although the industry standard approach for SOC 2 is termed “carve out”, in most cases it is indistinguishable from a “carve in” approach. We always verify the infrastructure controls for your environment, and check your third-party service provider controls support the same criteria objectives. This is easy to do for leading cloud infrastructure providers and where the providers have their own SOC 2 reports. This approach may be more complicated if you have third-party providers that do not issue their own assurance reports (SOC 2) to verify their controls for areas that support your CDR data environment (eg. physical security of the data centre).
There's some major benefits of SOC 2 Plus CDR rather than the specific ASAE 3150 Report. Aside from the benefits of achieving a leading standard that's internationally recognised, it's also a more cost effective solution. SOC 2 is a well-established and commonly practice standard which provides efficiency benefits that offset the few tweaks in approach explained above.
Read more in our Why SOC 2 Plus CDR post that explains the major benefits of SOC 2 over a specific ASAE 3150 report.