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:

• Infrastructure layer: controls like encryption, authentication, network security, and physical security, are required across your infrastructure. If you used multiple infrastructure environments for CDR data, each would need to be covered accordingly.
• Software layer: authentication, user access management, and change control for example should be covered across all software used in the CDR Environment.
• People layer: background checks, policy sign-offs, and security awareness training, for example, need to be covered for all people supporting or interacting with the CDR Environment.
• Process layer: The relevant processes in scope are determined by the requirements of the CDR and what processes meet those requirements in the CDR Environment. There may be multiple different processes for the same requirements, eg. different background checks for different types of employees or locations.

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:

• (1) An accredited data recipient must assess, define and document the boundaries of its CDR data environment.
• (2) The accredited data recipient must review the boundaries of its CDR data environment for completeness and accuracy:
  • (a) as soon as practicable when it becomes aware of material changes to the extent and nature of threats to its CDR data environment; or
  • (b) where no such material changes occur—at least annually.

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.