The privacy landscape shifts, it seems, every week. The changes may come from new laws or regulations, changes in public opinion, expansion (or contraction) of your business, or the introduction of new technology to your infrastructure. Throughout this turmoil you need to have a privacy program that is resilient, adaptable, and agile so it can take the buffeting from these shifts while continuing to provide guidance to your organization.
As you establish or improve your privacy program you have several choices to make. The responsibilities of the privacy team, the team’s structure, what to include in your policies, and how to ensure the organization is complying with your requirements are just a few of the items to consider.
You can develop a program from scratch, of course, but you can also take advantage of the work of others by basing your program on existing privacy frameworks.
What makes a good privacy framework?
A good privacy framework provides a foundation to assist you in meeting your objectives. Since objectives may vary, there are several privacy frameworks that I use with my clients.
For example, often I am asked to put together a new or revised privacy policy. I tend to use the basic principles in the OECD Privacy Framework (See Chapter 1 Part 2) as the foundation for this task. These principles are easy for an entire staff to understand and can easily be applied to your organizational requirements.
If I am interested in measuring how comprehensive a privacy program’s activities are, I tend to use Nymity Privacy Management Accountability Framework™. Using this framework I can look at a well-researched list of privacy-related activities, determine which ones fit an organization, and identify the status of the applicable activities within that organization. Usually I extend this activity to communicate expectations of the privacy office to operational areas of the organization.
If I want to determine the maturity of an organization’s privacy practices, I rely on the Generally Accepted Privacy Principles from the American Institute of Certified Public Accountants (AICPA) and Canadian Institute of Chartered Accountants (CICA).
Ultimately, selecting the proper framework depends upon what you are trying to achieve.
GDPR as a framework
The most discussed change to the privacy landscape recently is the EU’s forthcoming Global Data Protection Regulation. GDPR has a wide scope, but it does not apply to everyone (see GDPR: Do you provide goods or services in the EU?). Even if you are not in-scope, it is worthwhile to consider GDPR as the overall framework on which to build or redefine your organization’s privacy program.
Every privacy program should be based on some basic principles. GDPR specifies its basic principles in Article 5. These principles can be used as a foundation for any privacy program and include:
- lawfulness, fairness and transparency;
- purpose limitation;
- data minimization;
- accuracy;
- storage limitation;
- integrity and confidentiality; and
- accountability.
GDPR goes on to provide requirements for meeting these principles throughout the regulation. If you are not in-scope for GDPR, do you need to fulfill all of the requirements? No. I do suggest however, that using the requirements as a basis for defining your privacy policies and procedures is a great place to start. I am beginning to use these principles as an alternative to OECD when define privacy policies for my clients.
Transparency, for example allows the individuals you are collecting information about to understand your privacy practices. Articles 13 and 14 of GDPR provide guidance on what you should include in your privacy notice (see Privacy policy or privacy notice: what’s the difference?). The requirements are more comprehensive than many people would expect or are required in many jurisdictions. So, if you are not in-scope, you can use the GDPR list as a set of recommendations that can be adopted for your program.
GDPR also provides guidance on development (Article 25) and security (Article 32) practices. While high level, you can use the information in these articles and the associated recitals to work with your development and security teams to build privacy into their practices.
The role of the Data Protection Officer
If you use GDPR as a framework for your privacy program, one of the most helpful aspects is the description of the role of the Data Protection Officer. Whether the title of your privacy program owner is a Data Protection Officer, a Privacy Officer, or simply a Privacy Analyst, there is information in Articles 37 through 39 that may be used as a foundation for this individual’s job description. This information may also be used in setting expectations with the rest of the organization about what to expect from the privacy program owner.