Australia Consumer Data Right: CDR information security and accreditation controls

Any organisation that wants to receive Australian banking or energy customer data through the Consumer Data Right (CDR) must first prove it can protect that data, and the proof is a specific, auditable control set in Schedule 2 of the CDR Rules. Accreditation is not a one-off form: it brings a defined CDR data environment, minimum technical controls, independent assurance on a two-year cycle and data deletion duties that reach your outsourced providers. This guide covers the Schedule 2 information security obligation, Privacy Safeguard 12, the assurance and attestation cycle and the security parts of the Consumer Data Standards. It is written for security leads, auditors and engineers at fintechs, lenders, energy comparators and software providers preparing for or maintaining accreditation, including non-bank lenders brought into the CDR from mid-2026.

Key takeaways

• Schedule 2 has two parts. Part 1 sets five governance steps (security governance, CDR data environment boundaries, security capability, controls assessment, incident management) and Part 2 lists minimum controls under six headings.
• Multi-factor authentication covers all access to CDR data. The accreditation guidelines state that multi-factor authentication or an equivalent control is required for all access to CDR data, not just administrator access.
• Assurance alternates by year. After accreditation, an attestation statement is due at the end of the first reporting period and every second year after, with an assurance report (Type II for unrestricted accreditation) in the years between.
• ISO/IEC 27001 alone is not enough. The guidelines accept ISO/IEC 27001 certification only with a reduced-scope assurance report, an internal audit report and a Statement of Applicability.
• Your obligations follow the data. Contracts must make outsourced service providers take the Schedule 2 steps, and you must direct them to return or delete redundant CDR data.

Where the CDR stands in November 2026

The CDR is Australia's consumer-directed data sharing regime under Part IVD of the Competition and Consumer Act 2010 and the Competition and Consumer (Consumer Data Right) Rules 2020. The official rollout page lists these sectors.

Phasing for non-bank lenders depends on lender size and the final rules, so confirm current dates on cdr.gov.au before planning. The Australian Competition and Consumer Commission (ACCC) accredits data recipients and runs the CDR Register. The Office of the Australian Information Commissioner (OAIC) regulates the privacy safeguards.

This guide covers the data recipient security side. For the US equivalent of open banking rules, see the CFPB Section 1033 Open Banking Rule Guide.

Who carries which security duty

Schedule 2 Part 1: the five governance steps

The CDR supplementary accreditation guidelines on information security describe five steps with minimum review cycles.

1. Define and implement security governance: a formal information security governance framework, defined roles and an information security policy, reviewed at least every 12 months.
2. Define the boundaries of the CDR data environment: document the people, processes and technology that handle CDR data, usually as a "description of the system" that an auditor reviews. Review at least annually.
3. Have and maintain an information security capability: a capability adapted to your risks that meets the Part 2 controls, reviewed at least annually.
4. Implement a formal controls assessment programme: test control effectiveness through audit or control self-assessment at least annually.
5. Manage and report security incidents: keep response plans, test them at least annually, report notifiable breaches to the OAIC and report incidents to the Australian Cyber Security Centre.

The boundary step drives everything else. A tight CDR data environment, segregated from general corporate systems, shrinks the audit scope. A loose one pulls in every laptop, SaaS tool and support engineer.

Schedule 2 Part 2: the minimum controls

Details that catch applicants out

• Log retention: the guidelines expect controls-related information such as logs of critical events to be kept for six years, with at least 90 days readily accessible. Activity on generic or shared accounts must be monitored and retained.
• Encryption scope: encryption at rest covers file systems, devices, portable media and backups, with secure key management, plus encryption in transit.
• Non-production data: expect to show data masking or exclusion of CDR data from development and test, and data segregation.
• Application control: restricting installation and execution to authorised software is a named control, not an optional extra.

Assurance and attestation cycle

The evidence you submit depends on the accreditation level. These are taken from the CDR supplementary accreditation guidelines on information security (version 5, December 2022); confirm the current version on cdr.gov.au.

Choosing an assurance route

• Already ISO/IEC 27001 certified: check the certificate scope covers the CDR data environment, then budget for the reduced-scope assurance report. Expect supplementary testing of CDR-specific controls such as multi-factor authentication.
• Already producing a SOC 2: an ASAE 3150 or SOC 2 report scoped to the CDR data environment is usually the most direct route. Align the system description with the Schedule 2 boundary.
• Small or early-stage provider: sponsored accreditation, through an unrestricted sponsor, avoids an independent report at application but still requires a senior officer to sign and, later, operating effectiveness evidence.

See How to Read a SOC 2 Report Guide for scoping and reading assurance reports.

Privacy Safeguard 12 and redundant data

Section 56EO of the Competition and Consumer Act requires ADRs and designated gateways to protect CDR data from misuse, interference, loss and unauthorised access, modification or disclosure by taking the steps in Schedule 2. It also requires them to deal with redundant data.

• When data becomes redundant: when it is no longer needed for a permitted purpose, for example after consent expires or accreditation is surrendered or revoked. Exceptions apply where a law, court or tribunal order requires retention, or the data relates to current or anticipated legal or dispute resolution proceedings.
• Delete or de-identify: deletion is required if the consumer elected deletion, if your stated general policy is deletion, or if you cannot de-identify to the required standard. Otherwise you may choose.
• What deletion means: under rule 1.18, delete the data and copies to the extent reasonably practicable, record the deletion and direct any other holder to confirm when done. Data that cannot practically be deleted can be put beyond use under specified conditions.
• Providers: you cannot rely on an outsourced provider to de-identify. Direct it to return or delete the data and any derived data.
• Breach notification: section 56ES applies the notifiable data breaches scheme in Part IIIC of the Privacy Act to ADRs, so eligible breaches likely to cause serious harm go to affected consumers and the Information Commissioner. See the Australian Privacy and Cyber Rules Guide.

The Consumer Data Standards security profile

Schedule 2 covers the recipient's environment. The Consumer Data Standards set the technical security of the data sharing itself. Version 1.36.0 of the standards was current when checked in November 2026.

• Normative basis: the security profile references FAPI 1.0 Baseline and Advanced, mutual TLS (RFC 8705), pushed authorisation requests (RFC 9126) and PKCE (RFC 7636).
• Flow: data holders support only the Authorization Code Flow from 12 May 2025.
• Token lifetime: from 12 May 2025 refresh tokens are issued with an expiry equal to the sharing duration of the consent.
• Transport: data holders and recipients support only BCP 195 recommended ciphers from 17 March 2025.
• Register: the ACCC-run CDR Register issues software statement assertions that identify accredited software products.

See the FAPI 2.0 Security Profile Implementation Guide for the FAPI working group's position on migration.

Where identity fits

The CDR is built on machine identities. Each accredited software product has client credentials, transport certificates and signing keys, and every consumer consent becomes a set of OAuth tokens held in your environment.

• Private keys and certificates: keep mutual TLS and signing keys in an HSM or managed key service inside the CDR data environment, with named custodians and a rotation plan. Treat certificate expiry as an availability risk to data sharing.
• Refresh tokens are long-lived secrets: because refresh token expiry now matches the sharing duration, a stolen token store can give access for the full consent period. Encrypt token stores, restrict service access and alert on token use from unexpected sources. See How to detect use of a stolen OAuth refresh token.
• Service accounts in scope: the Part 2 requirements for unique IDs and restricted administrative privileges apply to pipelines and service accounts as well as people.

How to prepare: a phased approach

1. Scope (month 1): draw the CDR data environment, list every system, person, provider and machine identity that touches CDR data and decide what to segregate.
2. Choose level and route (month 1): unrestricted or sponsored, and which assurance route fits your existing certifications.
3. Gap assessment (months 1 to 2): map current controls to the five Part 1 steps and six Part 2 requirements; prioritise multi-factor authentication on all access, logging retention and non-production data.
4. Remediate (months 2 to 4): roll out changes to a pilot group first; keep a documented rollback for access policy changes, such as an excluded break-glass account stored offline.
5. Contracts (in parallel): update outsourced provider and CDR representative agreements with the Schedule 2 and deletion clauses.
6. Type I assurance and application (months 4 to 5): submit within the three-month freshness window.
7. Operate (ongoing): annual policy review, annual controls assessment and incident test, then alternate attestation and Type II assurance.

Timings are NHI Mgmt Group suggestions for a provider with an existing security programme; adjust to your starting point.

Measuring that it works

• MFA coverage: percentage of human access paths to CDR data protected by multi-factor authentication or equivalent (target 100 per cent).
• Log retention compliance: share of in-scope systems with six-year retention and 90 days online.
• Redundant data backlog: number of expired consents with data not yet deleted or de-identified, and age of the oldest.
• Provider deletion confirmations: percentage of deletion directions to providers confirmed in writing.
• Remediation time: median days to fix critical vulnerabilities in the environment.
• Certificate health: days to expiry of the nearest mutual TLS or signing certificate.

Common failure patterns

• Boundary drift: new analytics or support tools begin reading CDR data without being added to the documented environment.
• MFA only for admins: analysts and support staff reach CDR data through internal tools without multi-factor authentication.
• Test copies of production: CDR data copied into development environments without masking.
• Deletion that stops at your edge: data deleted internally but never directed for deletion at processors and representatives.
• Stale assurance: a report older than three months at application, or a Type II period gap between reports.

Framework mapping

The mapping is ours, for orientation; the CDR Rules and accreditation guidelines are the test.

Practitioner checklist

• Document the CDR data environment boundary and review it at least annually.
• Enforce multi-factor authentication or equivalent on every access path to CDR data.
• Retain logs of critical events for six years with 90 days readily accessible.
• Exclude or mask CDR data in non-production environments.
• Run application allow-listing on systems inside the environment.
• Put Schedule 2 and deletion clauses in every outsourced provider and CDR representative agreement.
• Track expired consents and delete or de-identify redundant data, with deletion records.
• Diary the attestation and Type II assurance cycle and the three-month freshness rule.
• Protect mutual TLS and signing keys and refresh token stores as high-value secrets.
• Check the current Consumer Data Standards version and change dates each quarter.

Standards and references

• Consumer Data Right: IT requirements for data recipients
• Consumer Data Right: Supplementary accreditation guidelines, information security
• OAIC: Privacy Safeguard 12, security of CDR data and destruction or de-identification of redundant CDR data
• OAIC: CDR Privacy Safeguard Guidelines, chapter 12 (PDF)
• Data Standards Body: Consumer Data Standards
• Consumer Data Right: Rollout

Related NHI Mgmt Group resources: CFPB Section 1033 Open Banking Rule Guide · FAPI 2.0 Security Profile Implementation Guide · Australian Privacy and Cyber Rules Guide · Machine-to-Machine OAuth (Client Credentials) Guide. This guide summarises the Consumer Data Right information security obligations and is not legal advice.