I was going through some old emails and reread the EU Data Protection Commissioners’ Privacy by Design resolution from the October Jerusalem conference. The principles are:

1. Proactive not Reactive; Preventative not Remedial
2. Privacy as the Default
3. Privacy Embedded into Design
4. Full Functionality: Positive-Sum, not Zero-Sum
5. End-to-End Lifecycle Protection
6. Respect for User Privacy

The above makes good sense. So how do you do it? You need to review every policy, process, and guidance to make sure that privacy is written into those documents. As the person responsible for privacy within your organization, you should be part of the governance process for the review and creation of new policies, processes and guidance. You then need to train the persons who rely on those documents. This training needs to be updated regularly and delivered regularly. Finally, you need to be able to measure your organization’s compliance with the policies, processes and guidance.

As an example, in a previous position, we had a sign-off process for each new product that was going to be delivered to market. The design process required sign-off by various parts of the business at various stages in the development. My sign-off was required at each stage. This allowed me to review forms, workflows, data flows and the like for each product. I was able to embed privacy at the concept stage.

Another example requiring privacy sign off for all significant changes in processing. Updating your IT infrastructure is a good example. New workflows and data flows could substantially affect international transfers. I’ve worked closely with IT departments to make sure that when migrating servers or installing patches, there are proper policies and procedures in place to ensure adequate testing before deployment. One change we made after a serious incident was to include the review of legacy code that had worked well in the prior environment. Legacy code can execute differently. Identifying the sections of code that process customer information and analyzing and/or testing them (in accordance with your risk-based policy) is important.

Although none of this is rocket science, it can be challenging in large and complex organizations. Of course, telling a regulator that your organization is just too large and complex is not going to go over well. It’s interesting, but I have often found that the work done by privacy departments in organizations is often leverage by other projects and departments (e.g., IT, marketing, legal).