Boundaries of the CDR Data Environment

The CDR data environment involves identifying the people, processes and technology that manages, secures, stores, processes, transmits or otherwise interacts with CDR data. 

CDR data also includes any data derived from CDR data. We describe CDR data as being toxic, contaminating any derived data or systems with the CDR Rules. The CDR data environment may include infrastructure owned by, and management provided by, a third-party service provider.

The CDR Rules therefore apply to all system components included in or connected to the CDR data environment, including system components indirectly connected, impacting the configuration or security, or providing security services to the CDR data environment. As no guidance on the boundary scope has been provided by the ACCC, we leverage the guidance provided by the PCI Security Standards Council for scoping a cardholder data environment and apply similar themes to the scope of the CDR data environment.

It is good practice to limit the size of the CDR data environment to the extent practicable. This may be achieved by: 

• Segregating the environment from other systems using firewalls;
• Minimising the number of people interacting with CDR data;
• Limiting the number of systems hosting, processing or accessing CDR data;
• Minimising the use of third-party service providers interacting with CDR data.

If CDR data has not been de-identified per The De-Identification Decision-Making Framework published by the Office of the Information Commissioner and Data61, the Schedule 2 information security controls (Part 1 & 2) apply. This means that encryption, tokenisation or using any non-personal identifier does not reduce the scope of information security compliance, as it still allows the data to be linked to personally identifiable information at some point in the future.

CDR data (including any data derived from CDR data) must be deleted or de-identified after the use consent has expired. N.B. data that has been de-identified during its use can’t be deleted once the use consent has expired. This is very different to the Australian Privacy Principles and puts control of the data in the consumers hands. Use consents are typically one-time or ongoing for up to 12 months. Once the use consent has expired, the data is deemed to be redundant because there is no purpose for the ADR to retain the data under the CDR Rules (unless it is required to be retained to comply with another Australian legislation, noting non-Australian legislation isn’t listed as a reason to keep the data, in which case the data can be retained but only for that reason and has to be secured in compliance with the CDR Schedule 2 information security requirements).

The CDR data environment includes outsourced service providers (OSPs) provided CDR data. If the data has not been completely de-identified the OSP needs to comply with and demonstrate that it complies with the Schedule 2 information security controls. Any other organisations that provide services to the CDR data environment, but cannot access CDR data, are third party providers. If using an outsourced service provider who is acting as a managed service provider e.g. Software-as-a-Service provider, there are a number of considerations that may apply to them if they hold the encryption keys to the CDR data.

Description of the system

CDR participants (any ADR or Representative) need to document a ‘description of the system’ to demonstrate they have assessed and defined the boundaries of the CDR data environment. The CDR data environment can be documented using a detailed data flow diagram and/or through a written statement (recommended to have both). See examples for AWS and Azure. Ongoing, documentation must be reviewed and updated as soon as practicable after a material change to the extent and nature of threats to the CDR data environment or, where no such changes occur, on an annual basis.

Typical contents of the "Description of the system" include:

Overview of operations

• Company Background
• Description of Services Provided 
• Use Case Description
• Data Flows, including derived data
• People Involved
• Technologies Involved
• Locations Involved

Components of the system used to provide the service

• System Boundaries – Network, System and Data Diagrams
• Infrastructure, Software, Database
• Network Segmentation and Network Traffic Control
• System Resilience
• System Monitoring
• Significant Changes During the Review Period

Risk management and related control activities

• Risk Management – Identification, Factors, Analysis, Mitigation
• Selection and Development of Control Activities
• Continuous Monitoring
• Assessment of Security Capability
• Formal Controls Assessment Program - Internal Auditing
• Security Incident Response

Information security governance framework

• Control Environment
• Integrity and Ethical Values
• Policies and Procedures
• Roles and Responsibilities 
• Access Management
• Network & System Security
• Information Asset Lifecycle Management
• Vulnerability Management
• Prevent, Detect & Remove Malware
• Training & Awareness
• Change Management

Data Classification and Handling

• Data Retention and Disposal

Subservice Organisations

• Monitoring of third-party providers and outsourced service providers (OSPs)

FOR MORE INFORMATION

To find out more, get in touch with Darren Booth or your local RSM office today.