The NIST Privacy Framework: Helping the Legal Team Talk with the Tech Team

The draft Privacy Framework recently released by the National Institute of Standards and Technology is a conversation starter. 

Could this voluntary framework help avoid missed connections in privacy, forestalling the next data breach or privacy scandal by baking data protection into new products from conception? Is “true privacy engineering” possible? After attending a recent stakeholder workshop on the framework, I am hopeful that it could be. 

Officially, it is a voluntary tool to help organizations better identify, assess, manage, and communicate about privacy risks so that individuals can enjoy the benefits of innovative technologies with greater confidence and trust. Unofficially, NIST officials view themselves as translators, creating a new language to foster critical conversations between lawyers, developers, the cybersecurity team and the c-suite to enable true privacy engineering. 

For many years, privacy has been the domain of the legal team, driven by the latest legislation and compliance requirements. Often, data protection requirements have been prescribed by lawyers for engineers. Many developers have viewed privacy requirements as presenting them with a binary choice. Offer a product or capability or forego the opportunity. Conversations have been limited, in part due to barriers in language and understanding. 

NIST aims to change that. 

Sponsorships Available

Sponsorships Available

Sponsorships Available

It has modeled the Privacy Framework on its successful Cybersecurity Framework. To develop a shared lexicon to assess privacy risk, they have imported the structure of the CSF, and importantly, some, but not all, of the language of information security professionals.  

Much like the CSF, the Privacy Framework is organized around the functions an organization must undertake to manage privacy risk, the profile of the organization using it, and a tiered implementation structure. Organizations are encouraged to move to a higher “tier” or more sophisticated risk management program based on the privacy risk their data processing operations create. 

The “core” outlined in each framework is, as the name implies, the heart of the matter. The Privacy Framework core is divided into five functions: identify, protect, control, inform and respond. Three of these (identify, protect and respond) are mirrored in the Cybersecurity Framework, while the other two differ. The functions are broken down into categories, such as inventory and mapping, supply chain risk management and redress. At this level, many similarities still exist between the two frameworks. 

Greater divergence is evident at the subcategory level, which, in the Privacy Framework, presents controls or capabilities organizations should consider adopting to address privacy risk. These range from “data elements can be accessed for deletion” to “records of data disclosures are maintained and can be shared.” NIST has helpfully mapped the CSF to the Privacy Framework core to assist organizations in identifying similarities and differences and perhaps eventually developing a streamlined risk management process for both. 

At NIST’s recent workshop, participants focused on what they indicated was most useful: the subcategories. Participants from both legal and tech teams commented that, at this level of detail, the proposed capabilities or controls aligned well with their own organizations’ privacy programs. The engineers seemed more comfortable with the framework’s language, though. The notion of “controls” was familiar to them, but for the lawyers, it evoked the concept of consent. Numerous participants wondered if the adaption of cybersecurity “threats” and “vulnerabilities” to “problematic data actions,” chosen to avoid the loaded notion of harms, appropriately articulated privacy risk. 

The language barrier has not yet been overcome, but the framework got everyone talking. 

Stakeholders also signaled differences in priorities. Some suggested that the governance elements should be elevated. Currently, the subcategory “legal, regulatory, and contractual requirements regarding privacy are understood and managed” is one out of more than 100. While NIST indicated that the framework core is not meant to be read linearly, some stakeholders thought this element deserved greater weight. 

Perhaps the framework could be mapped to the fair information practice principles, the EU General Data Protection Regulation, or the California Consumer Privacy Act, since such principles and laws drive compliance dollars and focus companies’ attention. Others thought differently, noting that engineers cannot implement the FIPPs and that the framework’s value will be in its ability to transcend legal requirements, making it “future proof.” Others suggested that NIST incorporate metrics so that organizations could avoid an imbalanced comparison between individuals’ privacy risk and organizations’ benefits. NIST welcomed all feedback and asked for more, announcing that they will host the next stakeholder workshop in July. 

The framework draft is just that, a draft, which will evolve as NIST’s consultation process proceeds. But, it has already succeeded in part. In concluding remarks at the recent workshop, Peter Swire, a professor at Georgia Tech and senior counsel at Alston and Bird, defined success as a privacy framework that makes sense to both lawyers and engineers to enable a two-way conversation. 

NIST’s process has jumpstarted those conversations.