How much do you have to check on a processor? — the Danish DPA’s point scale and six supervision concepts

Published by

Datatilsynet, the Danish Data Protection Agency, the supervisory authority for Denmark. The DPA’s release records that the guide was developed with input from its stakeholders. We have no relationship with Datatilsynet and inclusion here is not an endorsement in either direction.

Type

Practical guidance with an indicative model: list your processors and check each has a data processing agreement; a point scale (A–D) for how risky the processing is; what to supervise — the requirements in the Art. 28 agreement; six supervision concepts, each with a worked example; how often; and who supervises sub-processors. The companion on the DPA’s templates page is its Art. 28 data processing agreement template, available in Danish and in an English version.

Versions & language

October 2021; 26 pages. Listed as “Vejledning om tilsyn med databehandlere (oktober 2021)” in Datatilsynet’s A–Z list of guidance — we found no later edition. Danish only — we found no English translation on datatilsynet.dk. Summarised in English on this page; the original is linked.

Jurisdiction

Denmark. The obligations are GDPR Art. 28(1) (sufficient guarantees), 28(3)(h) (audits and inspections) and 28(2) and (4) (sub-processors), which UK GDPR carries in the same terms, so the method reads across. The illustration does not: the point thresholds (under 1,000 / 1,000–10,000 / over 10,000 people), the Danish examples and the Danish notion of “other confidential data” — which the guide anchors in Danish criminal and administrative law — are the DPA’s indicative scale for Danish controllers, and the guide says so. UK position: the ICO’s guidance Contracts and liabilities between controllers and processors is the UK reference for the contract terms and the audit right; the ICO currently flags that guidance as under review following the Data (Use and Access) Act 2025. A UK programme builds its own thresholds against that guidance and its own risk assessment.

Primary audience

Whoever owns processor oversight: DPOs and privacy teams, procurement and vendor-management functions, information security, and the internal audit teams asked to evidence that “we audit our processors” means something specific.

Topic tags

processors · Art. 28 · vendor management · third-party risk · audits · sub-processors · ISAE 3000 · certification · codes of conduct · accountability

Availability

Free PDF from datatilsynet.dk, no registration. The Art. 28 agreement template is a free Word download (Danish and English) from the DPA’s templates page.

Why it matters

The guide’s first move is to say what risk it means. In its words, when it comes to data protection it is not the risk that you — as a business or an authority — end up in trouble; it is the risk to the registered persons (employees, customers, citizens) that you must keep in view. Everything downstream scores that risk, not yours.

The point scale

Four questions, added together, to a maximum of ten.

• A — how many people? Under 1,000: 1 point. 1,000–10,000: 2. Over 10,000: 3. Count only the people whose data goes to this processor — the payroll bureau scores on your employees, the customer-analytics vendor on your customers.
• B — special categories (Art. 9)? Yes: 3 points. The guide’s examples are a union’s newsletter processor (membership is itself trade-union data) and an HR system that holds sickness records.
• C — other data that most people would want kept from others? Yes: 2 points — but only where you routinely entrust such data, not where a customer volunteers a national ID number once. The guide’s Danish examples include personnumre, protected names and addresses, exam grades, disciplinary sanctions, personality tests, debt registrations, and data about criminal offences.
• D — is the processing itself intrusive? Yes: 2 points. The guide’s examples are location tracking, systematic monitoring, profiling, solely automated decisions with legal or similar effect, and data matching beyond what people would reasonably expect — and it points to the DPA’s list of processing operations that always require a DPIA as a cross-check.

The six supervision concepts

In rising order of effort. Whichever you land on, the guide says the floor is an Art. 28 agreement that meets the minimum requirements; that is not a concept, it is the entry condition.

1. Do nothing unless you become aware something is wrong — press, audit reports, your own breach experience — then contact the processor and keep the correspondence. The guide conditions this on a credible and reputable processor.
2. Confirmation from the processor, preferably in writing, that every requirement in the agreement is still met.
3. An annual written status from the processor, direct or via its website, covering everything it does for you (including through sub-processors), any special requirements you agreed (encryption of all traffic, deletion dates for test data), and — asked for explicitly — the personal data breaches it has had since your last supervision.
4. A current certification (Art. 42) or an approved code of conduct (Art. 40) covering your processing — with the controller checking that the scheme actually covers the Art. 28 requirements and any special terms, and asking separately about anything it does not.
5. A documented supervision by an independent third party — an assurance report such as ISAE 3000, an industry body auditing on behalf of members, or an auditor mandated jointly by several controllers. The guide’s conditions: the audit covers your processing, tests compliance with the agreement including special terms, looks at sub-processors, and the auditor is independent of the processor. At 7–10 points, the guide says to choose the report that gives “high assurance”.
6. Your own documented supervision, alone or jointly with other controllers — scoped by a risk assessment of what could go wrong for the people concerned, and carried out, for example, by a written questionnaire with follow-up.

The worked examples run the scale: a hairdresser’s online booking system (concept 1); a webshop’s card-payment provider, checked every second year by written confirmation (concept 2); a state body’s outsourced HR system with 200 employees’ sickness data (concept 3); a retailer’s beacon-tracking vendor for 15,000 app users, certified, checked every second year (concept 4); a GP practice whose journal system is audited annually by an industry association (concept 5); and a municipality’s building-case processor holding 30,000 citizens’ data, audited jointly with other municipalities (concept 6). The guide is explicit that the concepts combine — concept 5 every second year with concept 3 in between is its own example — and that you may go higher than the score suggests, for instance after a breach at the processor, or, where the processor does not offer what the lower concept needs, either require it or move up a concept.

Frequency, and sub-processors

Possibly annual where the processing is critical for the people concerned; less often where the risk is low. The guide names what pushes frequency up — the processor has struggled to honour agreements (not only the data processing agreement), several serious security incidents, frequent changes of sub-processor, and changes of ownership, mergers or strategic shifts, which it notes can move a supplier’s priorities and lose focus during migration — and what argues for an extra supervision outside the normal cycle: an ownership change, or a change in the way of working such as a pandemic sending staff home. Long, stable experience with a processor, and no incidents or only a few minor ones, argue for a lower frequency.

On sub-processors: the processor supervises its sub-processors; the controller makes sure that it does, for example by receiving the processor’s documentation of the supervision it performed. A sub-processor need not land at the same point on the scale as the processor, because the slice of processing it holds may be smaller and less intrusive.

Done proportionately, supervision built this way serves both sides. The organisation spends its assurance effort where the data and the intrusion are, can show an auditor or a regulator why it checked one processor every second year and another every year, and spends less on reports that do no work for it. The people whose data it is get scrutiny in proportion to what could go wrong for them, which is the measure the guide starts from. The aim here is not to hand anyone a supervision programme; your processors, your data and your thresholds are yours to set and to defend. It is to point at a regulator that has written the method down, and we hope you find it useful.

Read alongside the EDPB’s Opinion 22/2024 on certain obligations following from the reliance on processor(s) and sub-processor(s), adopted 7 October 2024 at the Danish DPA’s request, which sets the principle this guide operationalises: the controller must verify the processor’s guarantees, with the depth of verification scaling to the risk, and must be able to identify every processor and sub-processor in the chain. On the Hub, the CNIL Practice Guide — Security of Personal Data from issue #6 is where the security measures a concept-6 questionnaire would ask about are written down; the AEPD Risk Management and DPIA guide from issue #4 covers the risk assessment a concept-6 supervision is scoped from; and the Danish DPIA templates from issue #4 come from the same authority.