I’m running into increasing calls from clients and colleagues in the privacy engineering world for a comprehensive and authoritative list of controls. Research and extensive discussion has revealed several uncomfortable truths. First, there is a pronounced lack of privacy specific controls. What one mostly finds in the market are objectives being mislabeled controls. The latter has been most readily occurring with regards to the NIST Privacy Framework’s Core. The Core organizes business outcomes into a hierarchy of 5 Functions, 18 Categories and 100 Subcategories. The 100 subcategories are frequently described as controls, which they are not. Research presented at the PEPR conference last year, by Nandita Narla and myself, found about 30% of articles conflated the two. Thankfully, the IAPP got this correct in their write-up on the framework in 2021 (“Finally, it is good to know that the subcategories are not controls.”).
Second, one finds an abundance of security controls and those security controls being masqueraded as privacy controls. One principle source of this is NIST 800-53. Originally limited to security controls, NIST added an appendix of privacy controls in version 4. The current version, revision 5, integrated those privacy controls throughout the control set. Unfortunately, as illustrated so beautifully in NIST’s baseline controls catalog, the controls are still heavily skewed on the security side.
That NIST baseline controls catalog also illustrates the third truth: the vast majority of “privacy” controls are on the organizational control/program management side. Technical and operational controls are severely deficient both in 800-53 and in other standards and guidance from other organizations.
What is a control?
Now that I’ve use the word control 18 times in three paragraphs, maybe I should define a control. In GDPR parlance, controls equate to measures, as in “technical and organizational measures.” I tend to like one of several NIST definitions, which essentially boils down to some action taken to achieve some objective. Using this definition, its easier to see the conflation between objectives and controls prevalent in the mislabeling of NIST Privacy Framework outcomes. By way of example, one of the outcomes in the framework is “PR.DS-P1: Data-at-rest are protected.” This is the objective. The desire is we, the organization, can state this claim as being true: data-at-rest are protected. But this is not the same as the controls used to achieve that objective, which could be many: maybe the organization encrypts data, maybe they use a role-based access system, maybe they physically isolate data. All of these are controls (i.e. measures) meant to result in the state of data-at-rest being protected.
Types of Controls
Controls can come in three form: technical (e.g. encryption), operational (e.g. process of screening individuals before being given the decryption key) and management (e.g. have a security program in place that governs the business). All of these are going to help achieve the objective, but, hopefully, its painfully obvious that some of these controls are going to have a more direct effect than others. As previously mentioned, the most common type of controls in use, in privacy, tend to be more management/organizational. Those that, in my view, are least effective at actually achieving objectives for “more privacy.”
An analogy might help. I live in Florida and we’re prone to hurricanes. If we want to build a house and reduce the risks the result in damage and injury from hurricanes, we can institute technical, operational or management controls. Technical controls might be a house on stilts (to avoid flood damage) and shutters on the windows (to avoid wind damage). Operational, in the context of operating the house, controls might be the closing of the shutters for an impending hurricane or gathering in the center of the house during the storm. Management controls would include designing houses to be hurricane resistant or creating policies and procedures for when a storm arrives (put water in the bathtub, listen to the radio). Personally, I’d rather have a house with the technical controls, then institute operational controls and lastly have good management controls. Unfortunately, many organizations do this backwards and often, don’t get to the tail end of actually implementing those operational or technical controls that are going actually reduce risks to people.
The focus on management controls also exacerbates that control/objective conflation described above. Policies, processes and procedures are written as policies to achieve objective, or process in achieving objective or procedures to achieve objective. For instance, using the framework example of PR.PS-D1, the objective is “data-at-rest are protected” and the management control is simply “create a policy requiring that data-at-rest are protected.” Hence the confusion between the objective and the management/organizational control, whether the control is merely a requirement to achieve the objective. But at the end of the day, if all you have is a management control, all you’re going to end up with is policies, processes and procedures, and not data-at-rest protected. To fulfill the latter objective you actually have to have controls that protect data, encrypting it, restricting access, etc.
More controls, please.
One of the incidents bringing this to my attention has been the Institute of Operational Privacy Design’s (IOPD) current efforts to develop a privacy design standard. As part of that effort, the IOPD has created a subcommittee of its standards committee to focus on creating a matrix of controls and their effects on privacy risk. The subcommittee had hoped to utilize an existing control catalog, but given the current deficiencies in that market, we’ve turned our attention to coming up with a set of non-security privacy specific technical and operational controls. The initial efforts will be limited, as our main focus is on the broader standard, but hopefully it will bear fruit and its 5th revision, in years hence, will be as comprehensive in privacy controls as 800-53 rev 5 is in the security space. The IOPD welcomes others efforts to contribute.
