The boundary of your CDR Data Environment

 There are two important questions it answers:

1. Is your intended use of CDR data allowed under the rules?
2. How broad is the audit and compliance burden?

Savvy CDR experts like Astero, have developed data boundary standards to help you get this right. That is defining the boundary around your use case and system set up, minimising the compliance burden, and helping you operationalise the boundary from a practical standpoint.

Let's unpack those two key questions.

Is your intended use of CDR data allowed under the rules?

The CDR rules are a moving target. As it stands, data obtained through the CDR regime cannot be shared with any unaccredited third parties in any form. That's expected to change with the CDR Insights model allowing derived data to be shared to unaccredited third-parties, and data sharing with qualified professionals under the Trusted Advisors model. 

If your use case requires sharing the CDR data with third-parties, it's important to consider whether that's allowed under the rules and whether the timing of expected changes will be adequate for your goals. The last thing you want is achieving CDR accreditation, only to find it doesn't meet your business goals!

If you want to explore the compliance angle of your use case, feel free to get in touch for a confidential chat.

How broad is the audit and compliance burden?

The rules require that you minimise the use of identifiable CDR data to the extent possible, while meeting the requirements of your use case. Like least privileged user access, it's the concept of not using data beyond the ways you need to. By limiting the use of data, it reduces the security and privacy risks to consumers and generally keeps it more secure. That said, the rules don't prevent you from using the CDR data in whatever internal systems you need to for your use case.

The point of this second question is that the more places and ways you use the data, the bigger the audit and compliance burden. The 26 CDR security requirements in Schedule 2, Part 2, apply to the scope of where you use the data. That includes the data itself, the infrastructure, software, people and processes. We categorise the security requirements into four types:

1. Governance: The organisational practices that support the environment, eg, policies, procedures, and management processes;
2. Infrastructure: Security configurations that relate to the infrastructure, eg, AWS accounts, that host the CDR Data Environment;
3. Software: The software product(s) that hold CDR Data and others that directly support or interact with those;
4. Endpoints: The devices of your people that have access to or otherwise interact with the CDR Data Environment.

We'll explore a few examples for each area to show the significance of those areas in practice.

Governance

The scope of your CDR Data Environment has limited impact on the governance level controls. These practices generally apply across your organisation anyway. A notable exception is background checks, where police checks are required under the CDR rules for all people supporting the CDR Data Environment. If you don't want to apply police checks across the board, you'll want to limit the number of people classified as part of your CDR Data Environment.

Infrastructure

Let's say you use multiple AWS accounts, and Google Cloud for your CDR Data Environment. The security controls need to be applied across all of those accounts and both platforms accordingly. Those security controls are subject to the initial accreditation audit and ongoing compliance audits. Infrastructure security includes things like encryption, audit logging, firewalls, and network monitoring, for example. 

Software

The more software used with CDR Data, the more systems that are subject to multi-factor authentication, strong passwords, formal access control and user management processes. Software also extends to systems supporting the primary software. You might have a core SaaS product, that then has 3-5 other products supporting that like Github, CircleCI, Okta, 1Password, and SendGrid.

Endpoints 

Endpoint devices (eg, laptops) are often the biggest driver for wanting to narrow the scope. The scope of infrastructure and software used determines which people come into your CDR Data Environment. It's those with access to, or otherwise interacting with, the CDR systems. The scope of people extends to the endpoint devices they use. Endpoint security requirements are some of the more challenging and burdensome areas of CDR compliance. It includes anti-virus software, restricted software installation, and device security settings, for example. This can be particularly difficult if you allow bring-your-own-device (BYOD).

While all of this may sound confusing, complex, and concerning, it doesn't need to be. The key message is, the boundary of your CDR Data Environment is arguably THE most important thing to consider when pursuing CDR accreditation. Speak with those that have practical experience navigating it before you get too far in.

If you want to explore what these two questions mean for you, feel free to get in touch for a complimentary and confidential scoping session.