GDPR, the EU’s data privacy and “right to be forgotten” regulation, has made the stakes of a data breach higher than ever. The GDPR – and parallel regs such as France’s Digital Republic Bill – 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 will keep IT security teams busiest is Article 32, which requires “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational 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. But those aren’t the only laws or regulations that affect IT security teams. There are plenty of others to worry anyone with words like “compliance,” “privacy” and “security” in their job title, from CSOs on down. In our compliance glossary at the end of this article, we list more than a dozen laws and regulations to keep you up at night.
No wonder eSecurity Planet‘s 2019 State of IT Security survey found that compliance is a big driver of IT security spending.
What’s an IT department to do to comply with all these data privacy and security regs?
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.
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).
U.S. financial data must comply with consumer-protection laws like the Electronics Fund Transfer Act (EFTA) and a litany of regulations under the SEC (such as Sarbanes-Oxley), CFTC, FISMA, and numerous other financial regulatory bodies. Meanwhile, data collected online that might potentially involve minors – regardless of industry – may have to comply with certain requirements under the Children’s Online Privacy Protection Act (COPPA).
The same goes for geography. GDPR aside, it has become axiomatic that non-EU countries must comply with current EU regulatory schemes when they have EU users and customers – and the notion was driven home recently (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 same holds true for other international or even interstate situations involving users or customers in jurisdictions other than their own. Where your customers are located matters. In the U.S., for example, 46 states 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 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. Speaking of data compliance at the federal level, data collectors transacting business in the U.S. still must comply with relevant federal laws and regulations on top of any state laws and regulations. The FTC, for example, has an extremely broad regulatory reach (sometimes having overlapping jurisdiction with other agencies) and enforces many laws not mentioned here affecting data practices.
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 Florida attorney Alia Luria, “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, who was a founding member of Akerman’s data law practice before becoming a partner at Losey Law, 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. She noted that “much of InfoSec management falls back on employee training and avoiding employee error – particularly with respect to phishing, spear phishing, and encryption lapses.”
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. One company in particular, Wire Wheel, offers data mapping specific to data-privacy compliance – something that Luria notes can be especially helpful with GDPR requirements on the horizon.
According to Luria, however, 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.
While data protection regulations and laws don’t always go far enough, particularly as people, enterprises, and governments debate the usefulness of regulating the Internet of Things to ensure better cyber security and data privacy, the trend lately has been for such legal frameworks to 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, a Massachusetts hospital recently 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).
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.
And if all this is too much, consider a governance, risk and compliance (GRC) software solution that could do at least some of the work for you. MarketsandMarkets lists Microsoft, Oracle, SAS, SAP, IBM, RSA, BWise, Thomson Reuters, and Wolters Kluwer among the GRC market leaders.
GRC software is a $22 billion market that is expected to double over the next five years, with risk management software leading the way.
Data loss prevention (DLP) is another import compliance tool, and has become one of the top IT security buying priorities in recent years.
Here are some of the major laws and regulations that affect information security. We’ve already spent significant time on GDPR, so we’ll focus on other statutes here.
Sarbanes-Oxley Act: The 2002 law was a response to corporate fraud and is designed to improve corporate disclosures and transparency. For IT and security folks, that means information control and integrity, business continuity and disaster recovery, and protecting information (and financial performance) from the impact of a data breach or loss.
Payment Card Industry Data Security Standard (PCI DSS): That name pretty much says it all. Anyone taking credit card payments or handling credit card data faces requirements for access control, firewalls, encryption, and software and hardware security, plus other issues such as penetration testing, skimming, phishing, risk assessment, and data breach response.
Gramm-Leach-Bliley Act: This 1999 law requires financial service providers to protect consumer financial information.
Fair and Accurate Credit Transaction Act (FACTA): A 2003 amendment to the Fair Credit Reporting Act requires proper handling and disposal of consumer credit reports and other controls to prevent identity theft.
Federal Rules of Civil Procedure: The FRCP has a number of sections (Chapter Five, Rules 26-37) that require that electronically stored information be preserved and untampered with so it can be produced in civil lawsuits (eDiscovery).
Industry-specific laws and regulations affecting IT security:
North American Electric Reliability Corp: NERC sets standards for the physical and cyber security of electric utilities.
21 CFR Part 11: This section of the Code of Federal Regulations requires secure and auditable systems for electronic records for FDA-regulated industries.
Health Insurance Portability and Accountability Act: HIPAA might be the one information compliance law that everyone has heard of. The 1996 law mandated the security and privacy of personal health information. The Health Information Technology for Economic and Clinical Health Act (HITECH Act) of 2009 created additional requirements for the security and privacy of patient data.
Patient Safety and Quality Improvement Act (PSQA): This 2009 medical error reporting law requires that patient data be protected.
Chemical Facility Anti-Terrorism Standards: These 2007 regulations mandate security for high-risk chemical facilities.
In addition to federal laws and regulations, a number of states have imposed data privacy and security requirements covering state residents, such as the new California Consumer Privacy Act, the Massachusetts Data Protection Law (201 CMR 17), and the Nevada Personal Information Data Privacy Encryption Law (NRS 603A). There are also many international laws in countries such as Canada and Mexico, along with the EU’s Data Protection Directive, Privacy Shield, Directive on Security of Network and Information Systems, and now the GDPR.
Joe Stanganelli, principal of Beacon Hill Law, is a Boston-based attorney, corporate-communications and data-privacy consultant, writer, and speaker. Follow him on Twitter at @JoeStanganelli.
(Disclaimer: This article is provided for informational, educational 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.)