With increasing frequency, the Federal Trade Commission (FTC) has invoked its authority under the language of Section 5—"unfair or deceptive acts"—to bring complaints against companies whose privacy and/or data security (P/DS) practices have allegedly harmed or could harm consumers. But to date, the FTC has not conducted rulemaking to specify the P/DS practices that are required to avoid liability. Instead, the FTC has declared that companies should consult "industry standards" as a source to develop P/DS best practices and has gone so far to say it "will view adherence to such codes favorably in connection with its law enforcement work." But has the FTC kept this promise?
Most of the companies facing Section 5 P/DS charges have settled with the FTC through consent orders. Critics bristle that these consent orders provide little guidance for companies to understand what their P/DS practices should be. But, in a recent study, IAPP Westin Research Fellow Patricia Bailin, CIPP/US, combed through 47 these consent orders along with the original complaints to show that it is, in fact, possible to infer what the FTC expects "reasonable" P/DS practices should look like. Here, I compared those inferred practices with some of the industry standards endorsed by the FTC, noting coincidence or uncovering gaps.
The good news, but also a challenge for companies and for this study, is that numerous industry groups have thoughtfully developed and now generously share standards for P/DS best practices. Some, such as "Security and Privacy—Made Simpler: Manageable Guidelines to help You Protect Your Customers’ Security & Privacy from Identity Theft & Fraud," created by the Better Business Bureau, apply to general business activities, while others, such as the PCI Data Security Standard, are directed to specific forms of the processing of sensitive personal information. There are also numerous, more informal sources for guidance on data security such as the recently released "Small Business Guide to Identity Theft Prevention and Data Security" by TechInsurance. Few of the biggest companies and certainly no small business owners could read, act on and continually react to updates to this full set of standards. Therefore, the approach used here was to rely on a small subset of the standards that have been endorsed by the FTC itself. In September, Federal Trade Commissioner Julie Brill described the 2014 "Framework for Improving Critical Infrastructure Cybersecurity," prepared by the National Institute of Standards and Technology (NIST), as "fully consistent with the FTC’s enforcement framework." The framework claims to enable "organizations regardless of size, degree of cybersecurity risk or cybersecurity sophistication to apply the principles and best practices of risk management to improving the security and resilience of critical infrastructure." Under the topic of "Data Security," the 2014 framework specifically references five sources for industry standards:
- The Council on CyberSecurity's Top 20 Critical Security Controls (CCS CSC)
- The International Society for Automation (ISA) “Security for Industrial Automation and Control Systems: Establishing an Industrial Automation and Control Systems Security Program” (ANSI/ISA–62443-2-1 (99.02.01)–2009))
- ISA's “Security for industrial automation and control systems Part 3-3: System security requirements and security levels” (ANSI/ISA-62443-3-3 (99.03.03)-2013)
- The International Organization for Standardization (ISO)'s “Information technology--Security techniques--Information security management systems—Requirements” (ISO/IEC 27001:2013)
- The NIST's “Security and Privacy Controls for Federal Information Systems and Organizations” (NIST SP 800-53 Rev.4)
Here, the suggested standards contained in these five sources were compared to 72 expected "reasonable" practices, as inferred from the FTC's complaints and consent orders. Note that because the framework is focused on data security and not privacy, the comparison was restricted to the inferred reasonable practices that related to data security only, i.e., four practices that were described under the heading of "Privacy" were not considered. Also note that this comparison was not intended to yield a definitive reference guaranteeing Section 5 compliance. An effort was made to scour the standards in their entirety, but even if no standard was located within a given reference document to match a particular inferred best practice, it does not mean that it was not inadvertently missed. Similarly, within a given reference document there may be other sections that are on point with respect to a particular inferred best practice but that are not listed in the summary table.
The NIST SP 800-53 Rev. 4 came closest to covering the 72 reasonable data security practices expected by the FTC, as inferred from the FTC's complaints. Sixty-six of the 72 expected reasonable practices were recommended in this NIST report. In many instances, the "match" between the expected practice and recommended standard was nearly perfect. For example, the FTC expects companies to use strong user IDs and passwords, and NIST recommends "that authenticators have sufficient strength of mechanism for their intended use." In other instances, the similarity between the expected reasonable practice and the recommended standard was less precise. For example, the FTC expects companies to prohibit storage of administrative passwords in plain text in cookies, whereas NIST recommends that a company store and transmit “only cryptographically-protected passwords” but makes no explicit mention of cookies.
The second-best source for industry standards was the CCS CSC, which covered 48 of the 72 FTC's expected reasonable data security practices. This is not surprising given that the Council on CyberSecurity describes “actions defined by the (CCS CSC as) a subset of the comprehensive catalog defined by the National Institute of Standards and Technology (NIST) SP 800-53." The language used to describe the Critical Security Controls was considerably less technical and often provided more specific guidance than that in NIST SP 800-53 Rev. 4. For example, the CCS CSC suggests "that all non-administrator accounts have strong passwords" and further explains that passwords should be "complex and contain letters, numbers, and special characters intermixed, and (have) no dictionary words present."
The ISA 2009, ISO 27001 and ISA 2013 performed similarly to each other, covering just 28, 24 and 21 of the expected reasonable data security practices, respectively. This in no way implies that these standards are incomplete but instead reflects the sharper subject focus of these documents or, conversely, their intentional generality. The ISA 2009 and ISA 2013 are not overarching reference documents for "system security compliance" like, for example, the ISA 62443-1-3, but instead are more specialized to describe "processes and procedures" and "cybersecurity in complex and dangerous manufacturing and processing applications," respectively. On the other hand, the "requirements set out in ISO/IEC 27001:2013 are generic and are intended to be applicable to all organizations, regardless of type, size or nature." So, for example, ISO 27001 states that users "shall be required to follow the organization’s practices in the use of secret authentication information" but does not provide guidance on what a strong password looks like. Both the ISO and the ISA documents considered are only single representatives of the abundant resources they offer, and it is very likely that most of the inferred reasonable practices could be located in other documents available from these organizations.
Based on the comparison performed here, it seems that the reasonable data security practices that the FTC expects are mostly contained within a short list of industry standards recommended by the FTC. It is therefore legitimate to conclude that companies that follow these industry standards could avoid Section 5 liability as the FTC has promised. But, companies should embrace this conclusion with a healthy level of caution. First, no company could possibly execute every industry standard in the 400-plus-page NIST 800-53, even with a full IT department and certainly not without one. The question then remains as to how many industry standards will suffice as "reasonable" data security. As privacy scholars have noted, we are only able to draw inferences based on the P/DS practices that the FTC has deliberated but have little information on "whether other practices that have not yet been addressed by the FTC are 'reasonable' or not." Hence, "we don't know how high the reasonableness bar is set."
Next, the FTC has assured companies that it will apply a "flexible standard of reasonable security" and that "reasonable depends on the nature and size of your business, the types of information you have, the security tools available to you based on your resources, and the risks you are likely to face." But to date, its complaints have been directed at large companies. Small businesses are justified to be leery of basing their data security practices on the FTC's complaints against significantly dissimilar defendants. Third, there is no bright line between what constitutes a "privacy practice" and what constitutes a "data security" practice. For example, requiring a company to destroy sensitive personal information when there is no longer a business need supports both. But four of the five standards analyzed here are confined to data security issues; only the NIST 800-53 Rev. 4 includes a section on "Privacy Controls." Therefore, to avoid data security violations, companies may still also need to consult privacy standards.
Finally, the FTC's flexible standard of liability is both a source of comfort and of anxiety for all companies. All five sets of industry standards explored in this study have been more or less endorsed by the FTC, but considering each in isolation, only the NIST 800-53 Rev. 4 appears to be adequate to satisfy the data security that the FTC expects. Does this mean that companies should focus compliance with the NIST 800-53 Rev. 4 only, or would adherence to the Top 20 Critical Security Controls be "reasonable?" These two documents differ substantially in their ease of use. Both are available online in a hyperlinked form. But, the CSS CSC provides nontechnical explanatory text for each control, breaks them down into explicit commands, categorizes the commands—such as "quick win" or "advanced"—describes effectiveness tests and includes descriptive diagrams. This standard would be better aligned with the level of technical expertise of a small business or even a large business that is simply collecting and processing personal information in the course of regularly conducted business activities.
The industry standards for data security are more than just a reference. Indeed, the commission has threatened to take action against companies for "failure to abide by self-regulatory programs they join." And according to the FTC, even if "you don’t say anything specific about what you do with users’ information … Under the law, you still have to take reasonable steps to keep sensitive data secure." Based on the comparison made here, the industry standards are being used by the FTC to decide what these "reasonable steps" look like. The five industry standards examined here are a good starting point. But, even the lengthy NIST 800-53 Rev. 4 refers readers to the NIST SP 800-118 for additional guidance on "password management." Also, the FTC has filed comments with other agencies to explain its enforcement and provide information on its policy and education work and "has hosted public workshops, issued reports and has frequently testified before Congress on business practices and technologies affecting the privacy and security of consumer data." These activities provide additional P/DS guidance.
With each new FTC enforcement action (see Bayview Solutions 5.7.1!), we enhance our functional understanding of what reasonable data security is, and this knowledge benefits both the companies that P/DS professionals support and the consumers that the FTC is authorized to protect.
If you want to comment on this post, you need to login.