Regulatory compliance and data privacy issues have long been an IT security nightmare. And since the EU’s General Data Protection Regulation (GDPR) took effect May 25, 2018, IT compliance issues have been at the forefront of corporate concerns.
GDPR, the EU’s flagship data privacy and “right to be forgotten” regulation, has made the stakes of a data breach higher than ever. GDPR (among other legal requirements in the EU and elsewhere) can expose multinational organizations to hefty financial penalties, additional rules for disclosing data breaches, and increased scrutiny of the adequacy of their data security.
The GDPR provision that may keep IT security teams busiest is Article 32, which requires “a process for regularly testing, assessing and evaluating the effectiveness of technical and organizational measures for ensuring the security of the processing” of personal data.
GDPR-style data privacy laws came to the U.S. with the California Consumer Privacy Act (CCPA) effective Jan. 1, 2020. Some other states have since enacted their own privacy laws, beginning with Virginia’s Consumer Data Protection Act (CDPA). But those aren’t the only laws or regulations that affect IT security teams. There are plenty of others to worry anyone with job titles that include terms like “compliance,” “privacy,” and “security,” from CSOs on down.
See the Top Governance, Risk and Compliance (GRC) Tools
PIPL Raises the Bar – And the Stakes
It once might have been said that perfect compliance with GDPR generally meant being mostly compliant with most privacy laws if applied globally. Today, that isn’t quite the case. Several new privacy laws and regulations have been promulgated since GDPR took effect – some broader or more sweeping in some areas than GDPR is.
China’s Personal Information Protection Law (PIPL), in particular, has raised part of the bar. Much of PIPL echoes GDPR, but as applied to data-handling activities within China’s borders and handling data of natural persons within China’s borders. Some areas of PIPL, however, go beyond GDPR standards. For instance, the list of data rights enjoyed by individuals differs slightly between the two frameworks. Relatedly, PIPL outlines some categories of sensitive information that do not receive additional protection under GDPR. Also unlike with GDPR, handling of this kind of sensitive data under PIPL requires express consent.
The penalties facing PIPL can also be far more severe than those under GDPR – which was already notorious for steep maximum penalties.
- Under PIPL, Chinese privacy officials can seize any and all “unlawful income” and compel the suspension or termination of any applications in violation.
- A PIPL violator refusing to come into compliance after a correction order may face an additional fine of up to ¥1 million.
- “Grave” violations of PIPL carry a fine of up to ¥50 million or 5% of the violator’s annual revenue. The violator may also be suspended or prohibited from doing business in China altogether.
- PIPL imposes personal liability on “directly responsible” company employees, who face fines between ¥10,000 and ¥100,000. For “grave” violations, such employees face fines between ¥100,000 and ¥1,000,000 – and may be prohibited from holding supervisory/management positions or a personal-information protection officer job.
- PIPL also grants victims of PIPL violations the right to sue personal-information handlers directly for damages. In such cases, the defendant personal-information handlers bear the burden of proof.
So what’s an IT department to do facing all of these legal requirements, with so much at stake?
Type of Data Matters More Than Type of Enterprise
The first thing to understand is that, when determining which statutes and regulations apply to you, the kind of organization you are matters less than the kinds of data you are handling, although there is often an overlap between the two.
Healthcare Data Privacy Laws
Health data and patient data in the U.S. are subject to laws such as the Health Insurance Portability and Accountability Act (HIPAA) and the Health Information Technology for Economic and Clinical Health Act (the HITECH Act), as well as regulations such as the Clinical Laboratory Improvements Amendments (CLIA).
Financial Data Protection Laws
U.S. financial data must comply with consumer-protection laws such as the Electronics Fund Transfer Act (EFTA) and a litany of regulations enforced by the SEC (such as Sarbanes-Oxley), CFTC, FISMA, and other financial regulatory bodies. The FTC, for example, has an extremely broad regulatory reach (sometimes having overlapping jurisdiction with other agencies) and enforces many laws not mentioned here that affect data practices. One such example is the Children’s Online Privacy Protection Act (COPPA) – which places requirements on anyone collecting data online, regardless of industry, that might potentially involve minors.
Also, health and financial data, among other categories of more sensitive data, is often treated as a more protected category of data under general data-privacy laws – subject to stricter protection requirements.
Geography matters just as much as data type. GDPR aside, it has become axiomatic that organizations in non-EU countries must comply with current EU regulatory schemes when they have EU users and customers – and the notion was driven home a few years ago (albeit in a context other than that of data protection) when the EU fined Google a record €2.4 billion (then the equivalent of about $2.7 billion USD) for antitrust violations.
The rule holds generally, too. If the data is being handled in a given jurisdiction and/or the data subject is located within or otherwise protected by a given jurisdiction, that jurisdiction’s data-protection laws generally apply – regardless of where a company is headquartered. In the U.S., for example, all 50 states (along with the District of Columbia, Puerto Rico, the U.S. Virgin Islands, and Guam) have their own data breach notification laws (and each such state, accordingly, has its very own definition of such basic terms as “data” and “breach”) – with Massachusetts’ and California’s respective breach-notification schemes viewed as among the strictest.
States also differ on other data privacy and IT security compliance laws. The states of Nevada, Minnesota and Washington stand out for having their own laws on the books creating liability in certain situations for businesses that handle credit card transactions and are not in compliance with PCI-DSS.
Other industry standards too can have the force of “pseudo-law” – notably, the NIST Cybersecurity Framework, which federal regulators often apply to financial-services firms and government contractors.
Thus, it can be difficult for even small enterprises to keep up with information security and data privacy compliance. The challenge becomes even greater for large enterprises – particularly when employees (or even entire departments) go rogue with Shadow IT implementations. This is where compliance software can come in handy for keeping track of, maintaining, and enforcing IT security and data privacy policies.
Automating IT Compliance with Security Compliance Tools
Data itself can be automatically managed, and employee compliance and training can be managed to improve data security and data storage security. Just as there are data storage solutions that can maximize the efficiency of where and how data is stored, so too are there solutions that, according to Alia Luria, managing partner at LNK Law PLLC, “can analyze your disks and determine where data is stored so it can be classified – and either deleted in accordance with existing policies, secured if not adequately secured, or tracked.”
Sometimes, however, information security, data privacy, and IT compliance overall are people problems more than they are pure data problems. Luria therefore urges enterprises who want to better ensure their information security to “consider a policy-management tool that tracks employee training and compliance.”
“There are a lot of options out there for training modules that track and audit employee participation, testing, and auditing that employees have reviewed policies [that may] apply to information security policies,” Luria told eSecurity Planet. “[M]uch of InfoSec management falls back on employee training and avoiding employee error – particularly with respect to phishing, spear phishing, and encryption lapses.”
See the Best Cybersecurity Awareness Training for Employees
Luria said the increasingly common practice in highly regulated industries (such as financial services and healthcare) is to create and implement their own customized database solutions and tie them to their particularized IT compliance requirements. Some vendors offer data mapping specific to data privacy compliance – something that Luria notes can be especially helpful with global compliance.
According to Luria, while there are a great many tools available to aid in pure information security, relatively few are available for data governance or connected to compliance frameworks. “[A] lot of companies [still] do the compliance auditing and analysis piece manually,” said Luria.
The result is arguably a perverse jumble of priorities. Employees are often compelled to jump through automated, bureaucratic hoops when actual security is at stake – with manual human interference and education coming into play only when there is a compliance box to be checked off. The difference underscores the fact that information security and IT compliance are different things.
Security, Privacy and Compliance Can Conflict
Data security, data privacy, and data compliance are all very much related – with similar goals in mind. The three, however, are not the same thing – and sometimes they even conflict.
While data protection regulations and laws don’t always go far enough, legal frameworks sometimes go too far. Compliance can sometimes hinder real security and real data privacy. This often happens when legislators and regulators get too carried away.
The Fair and Accurate Credit Transactions Act of 2003 (FACTA), for instance, so broadly defines what a “creditor” is that businesses that have no need for collecting various bits of PII (personally identifiable information) are compelled to collect and keep it. The law, therefore, directly flies in the face of the FTC’s oft-given guidance on data privacy and information security best practices that businesses should only collect information that they need and only keep information for as long as they need it.
For another example, as security expert Bruce Schneier has pointed out, the Digital Millennium Copyright Act (DMCA) makes it unlawful for someone to bypass security mechanisms protecting copyrighted work, thus making legitimate security research on devices containing copyrighted software legally actionable.
And when the blame is not on government overreach, it usually lies at the doorstep of poorly thought out check-the-box compliance measures – such as enhanced visibility of or easier access to PII. In one example several years ago, a Massachusetts hospital discontinued its practice of clearly labeling large trash receptacles dedicated to the disposal of documents containing HIPAA-protected patient PII. While the practice may have enhanced actual compliance, it also advertised to identity thieves precisely where to look.
A more high-tech (and notorious) example of IT compliance potentially hindering security occurred after New Zealand enacted the Telecommunications (Interception Capability and Security) Act of 2013 (TICSA). The resulting legal framework effectively drove researchers to pull a Google-sponsored SDN testbed out of the country and move it to Australia. This was because TICSA mandates that network operators notify the government of network changes – a task that is at best impractical when it comes to SDN and NFV because of the near-constant network changes that naturally result from network virtualization. New Zealand has thereby made itself a jurisdiction where virtualized network infrastructures – which can offer many security benefits – appear to be of complicated if not downright dubious legal nature.
The conflicting security-compliance relationship can also work the other way around; security can complicate compliance when enhanced security measures interfere with levels of accessibility required under certain laws and regulations (HIPAA, for example). After all, security and accessibility are exact opposites of each other; perfect security, by definition, means zero accessibility, and vice versa.
As Anthem was being roundly criticized for failing to encrypt data at rest after discovery of the health insurance carrier’s 2014 data breach, for example, healthcare journalist Fred Trotter pointed out that such encryption could actually make HIPAA compliance more difficult by hindering legitimate accessibility. Trotter further argued that encryption of Anthem’s data at rest would have offered only minimal security benefits and would not have prevented the hack. The counterpoint to this anti-encryption position, however, would be that larger and more nuanced security benefits – such as an enhanced organizational security culture – would result from broader encryption deployment and stricter encryption policies, and these benefits could potentially have helped prevent or mitigate a successful hack (similar to the way seatbelt mandates have been found to reduce traffic fatalities).
Compliance Comes Down to Risk Management
Examples like these highlight the balance of interests that must necessarily take place when making decisions about how to protect data. Data security, data privacy, and data compliance all co-exist as separate yet equally important circles on a Venn diagram that is best titled “Data Stewardship” – which itself sits on a balance scale opposite the interests of data accessibility. Consequently, these are all elements of risk management. The enterprise that treats these disparate elements as such, using a cost- or risk-benefit analysis, will have the fewest data-related headaches – compliance, security, privacy, or otherwise.
(Disclaimer: This article is provided for informational, educational/academic, and/or entertainment purposes only. Neither this nor other articles here constitute legal advice or the creation, implication or confirmation of an attorney-client relationship. For actual legal advice, personally consult with an attorney licensed to practice in your jurisdiction.)