The consumer data right (CDR), first mooted by the Australian federal government in 2017, lets consumers compare and switch providers more easily by giving them more control of their personal data. Banking is the first sector to roll out the CDR, with energy and telecommunications to follow.The early experiences are revealing how CSOs may need to adapt security protocols to each sector to secure the flow of data.CSO guides to privacy rules around the worldHow GDPR has inspired a global arms race on privacy regulationsThe EU\u2019s GDPRLaws across Asia-PacificLaws in US statesCalifornia\u2019s CPRALaws in CanadaAustralia's CDR and Australia\u2019s proposed GDPR-inspired privacy lawNew Zealand's Privacy ActThe UAE\u2019s data lawChina\u2019s PIPLFor providers like banks and telcos, the CDR means a new personal data sharing regime, becoming accredited as a data recipient, and being subject to compliance checks\u2014and potential enforcement actions for compliance failures. There are now 12 accredited data recipients, with Finder and SISS Data Services recently joining the list. In the case of banking, the four major banks are the first required to share data, to be followed by most authorised deposit-taking institutions (ADIs).By accrediting providers, the CDR framework is designed to ensure secure data sharing between designated data holders and accredited data recipients. \u201cThe accreditation requirements ensure data recipients have appropriate controls in place to keep data secure,\u201d an Australian Competition and Consumer Commission (ACCC) spokesperson told CSO Australia.Security-driven CDR complianceEach sector\u2014banking, energy, and telecommunications\u2014will have its own CDR implementation, including the application programming interfaces (APIs), which are to be agreed by the stakeholders in the sector and coordinated by the relevant agency\u2014the ACCC or the Commonwealth Treasury.Under the CDR scheme, there are data holders and data recipients, and to be CDR-compliant, providers must use the APIs developed for the sector. In the system design, security considerations have been paramount from the outset. \u201cThe design process was driven by cybersecurity concerns,\u201d said Rob Nicholls, an associate professor of regulation and governance at the University of New South Wales\u2019s Institute for Cyber Security.Each data recipient and data holder is expected to have a sector-specific endpoint security system. Banking, which deals with more sensitive information, may require endpoint security that is greater than in the energy sector, Nicholls said.The endpoint API security is defined in the standards. So with banking, for example, it uses either OAuth 2.0 access tokens or ID tokens. \u201cCompliance with the validation rules in RFC 6749 is also required. That is, well-established standards are incorporated by reference into the CDR standards and these are all provided on a GitHub,\u201d Nicholls said.Having these industry-specific requirements has actually meant that the changes have improved consumer data security. Nicholls noted the original model using the Australian Energy Market Operator (AEMO) gateway did not adequately protect consumer data, so has since been strengthened. \u201cNow, the industry is moving to a more secure peer-to-peer solution. The way these will be secured has not yet been finalised; however, all stakeholders will be involved,\u201d he said.The ACCC is the lead regular for the CDR and, together with the Office of the Australian Information Commissioner (OAIC) and the Data Standards Body (DSB), has been developing and implementing the CDR.The DSB has created the technical standards for the processes of sharing consumer data, while the OAIC is responsible for investigating and enforcing any privacy complaints and managing any privacy-related regulatory activities. Both the ACCC and OAIC will \u201cmonitor and enforce CDR participants\u2019 compliance with the relevant laws, rules, and data standards,\u201d Nicholls said.What security accreditation is requiredThere are high minimum security requirements to comply and be admitted into the CDR system. These include the use of encryption, firewalls, and server hardening for network security, along with multifactor authentication, audit logging, and monitoring, as well as role-based access, unique IDs, and password authentication to protect access to consumer data.Providers must also securely manage data across its life cycle, including data loss prevention, and hold CDR data in nonproduction environments. Vulnerability management\u00a0needs to include security patching and secure coding. Malware protection, at a minimum, will have antimalware, antivirus, web and email content filtering, and application whitelisting. And not overlooking the human element, providers must offer security training and awareness, including the acceptable use of technology and human resource security.To begin accreditation, organisations need to provide evidence they have a secure IT environment. \u201cOnce accredited, data recipients are required to pass a range of tests using a conformance test suite (CTS) to demonstrate their technology solution works correctly in the CDR ecosystem,\u201d the ACCC told CSO Australia.This testing takes place in a sandbox, and participants must pass the CTS before they receive \u2018active\u2019 status and are allowed to be part of the CDR. If providers, particularly smaller operators like fintech firms or online-only \u2018neobanks\u2019, need help to quality, compliance services are available from third parties to help them meet the CDR ecosystem requirements.\u201cAny businesses that fail [the CTS] are not identified by the ACCC, but they don\u2019t become \u2018active\u2019\u201d and thus are not part of the CDR ecosystem. \u201cEven some of the major banks have had to apply more than once,\u201d Nicholls said.CDR compliance may create additional security requirements\u2014and workLocal fintech Frollo helped build and test the CDR ecosystem as part of ACCC trial. Its CIO Tony Thrassis noted the security for accessing the CDR APIs is not in itself too onerous to build\u2014but it\u2019s a different story if things go wrong. \u201cOnce developed, it is very tight, and any issues between the data holder and data recipient become difficult to fix in production,\u201d he said.\u201cWe are seeing the need for a consumer to revoke their consent and re-consent to fix a problem. While maturity of IT systems will reduce this, things can go wrong and networks can have issues,\u201d he said. That may require additional requirements to be brought to bear in existing systems.The second element is the security objectives and controls along with data safeguards. \u201cThese are basically what an authorised ADI would need to pass Australian Prudential Regulation Authority (APRA) CPS234. Not a lot different, but in that regard, for a small fintech, these are quite onerous,\u201d Thrassis said.To manage the CDR security requirements, Thrassis recommends CSOs put in the required controls, safeguards, polices, and procedures. \u201cThese are also not too different to ISO 27001. For organisations not familiar with this level of security and the practices required, it will be quite daunting and not cheap to implement,\u201d he said.As part of the trial it undertook with the ACCC, Frollo performed more than 300 tests. When it went live with the four major banks, there were still plenty of issues. Thrassis said the CTS is at issue, and he considers the CTS not sufficiently robust to say the software developed, either by a data holder or data recipient, will itself be robust.\u201cCTS is not a quality tool, only a compliance tool, and that is a significant difference. We tested the big four banks and have been providing testing services to other banks. No one has got this right first go,\u201d he said.The CTS\u2019s limited scope of compliance is one issue that will affect organisations seeking to be accredited for the CDR.The University of New South Wales\u2019s Nicholls \u00a0\u00a0note that the two major cybersecurity concerns the new regime has addressed stem from two areas : systems and user data.The first is ensure that the underlying systems are not exposed by the CDR process. \u201cThat is, the APIs provide a mechanism by which underlying critical infrastructure is not exposed. The APIs and API security (including authentication and authorisation systems) are part of the cybersecurity design.\u201dThe second part is ensure that consumer data is not exposed, he said.What first steps should CSOs take for CDR implementation?The first steps begin with mapping out the CDR processes that will be needed against what is currently in operation within the organisation. If there isn\u2019t in-house experience, CSOs may need to look for external support from expert security assessment teams familiar with the framework.\u201cIn our case, because we were already working according to 27001 certification, we mapped the extra controls and procedures that were needed and updated staff with the new procedures,\u201d Frollo\u2019s Thrassis said.\u201cWe had to change systems to capture what was needed and restrict access where needed. Then it was building the actual use case into our apps and back end\u2014then lots of testing over six months. This meant understanding standards, developing our customer CDR policy and working out what de-identification meant by the rules. If it couldn\u2019t be passed, due to too much complexity (like de-identification), it had to be avoided,\u201d he added.The University of New South Wales\u2019s Nicholls suggested keeping across the regular government updates, via access to the GitHub and web resources as well as the implementer-specific support portal.While some of the available resources can help a CSO in that CDR effort, the commitment required is major. \u201cAll of this requires significant resources to be allocated by the CSO or CIO. To get those resources, it\u2019s critical that the consumer and security challenges are understood by the board of directors, as well as the C-suite,\u201d Nicholls said. CDR compliance is, after all, a required cost of doing business.And organisations can use it for broader advantage, Nicholls said: \u201cThe introduction of the CDR is being used by a number of businesses as an opportunity for significant transformation. It\u2019s a great reason for dropping legacy and less-secure systems.\u201d Of course, these transformations too will require significant attention from the CSO,\u201d he said.