The boundaries of your CDR environment determine where the stringent security requirements of the CDR schedule 2 need to apply.
The Consumer Data Right gives Australian’s control of their data. That enables innovation in new products and services to those consumers. To participate as a data recipient, there are five governance requirements and 24 information security requirements. These are independently audited by a qualified firm like AssuranceLab, and included in an assurance report for accreditation.
Defining the boundaries of your system is one of the five governance requirements. It sets the context for the 24 information security requirements.
Defining the boundaries of your system is an important practice for all companies. This helps to define your terms of service, contractual responsibilities to customers, and policies like privacy and confidentiality that relate to the scope of data and services you provide to customers or users. It also defines the perimeter at which information security controls are applied to prevent unauthorised access and protect your environment within that boundary.
For more established standards like SOC 2, the boundaries of the system are defined by starting with the services you provide. For example, Atlassian provides Trello Software as a Service. Based on those services, the scope or boundaries are determined by identifying the software, infrastructure, sensitive data, people, and processes that relate to those services. Those components each form part of the scope, and those that don’t are considered outside the boundaries of the system. For example, Atlassian's JIRA software and the team that supports JIRA, may be excluded from the scope for a Trello-focused report. This doesn’t mean you wouldn’t protect those other systems and data, only that they’re not in scope for your SOC 2 audits and reporting.
For the Consumer Data Right (CDR), the boundaries of the system are defined by starting with the consumer data used as an accredited data recipient under the CDR. This is a slightly different but very similar approach to that of SOC 2. It’s also similar to PCI-DSS where the scope is determined based on payment card information. The same principle then applies, you start with that data and identify the software that will process or otherwise interact with that data, the infrastructure that holds and manages that data and software, the processes that manage those systems, and the people interacting with those systems, data and process. If that sounds onerous or complex; it’s not really once you get into it.
Whichever the case, you need to identify the data, software, infrastructure, people, and processes in scope for information security controls. For a small cloud services provider, this can be really easy; you have the cloud platform that hosts the data, your software built on that platform, and often a few directly supporting software products for user authentication and development tools. You generally don’t need to segment your people. It’s easier to bring them all into scope. Your processes are scoped in based on what your company does to achieve the information security requirements (Schedule 2, Part 1 & 2 for the CDR). For the CDR it’s important to have a diagram to support your accreditation by visually showing the in-scope system components and data flows related to the CDR data environment.
The CDR Environment scope determines which control practices are audited and their expected coverage for your assurance report (used for accreditation). There are the following types of controls influenced by the boundaries and system components mentioned above:
You’ll notice there’s overlap in the controls covered across those layers; like authentication that applies to infrastructure and software in the environment.
The infrastructure and software layer controls include those managed by your team and those managed by third parties. The CDR requires a “carve-in” approach to these third parties, like where you use Github, Okta, and AWS, for example. The same control practices are considered, and generally, that’s easy to satisfy using their own SOC 2 reports.
Defining the boundaries of the system is more complex in larger organisations that perform various business activities, not just a SaaS product. That’s where you’ll hear talk of “network segmentation” and other ways to quarantine various parts of your infrastructure, software, people, and processes. This is to avoid requiring the same rigor of information security controls across the entire business, which is very hard to achieve for traditional companies that haven’t implemented best-practice security since their inception. It also causes bigger headaches for audits and assurance reports if the scope is larger and requires more audit work for the accreditation process.
The CDR Perspective
The CDR Schedule 2, Part 1 requires the following in relation to defining the boundaries of the CDR environment:
About AssuranceLab
AssuranceLab is a modern cybersecurity audit firm that provides assurance reports (ASAE 3150, SOC 1/2). We're experts in the latest software and cloud providers. We guide your team through the compliance practices in a way that fits your environment and culture. We work closely with clients through our agile and collaborative approach; saving time, costs, and headaches along the way.