Data privacy and security have moved to the forefront of boardroom visibility in 2018. Constant focus on how we manage personally identifiable information (PII) and personal health information (PHI) is moving in a new direction. Not only are we concerned about what we’re storing and processing, but we now need to understand the “where, why, and how.” Data subjects are going to have a lot more control over their data very soon and companies need to understand where data lives and be able to manipulate it and comply with regulatory bodies.
The General Data Protection Regulation (GDPR) and the updated Australian Data Privacy Regulations are some of the most talked about concepts in cybersecurity circles today. The GDPR has been getting a lot of momentum ahead of the enforcement deadline on May 25, 2018, but the Australian parliament has also been doing some due diligence to update its privacy regulations to get a little closer to the EU.
Key Differences Between the EU and Australia
There are some key differences between the GDPR and the Australian Data Privacy Regulations that need clarification with respect to “serious harm,” breach notifications and timeframes, business size applications, and reporting requirements.
The GDPR is the premier data privacy regulation on the books today. It encompasses 11 chapters and 99 articles that deal with everything from data subject rights, differences in controller and processor responsibilities, reporting, working with Data Protection Authorities, and enforcement actions. The Australian Data Privacy Regulations originally stem from the Privacy Act of 1988 (Privacy Act) as well as some added addenda via the Privacy Regulation 2013 and the latest addition for security breach reporting Privacy Amendment (Notifiable Data Breaches) Act 2017.
The first difference in the GDPR and Australian Data Privacy Regulations (Notifiable Data Breach Scheme) is the “real risk of serious harm” qualifier when referring to a data breach. The Privacy Act does not specifically define “serious harm,” but the Office of the Australian Information Commissioner (OAIC) defines this as: “may include serious physical, psychological, emotional, financial, or reputational harm.” While this is helpful, it’s not clear who makes the determination…the data subject or the company that was breached. By contrast the GDPR does not make a distinction; Article 33 simply, and more inclusively, mandates “the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.” This broader coverage removes a lot of ambiguity and simply allows the company to determine the likelihood of risk.
The Australian Data Privacy Regulations (Notifiable Data Breach Scheme) provides for some mandatory minimum limitations for “Australian Government agencies, businesses and not-for profit organisations that have an annual turnover of more than $3 million, private sector health service providers, credit reporting bodies, credit providers, entities that trade in personal information and tax file number (TFN) recipients.” This is very interesting in that it’s not a guarantee that a company with less than $3 million in annual turnover could not succumb to a breach. In fact, security resources may not be prioritized as would be with a higher profile company/agency. The GDPR does not make this distinction; any company or government agency that controls or processes data subject personal identifiable information is subject to the regulation.
Data breach assessments are part of every forensic investigation where a company controls or processes personal identifiable information. The Australian Data Privacy Regulations (Notifiable Data Breach Scheme) provides for a maximum 30 calendar days to assess the evidence of a possible/known data breach and report to the commissioner. Once completed, reporting should be immediate. This contrasts with the GDPR with mandates a mere 72 hours for controller reporting and “without undue delay” for processor reporting. The GDPR does not stipulate an assessment period and uses the “without undue delay” verbiage in concert with “upon becoming aware of a data breach.” Due to the GDPR’s global reach, and potential PII processing by Australian entities, it would stand to reason that the more restrictive reporting deadline will likely be used; especially where high profile companies and/or large losses of data control are concerned.
Australian Data Privacy Regulations (Notifiable Data Breach Scheme) data breach notifications, as stated earlier, should be immediate once an assessment is completed. However, in keeping with the more restrictive GDPR guidelines to notify the relevant Data Protection Authority, it may be prudent to notify the AUS commissioner as soon as possible. “The OAIC expects that once an entity becomes aware of an eligible data breach, it will provide a statement to the Commissioner promptly, unless there are circumstances that reasonably hinder the entity’s ability to do so.” Most companies will want to perform a thorough due diligence and incident response exercise to make sure all legal questions are answered before reporting a data breach incident, but getting information out to the authorities and relevant data subjects reduces the possibility and/or amount of “serious harm” that could potentially occur.
Where does the United States stand?
As the EU and Australia work to solidify data subject privacy rights and regulations, countries like the United States are actually backsliding on these concepts. The United States has a patchwork of laws on the books such as: The Health Insurance Portability and Accountability Act (HIPAA) (42 U.S.C. §1301 et seq.), The HIPAA Omnibus Rule also revised the Security Breach Notification Rule (45 C.F.R. Part 164), The Electronic Communications Privacy Act (18 U.S.C. §2510), Judicial Redress Act, The Financial Services Modernization Act (Gramm-Leach-Bliley Act (GLB)) (15 U.S.C. §§6801-6827), The Federal Trade Commission Act (15 U.S.C. §§41-58) (FTC Act), and the Children’s Online Privacy Protection Act (COPPA) (15 U.S.C. §§6501-6506), among others, but it lacks a cohesive and simplified regulation that would encompass all or most of these. In 2017, however, the U.S. actually reduced privacy regulations when the current administration rolled back inclusion of browsing history and apps usage as sensitive information, requiring opt-in consent from The FCC Privacy Rule.
These kinds of steps will likely be short-lived. As the GDPR, in particular, casts a wide net globally, countries like the U.S. who may not legislate the same level of privacy rights, will be forced to at the corporate level by doing business in a global economy.
The comparison of the GDPR and the Australian Data Privacy Regulations is a great exercise into what different countries are trying to do to answer a desire by individual data subjects to control how their personal information is processed. These regulations will become more and more similar, which is a good outcome since standardization makes the most sense and creates a common framework for citizens of all countries to use to manage their data.
All companies should be aware of major regional data privacy legislation. The GDPR, in particular, will affect virtually everyone and as it seems to be the most restrictive, it makes sense to start thinking that the regulation will apply to them. Data security and privacy professionals need to assess their environments and ensure that if they do business or employ someone from the EU, GDPR will apply to them. There will be a lot of change in the data privacy sphere in 2018 and even countries like the U.S. will end up complying with these frameworks to satisfy business requirements and contractual obligations.
This is a Security Bloggers Network syndicated blog post authored by Brian Rutledge. Read the original post at: Spanning