[BreachExchange] GDPR: 5 steps every company should address with their data processor now

[Audrey McNeil]

https://perspectives.tieto.com/blog/2017/12/gdpr-5-steps-
every-company-should-address-with-their-data-processor-now/

The EU General Data Protection Regulation (GDPR) is only six months away,
and preparations should be well under way by now.

However, it may be that many enterprises have concentrated on their own
main processing operations, and do not yet have a clear plan on how
responsibilities between the data controller (defining the purpose and
means of the processing), and the data processor (processing on behalf of
the data controller) should be managed.

At worst, the transition to GDPR can lead to misunderstandings between the
data controller and processor. At its best, however, it offers an
opportunity to deepen relations and collaboration, as long as the
transition is carried out properly, and in mutual understanding. The latter
approach is definitely the one I recommend embracing.

The purpose of this article is to summarize the key learnings we have
gained at Tieto during our preparations for the role of a data processor,
and also whilst planning our own procurement processes as a data controller.

So what, exactly, are the steps you should take with your data processor to
prepare for GDPR?

1. Map out and understand your own personal data processing

First of all, you must map out and understand the nature, scope, context,
risks and purposes of the personal data your enterprise processes.

Make sure that your actions correlate with the requirements of the GDPR,
such as accountability and privacy by design and default. Update any
measures where necessary. Always ensure and be prepared to demonstrate that
the processing of personal data is performed in compliance with the GDPR.
It is vital to remember that ‘doing the right thing’ is not a sufficient
approach, all measures taken must also be documented carefully.

Keep in mind, that you – the data controller – know best what kind of
personal data you possess, and how you use it. This is something you need
to be able to clearly communicate to your data processor(s), so that they
can provide the most suitable products and services.

2. Carefully consider which data processors you use and why

As a part of mapping your personal data processing, you also need to
identify what data processors you are using – why, how, where and when.

This may sound fairly straightforward, but it is surprisingly challenging
to map all instances where subcontractors are processing your personal
data, because they may be scattered throughout your business processes.
Create a clear question list for mapping, and keep your procurement people
close, as they are probably most knowledgeable of you subcontractors.

As a concrete result of this mapping you should be able to understand the
essentials: how your data processors relate to the purpose of processing
you have defined (why), how are they located geographically and in your
data flow mapping (where, how), and in the lifecycle of personal data
processing (when).

After this stage you can move towards more detailed requirements.


3. Evaluate your data processors: are they able to comply with the GDPR?

Although the data controller is considered accountable under the GDPR, an
IT-service provider may, in fact, perform a large part of the actual
personal data processing on behalf of the data controller’s organization.
It is therefore extremely important to ensure that the data processor you
use will comply with the GDPR.

As outlined in the GDPR: “… a data controller may only use data processors
who provide sufficient guarantees to implement appropriate technical and
organizational measures in such a manner that processing will meet the
requirements of the GDPR”.

In practice this means that your data processor should be able to provide
sufficient documented proof that it has general level policies, processes,
organizational and technical measures in place to meet the requirements of
the GDPR.

Remember that the data processors don’t necessarily have all this material
readily available, as the GDPR is not applicable yet. They should, however,
be able to give you preliminary descriptions and documents, and provide you
with a timeline that clearly demonstrates when they will have all the
required features in place.

Ask your data processor(s) to describe their core privacy and security
processes and to provide you with sufficient documentation.  Whilst a
one-off exercise is probably needed for the GDPR implementation work,
ensure that the questions are also part of your ongoing procurement
process. In the future, upcoming GDPR-approved certifications may prove
very helpful, but currently we have to manage with more custom-made
checklists.

4. Does the data processor’s product or service help you to comply with the
GDPR?

The ‘Privacy by design and default’ principle requires that GDPR needs to
be considered during both, the planning phase and the actual processing.
This can be challenging, as the GDPR does not provide a concrete list of
requirements that you should follow, merely examples referring to
minimization and pseudonymization.

At Tieto, we tackled this problem by using the full regulation text as the
foundation for the privacy by design and default definition.

We started by recognizing the articles of the GDPR that have an impact on
IT products and services, and then translated them to concrete
requirements, for example “I need to be able to acquire a copy
of/delete/transfer the data subject personal data”.

As result, we created our requirement list based on the GDPR. This is a
useful tip for software engineers, as the articles thus get simplified and
become readable requirements. It also works well for us lawyers, because it
is easier to prove one’s compliance with a criteria that is based directly
on the GDPR.

In addition, this approach works for reviewing the IT products and services
in the data controller-data processor relationship. The key is to establish
a clear requirement list based on the GDPR.

Recognize, which requirements are applicable to the data processor and then
ask how it has implemented them, for example by asking how the data
processor’s service enables data subject access right, or how the service
enables data portability.

Make this a part of your ongoing procurement process. It will enable you to
gather an understanding of your data processor’s capabilities, as well as
evidence of your own compliance.

5. Make agreements in adequate detail and with sufficient guarantees

It is important to remember that the GDPR requires mandatory clauses to be
agreed on between the data controller and the data processor.

Here, I consider it important to be effective and compliant at the same
time. Take some time to consider how you will actually agree and negotiate
on data processing with your service providers.

At Tieto we have chosen a “frame agreement” approach, where we agree on the
mandatory clauses once with our customer in a separate data processing
agreement, with processing specific details entered in separate
specification attachment(s). This way the parties don’t need to discuss the
same terms with each separate agreement.

Also consider what you should be negotiating on. Agreeing on data
processing should not be seen as a “fire and forget” -process, but as a
mutual goal where both parties have their responsibilities.

Avoid getting stuck in a discussion where parties try to transfer all
liability and responsibility onto each other. Understanding what the actual
(and applicable) requirements of the GDPR are will help you identify how
responsibilities should be shared, and agreed on, between the parties.

In a nutshell, first understand what is being done, and who is doing it.
Secondly, understand the requirements that need to be fulfilled, and ensure
that they are fulfilled within a controlled process. Thirdly, ensure that
you have the mandatory agreements and all other documents in place.

Last, remember that we are all working towards the same goal, so let´s work
together to get there successfully!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20171204/e8de01a5/attachment.html>