Guide to Performing a Privacy Impact Assessment

The requirement for a privacy impact assessment (PIA) or data protection impact assessment (DPIA) was introduced with the General Data Protection Regulation (Art. 35 of the GDPR). This refers to the obligation of the controller to conduct an impact assessment and to document it before starting the intended data processing. It’s also required when major changes or upgrades are made to systems processing personal data.
While various supervisory agencies have published checklists for questions how the data is collected, stored, shared etc, few really seem to deal with the necessary steps in preparing for the actual DPIA which is equally important. Here are some steps to consider before you start your assessment.

The key 1st step in starting a PIA is to assemble network, application and any existing risk assessment documentation about the data or proposed data for assessment. This is important, as assessing privacy controls is dependent on technical and administrative controls that will govern the data. For example, if a new customer database with sensitive data is being provisioned on AWS in an existing database farm then you will want to have a detailed knowlege of the environment that it’s going to sit in and if there are any gaps. Things to look at in this scenario might include proposed or existing;

• Encryption controls (e.g. Database TDE, SSL, Security certificates & Key Vaults)
• Access controls: DBO accounts and other privileged access users, security groups, access lists, network access controls
• Remote access (VPN users and groups, vendor accounts, multi-factor authentication, access logs)
• Database access logging, server security event logging, access list deny logs, firewall logs
• Network segmentation and firewall rules
• Data retention settings and policies for personal records
• Data loss prevention controls
• Data minimization techniques at data collection points and transfers to 3rd parties
• Form validation controls
• API security (REST/SOAP/JSON/XML)
• Vulnerability management
• Change management controls

The objective at this stage is data collection and controls to check for before the assessment gets underway.

While there is no specfic template, it’s a good idea to keep it high-level to resonate with technical and non-technical audiences alike. Remember the main purpose is to demonstrate personal data flows are documented and data assets are accounted for. The visio diagram below is an example for a middle eastern multinational. Personal data flow types are color coded and country flags are used to show trans-border data flows.

Several data protection authorities recommend that data subjects be consulted on plans to process their data. This is a good practice in gaining trust with customers and identifying potential push back early on. A simple survey can often be used to good effect for this practice.

Controllers must be able to describe waht the data processing is intended to accomplish (i.e., the primary purposes for which the data are collected and used). This can be a high-level description of the services. This can briefly describe the service, the data subjects whose personal data is processed as well as the purpose/value derived from the processing system. Put simply, why does this exist?

You should also be able to define how processing will be divided between the controller and the processor and whether any joint processing will take place.

Controllers and processors should first establish a ‘legal bases’ for processing data. Legal bases may fall into 1 of 6 categories listed in the chart below. The main themes of these categories is that businesses must have authorization to use the data and it must be kept to a minimum to enable processing. The correct legal basis/bases should be documented in the PIA.

Businesses are expected to implement a risk management program for protecting personal data under the scope of GDPR. Particular attention should be given to risk relating to encryption, access management, breach detection, incident management, logging, application security, backup systems and data loss prevention. Consider the following points when assessing the environment and mitigating risks;

• Are the latest encryption algorithms in use regularly scanned for latest versions? Regular scanning and patching of the network estate should detect and remediate these issues (Think about server SSL certs, RDP, SSH versions, VPN software, key management systems, TDE encryption etc.
• Is encryption deployed at the database, application and transport layers for personal data being processed?
• Are application view controls such as data masking used to prevent full personal data from being shown on operator screeens?
• Are controls over personal data used in the DEV/QA environments secured using data de-identification techniques? One or more techniques should be used such as data substituion to protect personal data
• Are APIs secured appropriately e.g. REST, SOAP security controls? Several techniques including encryption, access controls, rate limiting and registering all services can be used to protected application layer personal data
• Is logging enabled for a all privileged access to databases, application and infrastructure servers and appliances. Are these logs protected from deletion or modification? Technology teams should have centralized logging services which can colate logs and present early warning to analysts of possible attacks.
• Are personal data breach notification procedures in place with parties to be notified and incident handling measures? Specific notifications within timeframes are required for GDPR and US state laws. Security. legal and corporate communciation teams should be aware of what the statutory requirements are
• Are data loss prevention systems in effect for all communication channels and setup for regular PII discovery?
• Are DLP incidents reviewed and actioned timely?
• Is there an automated vulnerability management program in place for all on-premise and 3rd party hosted nodes? Does this include network infrastructure (e.g. Cisco IOS, appliance O/S’s, Linux machines) and databases (Oracle, SQL, PeopleSoft)

DPIA’s should identify threats and vulnerabilities by severity level at the end of the exercise. It’s important that the information is reported to stakeholders and action plans are drawn up and signed-off on. Data processing should not go ahead if high risks are not remediated. Any remediation performed should be checked in change management procedures.

You can find a DPIA template and Visio format diagram on our site by clicking on the link Here

If you have any questions about DPIA’s, contact me.