For many of us that work in IT Fields, the requirements of privacy bills like General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) seem very confusing. Privacy bills are often hard to digest and, though they address very real human rights concerns, they are often out of touch with the way information is structured and used in modern information systems. Nevertheless, privacy legislation is a very real issue in the modern technical landscape, and we, as IT professionals, need a clear path forward to engineer systems that better account for the privacy of individuals.
To that end, I would like to share a framework that will help your organization satisfy its various privacy requirements from a technical perspective. I am intentionally omitting security from this list to make room to focus on some of the more nebulous privacy concepts (for a better understanding of security controls to protect personal information, see Caitlin’s discussion of critical privacy security controls here).
As a cybersecurity professional, recovering policy wonk, and privacy hobbyist, the framework I am sharing is my attempt to bridge the gap between the ‘legalese’ in privacy bills, and the realities of the data center. The framework I am proposing is distilled from close readings of:
- General Data Protection Regulation (GDPR),
- California Consumer Privacy Act (CCPA),
- The US Privacy Shield Framework,
- The National Privacy Principles (NPPs) from the Australian Privacy Act,
- The Fair Information Practice Principles (FIPPs) which are informed by U.S. Federal Trade Commission, and
- The National Institute of Standards and Technology’s (NIST’s) privacy controls from Special Publication 800-53 Rev 4 and 5.
To be clear, following this framework will not guarantee compliance with any one of the previously mentioned acts, but it will help you engineer or reengineer, your information systems in a manner that will support the administrative requirements needed to comply with the privacy requirements in these acts and frameworks.
Personal information is what privacy is all about. The remaining concepts in the framework will revolve around their collection, storage, and use so let’s define personal information. Personal information is information that can identify a person directly or indirectly such as a name, an identification number, location data, an online identifier, or one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person. For the IT practitioner, a lot of this will be straightforward but bear in mind that personal information can also be identifiers used in information systems like hostnames, IP addresses, and email addresses.
Some laws even define more sensitive types of personal information to include health records, racial or ethnic background, religious/political/philosophical beliefs, trade union membership, information about an individual’s life, or criminal records.
Notice, Plain Language, Transparency, and Authority to Collect
One of the most consistent requirements in privacy law is that of consent. Engineer your systems to prompt and record an individual’s permission to use their personal information. It may be beneficial to your company to audit the use of this function to be able to attribute who gave permission, and when. Of course, auditing this acceptance may also be seen as collection of personal information, so make sure you disclose that you will record the information PRIOR to having an individual accept.
Right to Opt-Out, Object, and Be Forgotten
Closely related to consent is the right to opt-out or object to collection, storage, or use of personal information. This means that an individual can ask not to have their personal information included in the business activities of your company. Customers may also elect to have their personal information removed from your organization. Opting-Out, Objecting, and Forgetting can often be tricky requirements to accommodate from an information system design perspective, as not including, or even removing select pieces of information from a database schema may negatively impact the integrity of processes that require complete databases.
Make sure you speak to your privacy personnel and legal department to identify what personal information is required to be omitted or removed if an individual requests and design your systems to operate with that information redacted, overwritten, or removed from your databases. To that end, I would strongly recommend that you not use personal data as a key field in any database schema.
Some privacy legislation requires you to create methods for your customers to opt-out even prior to the collection of personal information. For instance, CCPA requires you to have a ‘clear and conspicuous link on the business’ internet homepage, titled “Do Not Sell My Personal Information’” prior to collecting information. Make sure you consult your privacy personnel and legal personnel about what artifacts should be designed into your webpage templates.
Access, Redress, and Data Quality
Another important privacy concept is that of access, redress, and data quality. It is vital that you allow individuals to have access to copies of the personal information you collect, store, transmit, or process. Additionally, the individual may request that you fix any errors with that information. To accommodate this, make sure any database holding personal information is easily accessible (by authorized personnel) and able to accommodate changes to discrete fields without compromising the integrity of your service.
If necessary, make corrections as part of regularly scheduled maintenance to minimize disruption of service. Many privacy laws have requirements about how much time you can take between receiving a request to fix information and actually fixing it, make sure you have processes in place to accommodate these time frames.
It may be beneficial to build systems that allow individuals to query and change their personal information on their own. If you do this, make sure you treat this as a top information risk, and secure the system appropriately, as unauthorized access to the system could be devastating.
Data Minimization, and Secondary Use
Data minimization means that, where possible, you must give individuals the opportunity to do business with you without the individual having to identify themselves. When you need to collect personal information, only collect personal information that is relevant to your purposes and no more. Also, make sure that you do not use data for any secondary purposes without getting consent from individuals.
Data minimization and restriction of secondary use require close monitoring of data structures, particularly in large organizations that may have complex database schemas. Make sure you account for personal information in the database, and that you know how that data is being used in support of the purposes you disclosed to the individual who consented to its use. Invariably, developers will try to use personal information in new and interesting ways. Make sure you know how the developers intend on using the personal data and get consent for its new use from individuals prior to implementing any new capabilities not covered by the individual’s previous consent (this includes testing any new capabilities).
Information Flows and International Sharing
Occasionally, personal information may need to be transferred to another organization and/or to a different nation. When transferring personal information to a different organization, make sure that you have a legally binding contract that requires your partner to protect personal information and accommodate privacy rights in the exact same manner you must. When transferring to another country, make sure your contracts are legally binding in both countries. Many privacy laws require you to inform individuals whose personal information you are transferring prior to transferring their personal information.
Be aware that GDPR is strongly tied into a controller/processor dynamic. As such, there are significant administrative requirements tied into any partnership in which personal information is transferred, stored, and processed by another organization on your organization’s behalf. Make sure you consult privacy personnel and/or legal personnel prior to creating any system interconnects or conducting transfers of personal information by any other means.
This is not an exhaustive list of privacy requirements for compliance with every privacy bill or framework, there are many other considerations you may take into account depending on the frameworks with which you must comply. A few additional things to consider include:
- Training employees to properly handle personal information,
- Auditing the use of personal information so you have attribution to who/what has accessed, or processed it,
- Protecting the rights of children by not collecting the personal information of minors,
- Not using government identifiers, such as Social Security Numbers, or Medicare Numbers as identifiers for individuals,
- Appointing data protection officers to head privacy efforts in the case that your organization collects, stores, or processes personal information on a large scale, and
- Conducting privacy assessments to ensure you are complying both technically and administratively to the privacy requirements of all pertinent privacy legislation.
CyberGRX Can Help!
CyberGRX was among the first organizations to conduct assessments against GDPR risks. We continue to work with our customers to provide assessment content that marries the technical and administrative issues in privacy to better serve a wide array of organizations doing business across the U.S., in the European Union, and Australia.
CISO OF CYBERGRX