Processor or independent controller
The first question is not what the contract is called, but which role the vendor actually takes. A controller is the party that decides on the purposes and means of processing; a processor processes personal data on behalf of that controller. With a monitoring or analytics tool the website operator usually decides: which addresses are checked, at what interval, how long the measurement series are kept and who sees the evaluation. The vendor supplies the technology and executes. That is exactly the constellation Article 28 describes. A tool that measures without touching device storage changes nothing about this: analytics without cookies still processes data that can usually be related to a person.
The role can flip. A processor that infringes the regulation by determining the purposes and means of processing itself is considered a controller in respect of that processing (GDPR). In practice this shows up in the wording of the contract documents: a vendor that reserves the right to use its customers' data to improve its own products, to build cross-customer benchmarks or to train its own models is processing for its own purposes to that extent. For that part the vendor carries the responsibility itself, and the processing agreement does not cover it. It is worth reading the vendor's terms of use and privacy notice with this in mind, not only the contract text.
- Visitor data from analytics - the address requested, the referrer, the timestamp, screen width, language and, depending on the setting, the truncated IP address.
- Screenshots from change monitoring - as soon as an area behind a login is captured, names, order numbers or mailbox contents typically end up in the image.
- Response bodies from API checks - anyone who stores the full response for debugging also stores whatever that response contains.
- Form data from browser checks - a test purchase or test registration creates records that resemble a real person or concern one.
- Contact details of alert recipients - name, email address, phone number and on-call times of your own staff.
- Access logs of the tool itself - who signed in when, which setting was changed, from which address.
That leaves two groups of data subjects, and both belong in the contract: the visitors of the monitored website and your own staff who operate the tool or receive alerts. The second group is often overlooked even though it is the more sensitive one: employee data is watched closely, and a log of who saw what and when is a record of behaviour. How roles, permissions and logs can be cleanly separated inside the tool itself is covered in access control and audit trails in monitoring.
The frame that comes before the eight points
Before Article 28(3) lists the eight individual obligations, its opening sentence requires determinations of its own: the subject matter and duration of the processing, the nature and purpose of the processing, the type of personal data, the categories of data subjects, and the obligations and rights of the controller (GDPR). These are not a preamble but the frame of reference: they define what every instruction, every deletion duty and every piece of evidence later refers to. A contract that gets by here with "provision of the contractually agreed services" has not set the frame.
For monitoring these points are easy to fill in. The subject matter is measuring availability, response time and content integrity of named addresses plus reach measurement. The duration is the term of the contract plus the agreed retention periods. Nature and purpose are the automated retrieval, storage and evaluation of measured values to evidence availability and detect incidents. The type of data is the list from the previous section. The categories of data subjects are website visitors and the controller's own staff. And the obligations and rights of the controller are its right to instruct, its right to audit, and its duty to issue lawful instructions only.
The contract must be in writing, including in electronic form (GDPR). A versioned contract text stored in the customer account and retrievable at any time satisfies that form. What matters is less the medium than the traceability: which version applied on the day of the processing, who accepted it and when, and is it still available if a supervisory authority asks two years later. A contract that only exists as an email attachment meets the form requirement but may well not be findable when it is needed.
The eight points of Article 28(3)
The opening sentence is followed by eight points from (a) to (h), and each of them is a separate obligation the contract has to stipulate (GDPR). They cannot be merged and cannot be replaced by a reference to the regulation. In short form:
- (a) Documented instructions - the processor processes only on documented instructions from the controller, including transfers to third countries.
- (b) Confidentiality - persons authorised to process the data have committed themselves to confidentiality or are under a statutory obligation of confidentiality.
- (c) Security - all measures required pursuant to Article 32 are taken.
- (d) Sub-processors - the conditions for engaging another processor are respected.
- (e) Data subject rights - the controller is assisted in responding to requests from data subjects.
- (f) Security, breaches, assessments - the controller is assisted in complying with Articles 32 to 36.
- (g) End of the service - the data is deleted or returned at the choice of the controller.
- (h) Evidence and audits - all necessary information is made available and audits are allowed for.
This list is the minimum content, not the ceiling. It does not yet explain how the obligation is met in daily practice - and that is exactly where many contracts fail. A sentence such as "the processor assists the controller in fulfilling data subject rights" repeats point (e) without answering a single question: by which route, in which format, within what time?
In its Guidelines 07/2020 the European Data Protection Board states explicitly that the processing agreement should not merely restate the provisions of the regulation but should include more specific, concrete information on how the requirements will be met and which level of security is required for the processing concerned (European Data Protection Board). For reviewing a draft contract this is a usable quick test: if a paragraph would fit a payroll service or a newsletter dispatch unchanged, it does not describe the processing at hand.
From the legal text to the contract annex
It has proved practical to keep the contract text short and move the changeable parts into annexes: one annex for sub-processors, one for the technical and organisational measures, one for the deletion policy. Annexes can be updated individually without re-signing the main contract, and they are the place where an obligation turns into a verifiable commitment. The table below sets each obligation against what the annex should say so that it holds up in a dispute.
| Point | What the regulation requires | What the annex should say |
|---|---|---|
| (a) | Processing only on documented instructions | Who may issue instructions, in which form they are recorded, at which locations the check nodes run |
| (b) | Confidentiality of authorised persons | Commitment of staff, applicability to sub-processor personnel, evidence on request |
| (c) | Measures pursuant to Article 32 | The measures actually in place instead of a reference to the state of the art |
| (d) | Conditions for engaging another processor | Type of authorisation, notice period for changes, route for objections, list with location and task |
| (e) | Assistance with data subject requests | Search and export function, vendor response time, format of the disclosure |
| (f) | Assistance with Articles 32 to 36 | Reporting route for a breach, minimum content of the report, input for the impact assessment |
| (g) | Deletion or return after the end of the service | The choice exercised, export format, deadline, handling of backups, confirmation |
| (h) | Making information available and allowing audits | Which documents are available without asking, how often audits may take place, remote or on site |
Two rows of this table tend to be the contested ones. On point (c) vendors lean towards general security promises; on point (h) the audit right is often narrowed to an annual certificate. Both are negotiable, but only before signature. Anyone who requests the annex once a supervisory authority is already asking negotiates under time pressure. How the Article 28 requirements interlock with the remaining documentation duties is set out in the overview of GDPR compliance in monitoring.
Sub-processors: authorisation, list, objection
A processor must not engage another processor without prior specific or general written authorisation of the controller (GDPR). Both routes are permitted. With specific authorisation every sub-processor is approved individually, which becomes impractical fast for a tool with check nodes in several countries. With general authorisation the vendor has to inform the controller of intended changes, and the controller can object. The European Data Protection Board makes clear that the mere publication of such modifications on the processor's website does not comply with Article 28 (European Data Protection Board). So an active notice to a named address is required, not just a page that changes quietly.
According to Guidelines 07/2020 the list of intended sub-processors has to state, for each of them, their location, what they will be doing and proof of the safeguards implemented, so that the controller can decide at all (European Data Protection Board). A list of company names without those three items does not support that decision.
With distributed checks every location is a place of processing. Anyone measuring availability from several locations should know which data centres are involved and whether a transfer to a third country takes place.
The path from alert to message runs through a mail or messaging service that processes recipient data along the way. The same question arises for confirmation emails, as described in the article on monitoring the double opt-in flow.
The period should be long enough to review a change and, if necessary, to terminate. When a vendor retires an interface, the same timing problem applies as with Sunset and Deprecation headers: without lead time, agreement is the only option left.
When a sub-processor is added, the same data protection obligations as set out in the contract with the controller have to be imposed on it. Where that other processor fails to fulfil its obligations, the initial processor remains fully liable to the controller for the performance of that other processor's obligations (GDPR). For the controller this means the chain ends at the direct contract partner, but it does not end at the question of where the data actually sits. Anyone who has to vet service providers under other rules anyway can combine the evidence; the article on supply chain evidence for service providers describes the overlaps.
The record of processing activities
The contract is one half of the accountability duty, the record is the other. The controller maintains a record of processing activities under its responsibility, and it contains seven items from (a) to (g): contact details, purposes, categories of data subjects and of personal data, categories of recipients, third country transfers, erasure time limits and a general description of the measures under Article 32 (GDPR). The processor maintains its own record with four items from (a) to (d) (GDPR). Anyone who separates the two cleanly notices quickly which details they need from the vendor and do not have today.
{
"name": "Availability and reach measurement of the company website",
"controller": "Example Ltd, Musterweg 1, 30159 Hannover",
"purposes": [
"Evidence of availability towards customers",
"Detection of outages and security incidents",
"Reach measurement without access to device storage"
],
"subjects": ["Website visitors", "Staff of the controller"],
"data": [
"truncated IP address",
"timestamp, requested address, referrer",
"browser screen width and language",
"name, work email address and phone number of alert recipients"
],
"recipients": [
{"role": "processor", "service": "monitoring and evaluation"},
{"role": "sub-processor", "service": "delivery of alert messages"}
],
"third_country": null,
"retention": {
"measurement_series": "13 months",
"screenshots": "90 days",
"access_log": "6 months"
},
"measures": "see annex 2 to the data processing agreement",
"as_of": "2026-09-27"
}
The record duty knows an exemption for organisations with fewer than 250 employees, but it only applies where the processing is not likely to result in a risk to the rights and freedoms of data subjects, is occasional and does not include special categories of data (GDPR). A website that measures continuously is not processing occasionally - the exemption usually does not carry here. Whether a data protection impact assessment is additionally required is a separate test; the article on the impact assessment for web tracking lists the thresholds.
A processing agreement is rarely read at signature and typically on a bad day: when an access request arrives, when a sub-processor changes, or when someone has to explain where the last eighteen months of data are stored.
— XICTRAQ
Technical and organisational measures
Point (c) refers to Article 32, and that article names four measures explicitly: the pseudonymisation and encryption of personal data, the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems, the ability to restore availability quickly after an incident, and a process for regularly testing the effectiveness of the measures (GDPR). The enumeration is not exhaustive, but it provides the structure for the annex. What should be in it for a monitoring service:
- Encryption in transit and at rest, each stating what exactly is encrypted - measured values, screenshots, backups.
- Tenant separation: how it is prevented that data from two customers ends up in one evaluation.
- A role and permission concept with named roles, plus the question of who at the vendor can see customer data during an incident.
- Access logging, with a retention period and a statement of who may evaluate the logs.
- Backup procedures including a documented restore test, not only the backup itself.
- Pseudonymisation wherever possible: truncated IP addresses, identifiers without personal reference, masking in screenshots.
- Deletion routines per data type with the same deadline that appears in the record, so that the two documents do not drift apart.
- Regular testing of effectiveness with an interval and a responsible person, so that the fourth measure in Article 32 does not stay empty.
Every line of the annex comes with the question of how you would recognise that it is implemented. For encryption it is the configuration, for the permission concept the role list, for the restore test the log of the last run. On your own side the evidence is often easier than it sounds: anyone who assigns roles and team access cleanly and logs the changes can support the statements on point (b) and on the permission concept at any time, without reconstructing them.
Reporting routes and deadlines after a breach
The controller notifies a personal data breach to the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it (GDPR). The processor has no deadline of its own towards the authority, but it notifies the controller without undue delay after becoming aware of a breach (GDPR). The controller's clock therefore effectively starts at the vendor, and that is exactly why the contract has to say what "without undue delay" means here: which address the report goes to, which details the first report contains as a minimum, and how a follow-up report is filed when the facts are not yet complete.
Such queries do not replace a contract review, but they answer three questions that contracts often leave open: where do the names of the check nodes point, which address does the tracker deliver to, and when was the sub-processor list last changed. A list whose date has been unchanged for eighteen months is either stable or unmaintained - both are worth asking about. The date is also worth a look at the time zone: reporting deadlines and logs drift apart when one side counts in UTC and the other in local time, as the article on daylight saving time in monitoring shows.
Send one test report through the route named in the contract and measure how long it takes to get an answer. Experience shows that this single attempt uncovers at least one break: an address pointing to an abandoned mailbox, a form behind a login nobody on the team has, or a responsibility that is only staffed during the vendor's business hours. The result belongs with the contract as a note, with a date.
End of contract: delete or return
Point (g) requires the processor, at the choice of the controller, to delete or return all personal data after the end of the provision of services, unless storage is required by law (GDPR). The choice lies with the controller, and it wants to be exercised: leaving it open hands the decision to the vendor. It makes sense to make the choice in the contract and to add three points the regulation does not mention: the format of the return, the deadline, and the handling of backups, which follow their own cycle and cannot be deleted individually on request.
The export belongs before the termination, not after it. An account that is locked on the cut-off date usually does not hand out data any more, and evidencing availability for the past year is hard without raw data. Which retention periods make sense for which data type, and where retention duties and deletion duties diverge, is covered in the article on retention periods for monitoring and analytics data. At the end there should be a written deletion confirmation with date and scope, filed together with the contract.
What an infringement costs and who is liable
Infringements of the obligations of controllers and processors under Articles 8, 11, 25 to 39, 42 and 43 are subject to administrative fines of up to 10 000 000 euros or, in the case of an undertaking, up to 2 per cent of the total worldwide annual turnover of the preceding financial year, whichever is higher (GDPR). Article 28 sits in that band. When deciding whether to impose a fine and on its amount, eleven criteria from (a) to (k) are taken into account, among them the nature and gravity of the infringement, the degree of responsibility, previous infringements and the degree of cooperation with the supervisory authority (GDPR).
Next to the fine sits compensation. A processor is liable for the damage caused by processing only where it has not complied with obligations specifically directed to processors or where it has acted outside or contrary to lawful instructions of the controller (GDPR). The split therefore is not fifty-fifty but follows the role. Which mistakes most often lead to proceedings in practice is put in context in the article on avoiding GDPR fines.
A signed processing agreement is an obligation, not a liability waiver. The controller remains answerable to data subjects and supervisory authorities even where a vendor performs the processing technically. What the contract delivers is the allocation of duties, the ability to audit, and a workable recourse when the vendor does not keep its commitments. Treating it as proof that the duty to vet is now discharged misses its purpose.
What to settle before the first check runs
The ten points below can be asked before setting anything up, usually with a single message to the vendor. They are not legal advice but a pre-check: anyone who gets them answered already holds parts of the draft contract, the record entry and the answer to the first authority enquiry.
- Is there a data processing agreement, is it retrievable without asking, and which version applies today?
- Which annexes belong to it, and are measures, sub-processors and retention periods named individually in them?
- Where is the data processed and stored, and does a transfer to a third country take place?
- How are sub-processors authorised, how are changes announced, and how long is the period for objecting?
- Which types of data actually arise, in particular with screenshots, response bodies and browser checks?
- Does the vendor also process data for its own purposes, for example for cross-customer evaluations?
- Through which route and with what minimum content does the vendor report a personal data breach?
- Which functions support answering requests from data subjects, and in which format does the disclosure arrive?
- Which retention periods apply per data type, how is data exported at the end, and is there a deletion confirmation?
- Which evidence does the vendor provide for point (h), and how does an audit proceed?
Once those points are settled, the rest is routine: file the contract, write the record entry, set the retention periods in the tool, name the responsibilities. XICTRAQ processes and hosts in Germany, provides the data processing agreement together with a sub-processor list and documented measures, and exports the details that belong in the record of processing activities; the demo shows without an account which data arises in the first place. How an access request is answered with that data is described in the article on access requests under Article 15.
This article draws on Regulation (EU) 2016/679 (General Data Protection Regulation), in particular Articles 28, 30, 32, 33, 82 and 83 in the version published via EUR-Lex, and on Guidelines 07/2020 of the European Data Protection Board on the concepts of controller and processor. The references in the article point to the paragraph of the norm or the margin number of the guidelines. It does not replace legal advice in an individual case; whether a specific processing is processing on behalf of a controller depends on the circumstances.