Processors and service providers

Articles 4(7) and 4(8) GDPR distinguish between controller and processor. A controller decides the purposes and means of processing. A processor is a person, public authority or other body that processes personal data on behalf of the controller.

A typical example is an IT provider that stores customer data in a cloud application selected by the business. Payroll, newsletter delivery, hosting, support and document destruction may also involve processing on behalf of a controller. The word service provider does not answer the legal question.

The distinction from providers acting under their own purposes or legal duties is important. A provider may be a processor for one service and a controller for another. With complex platforms, review which decisions the business makes and which essential means the provider determines.

Under Article 28(1) GDPR, a controller may use only processors that provide sufficient guarantees for appropriate technical and organisational measures. This is not merely a paperwork exercise. Before engagement, the business should understand the data flow, access groups, security measures and provider chain.

Depending on the risk, selection may involve encryption, access management, logging, backups, deletion, business continuity and incident response. Certifications and audit reports can be useful indicators, but they do not answer whether the concrete service and agreed controls fit the processing at issue.

The processor assessment checklist structures due diligence. For an existing agreement, the processor agreement check helps make missing terms and controls visible.

The agreement or other legal instrument must set out the subject matter and duration, nature and purpose, type of personal data, categories of data subjects and the controller's obligations and rights. These details create the framework in which instructions and controls can work.

The minimum content includes documented instructions, confidentiality, appropriate security measures, rules for subprocessors, assistance with data subject rights and breaches, support for compliance evidence and audits, and deletion or return after the service ends. The processor must also tell the controller if it believes an instruction infringes data protection law.

Article 28(9) GDPR requires the agreement to be in writing, including electronic form. Section 48(5) of the Austrian Data Protection Act confirms this for processors under Austrian law. A concise schedule can be sufficient when it fully describes the actual process. A long agreement can still be incomplete when essential data flows are missing.

Instructions do not have to anticipate every technical detail. They should make the permitted framework clear. This includes purpose, data types, data subjects, recipients and transfers, as well as the limits of the provider's own decisions. Changes should follow a traceable process.

Article 32 GDPR requires controllers and processors to implement a level of security appropriate to the risk. The required measures depend on the state of the art, implementation costs, the nature, scope, context and purposes of processing, and the likelihood and severity of risks. A general promise of security without usable evidence is weak in a review.

Do not request every conceivable document automatically. Define which evidence is needed for the concrete processing, how long it remains current and who evaluates deviations. This connects with privacy governance and prevents contracts and controls from being managed separately.

Where a processor engages another processor, Article 28(2) and (4) GDPR apply. The controller may provide specific authorisation or general written authorisation with information about planned changes. With general authorisation, the controller must have the opportunity to object to changes.

In practice, the chain should not end with a link to an online list that changes without a usable process. The business needs a current view, a responsible function, a notice route and a decision on what happens after an objection. Location, access possibilities and transfers to third countries also require attention.

The first processor must impose essentially the same data protection duties on the further processor. If the further processor fails to meet its duties, the first processor remains responsible towards the controller for compliance with those duties.

The review does not end when the agreement is signed. The controller must continue to direct the processing and request evidence or audits where appropriate. The processor must provide the agreed assistance and may not use the data outside the instruction framework.

A workable control model connects risk, trigger and evidence. For lower-risk processing, current self-assessments and spot checks may be enough. Sensitive data, large volumes, critical systems or cross-border chains may require deeper review. Record scope, result, deviation and follow-up measure.

New software, new purposes, a change of subprocessors, a security incident or a material contract change should trigger a new review. An incident process must also explain how the provider informs the controller without undue delay. The focus page on personal data breaches explains the joint response.

Many problems arise because the provider is treated as a purely technical matter. The following mistakes can be reduced through clear ownership and a shared process.