A privacy program can be multi-dimensional and broken up across the enterprise to align with where the competency lies. But the privacy professional must connect the dots across the whole program. Here are 5 examples of work-streams that could form a privacy program.
- GDPR Principles
- Integrity & Confidentiality + Notification + Storage Limitation + Data Minimization + Accuracy
- Integrity & Confidentiality + Notification + Storage Limitation
- Integrity and Confidentiality
- Notification
Various credible authoritative sources of guidance exist for Information Security, e.g. NIST. These provide clear control detail to assist clients in meeting audit-able defense standards including various compliance requirements such as PCI-DSS. GDPR requirements are not prescriptive at all but rather high-level and talk to the principals. While allowing for different interpretation, they are scalable to any type or size of organisation. But this can be frustrating to Information Security practitioners looking for prescriptive guidance. The privacy officer must tailor and balance the fine line between compliance and business value. The GDPR principles include:
Personal data shall be:
- Processed lawfully, fairly and in a transparent manner in relation to the data subject (‘lawfulness, fairness and transparency’);
- Collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’);
- Adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (‘data minimization’);
- Accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay(‘accuracy’);
- Kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) subject to implementation of the appropriate technical and organizational measures required by this Regulation in order to safeguard the rights and freedoms of the data subject (‘storage limitation’);
- Processed in a manner that ensures appropriate security of the personal data, including protection against unauthorized or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organizational measures (‘integrity and confidentiality’).
- The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 (‘accountability’).
For the InfoSec Pros
InfoSec is just a “slice of the pie.” Privacy is broader than InfoSec and certainly NOT a domain of InfoSec as many InfoSec Pro’s believe. This is likely caused by the inclusion of privacy dependencies included in InfoSec curriculum. Most InfoSec / IT folk are not concerned about lawfulness, fairness, transparency etc., right? Data is data and must be protected, correct?
One of the key contributions the InfoSec & established risk / incident management community can make is the inclusion of privacy incident management into existing processes typically managed by service delivery. Use the existing tools and processes which are typically sound rather than let the organization start creating a “GDPR Incident / Breach” process. Typically lawyers and compliance people are not as “mature” as IT / ISO when it comes to managing incidents.
Integrity & Confidentiality + Notification + Storage Limitation
These are the slices of the pie most relevant to the IT Service delivery teams and InfoSec. This is your area of expertise – don’t let compliance set up parallel systems and processes – you own this piece with one exception.
For mature enterprises with established enterprise architecture capability, we now include consideration for the data itself. Here, information governance & architecture now leads to support privacy. This is where new developments in privacy tools, privacy by design, etc. are required but typically this is a lower maturity of capability in the enterprise and an emerging data science topic. Most privacy and InfoSec pros start to get lost here so our job becomes consulting with the data scientists on WHY this is important.
Privacy is not confidentiality
Authoritative texts on InfoSec are to blame for including a “privacy” domain in their curriculum. If they just replaced the word privacy with “Information security dependencies for privacy” we would all be OK – but they don’t. They try to explain privacy but fail to define what InfoSec’s role is in relation to privacy – this is the most common misunderstanding you will come across with InfoSec team members. Fortunately, the GDPR principals illustrate this easily but it’s still going to take some awareness and socialization.
Many organizations battle with trying to define exactly what constitutes Personal Data. Here’s a tip – it’s extremely hard and pointless to really go down this rabbit hole. Why? As you combine pieces of data (that on their own may not be considered “personal”) suddenly we move into the identifiable grey territory. Secondly, technology is creating privacy risks every day – this is a moving target and why the GDPR is principal based. Many enterprises don’t stop to even consider who actually owns Personal Data.