Introduction
Privacy engineering, as a discrete discipline or field of inquiry and innovation, may be defined as using engineering principles and processes to build controls and measures into processes, systems, components, and products that enable the authorized, fair, and legitimate processing of personal information. One privacy leader defines it as the “inclusion and implementation of privacy requirements as part of systems engineering.”
In the book I wrote with my daughter, Michelle Finneran Dennedy, we define a Privacy Engineering Methodology that includes Use Cases, Agile techniques, and data and UML modeling. Let’s define privacy.
Privacy
There are many definitions of privacy. A simple definition is that privacy may be considered as the authorized, fair, and legitimate processing of personal information. Authorized processing of personal information only happens where the person or organization is authenticated, and the processing is authorized in that the person acting has appropriate privilege for that processing. The criteria for “fair” can be developed using laws, regulations, and enterprise privacy policies, based, in part, on Privacy Frameworks such as Fair Information Processing Principles (FIPPs), Generally Accepted Privacy Principles (GAPP), Privacy by Design (PbD) and other privacy frameworks. We will discuss some privacy requirements developed from these frameworks below.
Processing personal information includes, but is not limited to collection, storage, use, sharing, organization, display, recording, alignment, combination, disclosure by transmission, copying, consultation, erasure, destruction, alteration of personally identifiable information and any data related to it.
Personal Information
Personal Information (PI) is the asset protected by privacy rules, processes, and technologies. Traditionally, personal information has been defined as information that directly identifies or, in combination with other data, allows for the identification of an individual (i.e., basic examples are an individual’s name, address, phone #, national or tax id) or any otherwise-anonymous information that when combined can only be a single person. Largely due to the explosion of the Internet, mobile computing, and telecommunications technology, the definition of personal information is evolving to include unique device and network identifiers such as the universally unique identifier (UUID) and IP addresses. The Federal Trade Commission (FTC) effectively redefined PI to include certain types of what used to be considered machine data such as device ID and IP addresses when it stated in its 2010 report, Protecting Consumer Privacy in an Era of Rapid Change, that:
“…the proposed framework is not limited to those who collect personally identifiable information (“PII”). Rather, it applies to those commercial entities that collect data that can be reasonably linked to a specific consumer, computer, or other device.2
Data Governance
Data governance, as most of you know, is a strategic, “top-down” program for data management in which an organization’s leadership communicates the core value, including privacy, of data quality and integrity to stakeholders. It includes the development and enforcement of standards and procedures. It requires broad understanding of data entrusted to the organization, the value and use of data, upstream and downstream stakeholders, systems, and processes for all decisions and issue-resolution. To be effective, data governance requires data stewardship and data stewards. Also, to be effective, it requires executive sponsorship and support. Stewardship is not ownership. A steward is a custodian responsible for managing something that belongs to someone else. Data stewardship is the managing of information on behalf of the “owners” of the data. The data steward is in effect “the feet on the ground” ensuring the date governance and privacy standards are adhered to and evolve as necessary.
An effective data governance program requires that:
- Data is created, recorded, and distributed in compliance with standards.
- An established metadata gathering process clearly describes requirements and characteristics of the data to be maintained.
- There be a metric-driven adherence of all data definition standards
- There be a feedback/notification system to identify inadequacies in the data
- There be a data quality assurance process that monitors the integrity of information within the system.
- There be a data management structure that includes data stewardship, a data governance panel, and an executive layer.
There are two data steward roles: Data Collection Stewards and Data Usage Stewards.
Data Governance and Privacy
Data Collection Stewards, Data Use Stewards, Data Architects / Modelers / Designers, and System Developers will work with the enterprise privacy team, including the Privacy Engineer to add privacy rules metadata to each privacy-oriented data attribute. We will discuss Privacy Requirements below. They will also be responsible for determining data governance requirements, including:
- Data Standards Compliance
- Use of Metadata Documentation
- Metric-driven Quality Assurance
- Data Management Structure
Data Collection Stewards are also responsible for determining the need for encryption and the evaluation of the privacy sensitivity of each data attribute. The collection stewards will determine whether each is a:
- Non-privacy attribute
- Potential PI attribute
- PI attribute
- Sensitive PI attribute
- Serious PI attribute
Data Use Stewards evaluate:
- User experience requirements
- Screen and Report Quality
- Screen and Report Business Content
- Screen and Report Presentation / Aesthetics
- Screen and Report Design
The Data Use Stewards, working with the Privacy Team and the Privacy Engineers, will also review all outputs to certify whether privacy requirements have been satisfied.
Privacy Requirements
The data stewards, data architects, data administrators, and data modelers should review and use the following privacy requirements throughout the system life cycle.
The following provides some privacy requirements to be considered:
- Purpose: Collect and process for purposes that are relevant to the services being provided. PI must not be collected or used for purposes that are materially different from the original purpose for which the data was provided.
- Notice: System creators, owners, and fiduciaries must explain to users how their personal information will be used, collected, protected, retained, kept accurate, accessed, corrected, or otherwise processed before any processing occurs.
- Choice/Consent: Data subjects must consent to the collection and use of their personal information.
- Transfer: Data should not be transferred to third parties for their own use without the data subject’s permission.
- Access, Correction, Deletion: Data subjects must have a means of accessing the personal information that has been collected about them. They also are entitled to delete or amend false or inaccurate data.
- Security: Use appropriate technical, logical, and administrative measures to ensure only authorized access and use of data.
- Minimization: Collect and process the minimum necessary data to achieve the identified, legitimate intended purposes. The minimization principle is closely related to the purpose limitation requirement where the only the necessary PI is collected and processed to achieve a legitimate purpose.
- Proportionality: Data collection should be legitimately proportional to need, purpose, and sensitivity of data. This requirement can be one-step further abstracted to connect that data to quality and value.
- Retention: Retain data only if it is required.
- Act Responsibly: Put a privacy program in place.
Organizing for Privacy-Oriented Data Governance
In our book, we have 2 chapters concerning organizational aspects of privacy management and privacy engineering. In this section, we will discuss aligning the privacy management structure with the data governance structure. An example data governance structure, based on a structure that we helped a few of our clients establish, is shown in graphic below.
The structure is headed by a steering committee, comprised of senior managers from key domains across the organization, which sets data governance direction and strategy. The Chief Privacy Officer should be a member of this committee. The steering committee resolves major issues and authorizes solutions —even if those decisions impact organizational structure or project costs and timelines.
The next level of the data governance structure consists of data governors and governance managers, who define overarching data governance requirements based on the strategy set by the steering committee. The privacy team and privacy engineer(s) support the governors.
Below this level are the data stewards and data architects responsible for the day-to-day operational data governance activities required for specific projects. They ensure that the way information is used in these projects is aligned with the overall strategy set by the steering committee. The privacy function is represented at each level of this structure, either directly by one of the CPO’s delegates or by ensuring that the person performing each role has adequate knowledge of privacy strategy and principles.
Key phases required to create this governance structure include:
- Gain executive sponsorship.
- Define data governance and privacy policies.
- Select data governors.
- Identify data stewards – The key data management tasks performed
by data stewards include:
Creating standard definitions for data. - Establishing the authority to create, read, update and delete data.
- Ensuring consistent and appropriate usage of data, including privacy rules.
- Providing subject matter expertise to help resolve data and privacy issues.
Conclusion
The key aspect of Privacy Engineering is that privacy and privacy requirements need to be considered throughout the life of the Personal Information (PI).
The privacy team, the data architect / designers / modeler, the privacy engineers, and the data stewards need to work together throughout the privacy life cycle to develop privacy policies and then to develop and implement privacy and data management procedures, standards, guidelines, best practices, and rules. Our Privacy Manifesto states that:
- Data about people is valuable in and of itself.
- A Privacy Engineer needs more than just technical skills to protect and extend the value of data.
- A privacy engineer draws from artistic creativity and expression to innovate.
- A privacy engineer learns from, but disregards, the failures of the past.
- We are all privacy engineers.
- For the privacy engineer, before the mantra to innovate, comes the mantra to do no harm.
- Innovation and complexity need not be the adversary of Privacy Engineering, though failure of imagination may be.
- The Privacy Engineer must be able to understand, calculate, mitigate, and accept risk.
- Privacy engineering happens inside of and outside of code.
- A privacy engineer needs to differentiate between bad ideas and bad implementations
Let’s all be Privacy Engineers.
End Notes
- Is 2013 the Year of the Privacy Engineering by Robert Jason Cronk, CIPP/US
- Federal Trade Commission, “Protecting Consumer Privacy in an Era of Rapid Change: Recommendations For Businesses and Policymakers, p. 43 http://www.ftc.gov/os/2012/03/120326privacyreport.pdf
___________________________
by Michelle Finneran Dennedy
Tom Finneran was my dad, my hero and my mentor. He died of long haul COVID-19 on December 23, 2021.
He was the world’s first privacy engineer (we affectionately called him ‘Privacy Engineering Zero’) because he was able to take requirements, data models, and other classic problem solving and engineering techniques and apply them to the complex and evolving world of data protection, governance, and privacy.
In the above article, he introduced the world to many of the definitions formulated in our take on Privacy Engineering after we launched “The Privacy Engineer’s Manifesto: Going from Policy to Code to QA to Value”, (Apress 2014) written by Tom Finneran, Jonathan Fox and myself. There is more to build and grow based upon these methodologies, all of which will have a bit of the heart and soul of Tom Finneran inspiring them and leading us all ever forward in the pursuit of ethics and excellence.
by Robert S. Seiner (TDAN.com Publisher)
Tom Finneran was a close friend and huge influence on me and my career. I joined Spectrum Technology Group many years ago after learning about Tom and fellow Spectrum consultants (Barbara Von Halle, Terry Moriarty, Kathy Long, Judy Reeder, Martha Dember, Gwen Thomas among others) at this company that had careers that were advanced through their public teachings, writings and presentations. I modeled my career after Tom’s and the others I mentioned. Tom and I developed a close working relationship through the years at Spectrum, CIBER, and beyond, as Tom showed interest in mentoring me and guiding me on the ins-and-outs of the data management consulting industry. Thank you, Tom. You will be missed dearly by me and others.
This article was originally published on the pages of TDAN.com years ago.
