May 25th is just around the corner and most organizations are well on their way to establishing a Data Processing Agreements (DPA) with their third party service providers. But having a DPA is does not mean compliance with GDPR.
The DPA sets out:
1. The scope and type of data processed;
2. The agreed processing rules (what the processor may and may not do with the data)
3. Specific terms (such as liability, notification, recovery, deletion, etc.. ..) applicable to GDPR.
But, having this document in place is only half the story. Once there is awareness of the data processed and agreement on the rules, the other half of the story is governing compliance with the DPA and in doing so, mitigating the risks on GDPR non-compliance. Ask yourself things like: Does the service provider follow up on the agreed provisions? What if personal data categories change? Are breaches reported and data request handled within the stipulated deadlines? Are data cleaning processes properly executed? These questions refer to just a few of the GDPR obligations on the data processor that the client – being the controller – is expected to verify and control. Failure to do so risks significant financial penalties by the supervising authorities. See our earlier post for more on GDPR obligations on data processors.
The key to this execution stage of GDPR compliance, lies in understanding operational controls that are used on a day to day / month to month basis to monitor and control the DPA. In other words, the DPAs must be effectively governed. No organization wants to translate GDPR requirements into an overly detailed list of checks that cost a fortune to validate and collect evidence on. This is why Leadmark helps clients process their DPA obligations efficiently into existing governance frameworks which will reduce the risk of non compliance and reduce the cost of control. Additionally, our services and tooling can take GDPR control to another level by automating the application of controls across suppliers and contracts. This prevents the need for reestablishing the list of controls each time a new agreement is signed.
5 steps to get your sourcing governance ready for GDPR
Below is our 5 step process to get your sourcing governance ready for GDPR:
1. Identify critical risks and controls
The identification of risks and associated controls should be done in the DPA development stage and will be based on the types of data and services in scope of the DPA.
For most organizations, there will be two types of controls. Generic and Service specific. The effort to distinguish is worthwhile because it can significantly reduce the effort needed to create new DPAs with suppliers as sourcing partners and services change over time. Also it significantly reduces the risk of non compliance by ensuring there is a minimum level of mandatory generic controls for any new supplier and/or agreement.
Generic controls are those that are mandatory and applicable under GDPR irrespective of the types of data being processed or what type of processing is being done. Examples of a mandatory generic GDPR control is that all personal data (if not anonymized) must be deleted once it is no longer needed for the purposes for which it was collected. It is therefore necessary to have a control that verifies this data deletion on a periodic basis. The exact period and timeframe for retention will be set based on the service risks. Another generic control relates to the processing of data only according to written instructions. This requires a periodic check that written instructions are up to date and that the supplier is not doing any ‘out of process’ processing. As you can see, generic controls must be defined and applied, however the frequency and method of verification will be scaled to the risks of the service.
Service specific controls are those which are required as a direct result of the scope of data and services being covered by a DPA. For governance purposes, this list of controls is more of a checklist which must be used to identify additional controls over the generic controls based on the scope and risks of a specific service. For example, financial and health related special data categories introduce new requirements. Or, whether data will be processed outside the EU or by sub-contractors and additional controls are needed for capturing explicit controller approvals.
With these categories of controls, the standard DPA can be created where contract managers need only set a frequency for mandatory controls and select from a checklist specific services. This greatly reduces the time and risk for new service agreements. In a governance system, such as TRAC, these controls can then be operationalized with a few clicks, reducing the time to implement on new agreements even more.
2. Operationalize controls
Many organizations define and document controls in contracts, including the DPA, and assume the suppliers will implement all the necessary processes and activities to meet these obligations. Some will define a set of measures and KPIs to control these obligations (such as volume of breaches reported over a period, average time to respond to a data subject request, etc… ) But, as with many contractual obligations, these controls are not sufficiently operationalized in terms of Who, What and When. Who will validate a control, What will they do to validate it and what data will be used (if relevant) to validate it, When will this validation be done and how frequently. The idea behind operationalization is that if you want to manage the performance of a contract you need to control the units of performance which includes obligations, services and deliverables.
To truly operationalize controls, automated alerts to accountable people are needed, and the results of any control need to be logged and traceable. This is where our sourcing governance system TRAC can help and prevent unnecessary spreadsheets. When in doubt, controls should be checked on a frequency proportional to their risk (severity and likelihood).
Here is an example of an operationalized GDPR control:
Obligation:
The service provider shall not engage with any sub-processor or change any of its sub-processor without prior written agreement from the client
Control:
The service provider shall provide an annual formal statement on the extent to which sub-processors are used to provide the service including their role and site of operation
When:
Each year on January 31st during the full term of the agreement
Deliverer:
Bill Johnson – Service Delivery Manager (Supplier)
Acceptor:
Don Brown – Contract Manager (Client)
3. Communicate to suppliers and internal stakeholders
A quick search on Google about the needs of data security and GDPR will almost always raise the point of awareness within the organization. The simple fact is this: If people don’t know what is expected from them it will not get done. This goes for both the client side and supplier side. It’s important to remember that client side is ALWAYS the controller and as such, cannot assume a supplier that says they are GDPR compliant, is. It is the responsibility of the controller to define what is needed for a supplier to be compliant and therefore it’s essential that these requirements and objectives are communicated clearly with suppliers. Also, it’s a mistake to assume the supplier internally communicates beyond those involved in the DPA.
A discussion with the supplier should be managed that ensures both sides are on the same page when it comes to critical control objectives and which people need to be informed. This will change over the course of the deal and should therefore be reviewed regularly
4. Establish data capture processes and tooling
Don’t underestimate the operational needs imposed by GDPR. Article 30 of the GDPR requires controllers to establish auditable registers that capture information like Data subject consent (if relevant), Data subject requests, policy waivers, etc… These are essential and many have processing speed limitations with the new rules which make them as critical to track as incident responses. These are operational processes that must be in place. The increase in costs can be significant if these processes are not enterprise enabled. Relying on each individual team to control these elements themselves, not only increases overhead, but also the risk of non compliance.
5. Embed and review
Once everything is in place, GDPR obligations have to be managed to ensure ongoing compliance. For this the management of GDPR obligations has to be embedded in the day to day / month to month governance activities and reviewed on a regular basis. To ensure compliance it is not sufficient for the controller to be reactive and just wait for the service provider to report any potential breach or change it’s data processing activities. This would put the client at risk of non-compliance with GDPR regulations and possible subsequent regulatory actions by supervising authorities that may include significant financial penalties.
Conclusion
What will happen after GDPR comes into effect on May 25th? Will companies be fined from day one or will the supervisors start cautiously and be lenient? We don’t know. What we do know is that waiting to see which way the wind blows is not a good idea: supervisors and ultimately customers will not accept this.
If you have already operationalized privacy requirements and included them in your ongoing sourcing governance efforts, the GDPR encourages you to keep up the good work. If you are not quite there yet you have some work ahead.
