Art. 28(1) GDPR: “sufficient guarantees”. What the controller must check before deploying a SaaS application, and what point (h) allows afterwards

Paragraph 1 in the text's own words: a duty before the contract

Art. 28(1) GDPR reads: “Where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject.”

The subject is the controller, the verb is “shall use only”. The provision does not say what must be in the contract; paragraph 3 does that. It says whom the controller may work with at all: only processors “providing sufficient guarantees”. Whether a provider offers those guarantees must be established before it is engaged. A contract with a provider that does not offer them does not cure the breach of paragraph 1, because paragraph 1 governs the selection and not the agreement.

Anyone introducing a SaaS application in which personal data are processed therefore has to perform this check before ordering, not at signature and not at the first audit. The wording names no form. It requires the guarantees to be “sufficient”, and that can only be judged if somebody has looked at them.

Paragraph 3(h) in the text's own words: a duty after the contract

Paragraph 3 lists what the contract must stipulate. Point (h) obliges the processor to “make available to the controller all information necessary to demonstrate compliance with the obligations laid down in this Article and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller”.

Three things follow. First: after the contract is concluded, the controller has a right to information and to audits, and the processor must “allow for” and “contribute to” both. Second: the audit may be conducted by a mandated auditor; the controller need not carry it out itself. Third, from the second subparagraph: the processor “shall immediately inform the controller if, in its opinion, an instruction infringes this Regulation”. The audit right is not an invitation; it is the mechanism by which the guarantees under paragraph 1 are followed up during use.

Before and after, in the file

The two duties are separated in time and leave different records. Before deployment: a documented check of which guarantees the provider offers, dated before the engagement, with the decision that they are sufficient. After deployment: the information the provider made available under point (h), the audits carried out, and their results. A controller who can only produce the signed contract has evidenced paragraph 3 and left paragraph 1 and point (h) open.

What the audit templates in CIVAC ask for

The CIVAC workspace contains, for the data protection officer role, two built-in audit templates that cover exactly these two moments. Their fields are in the code, and they are instructive because they show what “sufficient guarantees” means in practice as questions.

Template “Cloud Provider Audit” (tpl-audit-vorlage-cloud-anbieter)

• Certifications: ISO 27001 valid, SOC 2 Type II report, BSI C5 attestation, certification expiry date.
• Data location and encryption: processing exclusively in EU/EEA, encryption at rest, encryption in transit, customer key management.
• Tenant isolation and incident response: logical tenant isolation verified, breach notification SLA in hours, transparency report available, assessment notes.

That is the check under paragraph 1, as a questionnaire. Each field is a circumstance from which guarantees can or cannot be derived, and the certification expiry date is the reason this template is opened again after deployment.

Template “DPA Compliance Audit” (tpl-audit-vorlage-avv-compliance)

• Contractual framework: DPA signed, subject and duration defined, data categories and subjects specified, instruction binding regulated.
• Technical and organisational measures: TOM annex attached, TOM adequacy, last TOM update, TOM notes.
• Subprocessors and audit rights: subprocessor list complete, approval mechanism for new subprocessors, audit rights secured, deletion obligation regulated, findings.

This template does not check the contract text but whether what the contract promises is being kept: whether the subprocessor list is still correct, whether the TOM annex is still current, whether the audit right under point (h) was actually secured and exercised. That is the audit under point (h), as a criteria catalogue. Alongside it, the template collection for the information security officer role carries a “Supplier audit (Cloud)” for new SaaS providers on the basis of BSI C5 and ISO 27001 and an audit for the “Introduction of a new tool”; both sit before deployment.

What the workspace does not do: it does not itself test whether the provider encrypts or whether its tenant isolation holds. It records that somebody asked the questions, which answers were received, what was concluded from them and when the next review is due. The judgement whether the guarantees are “sufficient” is made by the controller, advised by its data protection officer under Art. 39(1)(a) GDPR.

Where this article ends

Whether a particular provider's guarantees are “sufficient” for your processing within the meaning of Art. 28(1) GDPR, in what scope and at what interval audits under paragraph 3(h) are appropriate, and whether a provider refusing an inspection is in breach of the contract are questions that require a legal examination of the individual case. CIVAC is not a law firm and does not provide legal advice. This article reproduces the wording of the Regulation and the fields of two templates; the assessment of your case belongs with your data protection officer or with someone authorised to give it.

Frequently asked questions

Is a signed data processing agreement enough for Art. 28(1) GDPR?

No. The contract is the subject of paragraph 3. Paragraph 1 requires the controller to use only processors providing sufficient guarantees, and that must have been checked before the provider is engaged.

Does the controller have to inspect the provider on site in person?

Art. 28(3)(h) GDPR speaks of audits “including inspections, conducted by the controller or another auditor mandated by the controller”. The audit can therefore be delegated. Whether an on-site inspection is necessary or whether information and reports suffice depends on the individual case and is not in the wording.

Is a provider's certificate enough as a sufficient guarantee?

Art. 28(5) GDPR provides that adherence to an approved code of conduct under Art. 40 or an approved certification mechanism under Art. 42 “may be used as an element by which to demonstrate sufficient guarantees”. An element is one building block of the check, not its replacement, and Art. 42(7) limits the term of a certification to a maximum of three years.

What about the provider's subprocessors?

Art. 28(2) GDPR requires, for every other processor, the prior specific or general written authorisation of the controller, and in the case of general authorisation, information about any intended change with the opportunity to object. The completeness of that list is therefore a separate check field in the DPA template.

How often is the audit under point (h) to be repeated?

The Regulation names no interval. Two triggers follow from the text itself: the expiry date of a certification on which the guarantees rest, and any change of subprocessors under Art. 28(2). Everything beyond that is a question of risk and of the individual case.