- 15-01-20Riot as a privacy-friendly and secure messaging app
- 20-12-19Guest blog | Privacy and IT: 3 tips for a good processor agreement
- 11-12-19Ceph’s Software Designed Storage for all possible storage flavours
- 05-12-19Cisco switches for new connections between BIT data centers
- 14-11-19Centralisation of data can lead to vendor lock-in, monopolisation and increasing risks
- 05-11-19Guidelines for good cable management in your rack
- 29-10-19The power-consuming climate activist
- 14-10-195 Practical tips for information security
- 08-10-19The person behind BIT
- 12-09-19Goodbye old firewalls. Welcome Next-Generation Firewalls!
Guest blog | Privacy and IT: 3 tips for a good processor agreement
Every week there are clients who ask me to assess or prepare a processor agreement. A processor agreement is an agreement between the controller and the processor, where - in short - you document how the processor has to handle the personal data of the controller. The controller can be a healthcare institution that uses services form an IT supplier. The IT supplier can be considered as the processor.
When assessing a processor agreement I often find some basic ‘mistakes’. I purposefully added quotation marks, because the current law and legislation is not (yet) clear about the processor agreement in all instances. To me, it is not always defined what is right or wrong. I am, however, convinced that some basic items need to be addressed properly in order to prevent a lot of legal hassles in the future. So here are my tips for a good processor agreement.
Tip 1: Be critical of the legal relation with your contract partner and specify the processor agreement for your situation
I often find that processor agreements are set up as a type of general terms and conditions contract and are used as a standard for every agreement that (might) involve the processing of personal data. First, you need to assess whether there is a relation that needs a processor agreement at all. Is there a controller and a processor?
Companies tend to see every company that touches their data as a processor. Just to be safe, everything is closed off with contracts by using a processor agreement. Before you know it, parties can have a legal relation that actually does not even exist. Better safe than sorry does not always work when it comes to processor agreements if you ask me. Always check whether you and your contract partner are actually controller and processor.
In addition, parties usually cannot use a standard agreement. I look at processor agreements as bespoke work. Invest in a good processor agreement. For a processor, this does not mean that there has to be a different processor agreement for every individual client. Not at all. In practice it will be impossible to keep remembering and applying all different nuances for every single client. I advise processors to offer their clients their own processor agreement that matches the service agreement. The two documents should not contradict, but complement each other. It is also important to set the duration of the processor agreement to the same period as the duration of the framework agreement.
Make sure that the processor agreement matches both your business operations and the operations of the controller. Is it (relatively) easy to meet the standards of the agreement? Are the provided guarantees fitting on, for example, the security level? Are the demands for the destruction of data realistically possible? It is important to fine tune the processor agreement to the specific situation of both parties.
Tip 2: Make a clear and complete liability provision
A faulty liability provision is very high-risk. Make sure you have a clear and complete liability provision. Especially for a processor, it is important to take a critical look at this provision. For example, when a relatively small IT supplier has clients that are ‘the Ahold and the KPN of the world’, there is a good chance that a liability statement can put them out of business. Only because of the fact that his big clients will have the funds to go to a lengthy trial that he probably cannot afford himself. It is also wise to specify the level of liability. Controllers have to be critical about the actual risk and how to minimise this risk as well. To me, the liability provision is like a safety net behind the scenes, but preventing the damages - finding solutions ‘on-stage’ - is more important in such issues.
Tip 3: What to do in case of leaks
Accidents happen in the blink of an eye. It can (unintentionally) happen that something goes wrong and personal data gets out. In practice, you are dealing with two different organisations and two different business operations. It is useful to agree on a specific procedure in case of such mistakes. Who are the people to contact? How can these people be reached? Where is the most risk for each party? Many things to think about beforehand. In case of an incident, this can slightly decrease the damages.
The processor agreement is not a standard document and it is not applicable in every situation and on every legal relation. Assess whether your contract partner is actually a processor (or controller) and do not hesitate to be critical when it comes to the contents of the agreement. It is important to think about the agreements that you include in the processor agreement and to make sure that they match the relation you have with your contract partner.