Business First December 2017 December BF Digital | Page 19

Neither do I: my client’s services are purely
in relation to the maintenance of the bits of
software through which their customer’s
personal data passes. Crucially, my client
doesn’t come into contact with the personal
data at any point of its services. Therefore,
my client doesn’t process personal data,
therefore it isn’t a data processor.
• a software services provider is about to
take over the management of a public
sector body’s IT infrastructure. Not the
actual individual software applications, but
the infrastructure on which the apps are
hosted – the pizza base, rather than the
pizza toppings. However, although the
public body’s personal data is held in the
various apps, the apps are hosted on my
client’s servers, and therefore my client is a
data processor.
The message: each business situation needs
to be judged on its own facts, to ascertain
whether a particular entity acts as data
controller, data processor or simple service
provider. Once the data role has been
identified then the entity knows which
obligations it has to comply with under the
GDPR.
What do Data Controllers and Data
Processors have to do?
So, if I’m a data processor, what are my
obligations under GDPR?
The answer is that there are two types of
obligations: obligations which the GDPR
imposes directly on you as statutory
requirements for a data processor. Secondly,
you should have contractual (as opposed to
statutory) obligations placed on you by the
data controller – and the reason why the data
controller wants to place contractual
obligations on you is because the GDPR tells
him he has to.
The GDPR wants to see action, pro­active
steps towards compliance. It wants data
processors to show the steps that they have
taken to comply, and it achieves this by direct
statutory obligation on the controllers.
However, the GDPR also wants to engender
best practice standards on dealings between
data controllers and processors, and
consequently it takes the unusually direct
step of dictating the key terms of a data
processing agreement.
So what do data controllers have to do in
relation to data processors? The Information
Controller’s Office issued draft guidance on
this in September 2017.
The basic rules for data controllers are:
• a written contract must be put in place
with each data processor, clearly setting out
each party’s data protection responsibilities
and liabilities;
• The GDPR sets out what needs to be
included in the contract. Obligations include
the processor’s only processing personal
data in line with the data controller’s
instructions, taking appropriate infosec
measures to ensure confidentiality of the
personal data, providing records and audit
access to the data controller and generally
assisting the controller in its compliance
with the GDPR; and
• Controllers must only appoint processors
who can provide ‘sufficient guarantees’ that
the requirements of the GDPR will be met
and the rights of data subjects protected.
The written contract goes some way to
providing the required guarantee, but the
expectation is that in the future approved
codes of conduct or certification schemes
will be developed.
What about data processors: what are
their obligations?
• Processors will have to comply with the
terms of the written contract imposed by
the data controller. This is an interesting
situation (really) for the data processor’s
contract negotiator: there’s little scope for
refusing to sign up to obligations which the
law says the data controller must impose on
you. I’ve already come across a couple of
instances where controllers’ lawyers have
adopted the “I’m sorry, this is non­
negotiable – statutory obligation on
m’client, you see”.
However, a couple of comments from
current experience. First, the “statutory
obligations” required by the data controller
need to be compared with the actual
requirements of the GDPR: I’m finding that
over­enthusiastic lawyers for data
controllers are frequently asking for far
greater protection than the GDPR requires.
Thus, the GDPR’s requirement that a data
processor provides to the controller all
information necessary to demonstrate
GDPR compliance, “and allow for and
con tribute[s] to audits” (Article 28,
Regulation 3 (h)), can be inflated into a
fixed requirement to permit, and to pay for,
quarterly audits of the data processor’s
premises – as well as the premises of any
sub­processor appointed by the data
processor as sub­contractor. This is an
over­onerous interpretation of the
comparatively gentle GDPR obligation. Data
processors shouldn’t have to sign up to a
commercial demand which is louder than
the request of the GDPR.
Secondly, just because the data controller
is required by statute to place contractual
obligations on data processors, this doesn’t
stop processors placing obligations on the
controllers in return. In the past few
months I’ve been able to impose a
contractual obligation on data controllers
to comply with their own GDPR
requirements – and to indemnify the
processor for any loss caused by the
controller’s breach of the GDPR
requirements.
• Processors have to pass on to any
subcontractor the contractual obligations
imposed by the controller, and need to get
guarantees from the subcontractor. Fine in
principle, incredibly difficult in practice:
how will a comparatively small company
acting as data processor be able to impose
its data controller’s obligations on a multi­
national data hosting services provider
such as, say, Rackspace?
• If the subcontractor breaches the GDPR,
the law requires the data processor to take
responsibility for the breach. Usually, the
processor would protect against this by
getting an unlimited indemnity from its
subcontractor – but once again, this
depends upon the commercial reality.
Amazon Web Services’ Customer
Agreement currently caps its liability to
customers at fees paid in the previous
twelve months – good luck negotiating
unlimited liability with that one!
• Processors must only act on the
documented instructions of a controller. If a
data processor uses data outside the scope
of a controller’s permission, the act of doing
so will be a decision of the processor –
which means that it’s no longer a processor,
but a data controller, since controllers are
the only entities who can determine the
purpose of data use. Transformation from
processor to controller is disastrous for a
business, unless it has complied with all the
necessary GDPR requirements on a
controller about collection and processing
the relevant personal data. Consequence:
processors should be very clear about what
it is that the data controller wants them to
do. It’s therefore in the interests of both
controller and processor to be as clear as
possible about the scope of services
required.
Conclusion
The data controller/processor distinction
may sound like yet another headache from a
worrying piece of new legislation. In fact, it’s
a logical consequence of the shift from an
introvert Data Protection Act to the more
extrovert GDPR: controllers and processors
alike now have to be clear about their
obligations, have to take practical steps to
fulfil them and have to show that they’ve
done so.
There’s work for lawyers in negotiating
data processing agreements, and in
determining whether a business is or isn’t
acting as a data processor. Ultimately,
however, the consequence (unwanted or not)
goes back to the essential
aim of the GDPR: it’s time
for businesses to
understand what personal
data they hold, and what
they can and can’t do with it.
www.businessfirstonline.co.uk
17