An accounting office connects a cloud system to run clients' books and signs only the vendor's terms of service — nobody on either side asks about a data processing agreement. That's a short road to an administrative fine, because clients' data (names, IDs, accounting documents) ends up in an external system without a formal basis.
This page walks through a real penalty case for missing such an agreement, lists what a data processing agreement must contain, and explains where a vendor's terms of service end and the administrator's legal duty begins.
The situation: a new software vendor, only terms of service signed
Rolling out a new accounting or CRM system at an accounting office usually looks the same: someone opens an account, clicks "I accept the terms" and moves on to setup. The terms describe how the service works and what it costs — they don't describe on what legal basis the vendor will process the office's clients' data, which lands in its system together with invoices, ledgers and reports.
The problem usually surfaces not during rollout but during an audit or a complaint — when it turns out nobody checked whether the vendor can legally process that data at all.
A 2.5 thousand zloty fine: entrusting data without a written agreement and without checking the vendor
The Polish data protection authority (UODO) fined an entity 2.5 thousand zloty for entrusting the processing of personal data (including bookkeeping, records and reports) to another entity without a written data processing agreement and without checking whether that entity provides sufficient data-protection guarantees (UODO, Entrusting data processing must be documented). In other words: the vendor operating legally and having a good reputation doesn't remove the duty to put an agreement in writing and check the vendor before signing.
What a data processing agreement must contain
Per the same source, a data processing agreement specifies, among other things, the subject and duration of processing, its nature and purpose, the type of personal data and the categories of people whose data it concerns, plus the administrator's duties and rights (UODO, same page). Missing even one of these elements is grounds to call the document incomplete — and in an audit, what matters is what's actually written in the agreement, not what both sides "understood in practice".
What's at stake without it
The consequence of missing a data processing agreement and skipping the vendor check is an administrative fine — exactly the kind UODO issued in the case described above. Whether a specific office's situation qualifies as a violation, and how large a fine it would realistically face, is for a lawyer or a data protection officer to assess, not for the office owner alone.
Checking the vendor before signing — not on trust
Signing a data processing agreement alone isn't enough if nobody first checked whether the vendor actually provides sufficient technical and organisational guarantees — UODO pointed to exactly that missing check as the second element of the violation, alongside the missing agreement. In practice, that means asking the vendor to describe its security measures before choosing it, rather than taking "everything here is secure" on trust.
A vendor's terms of service is not a data processing agreement
The terms you accept when opening an account govern the commercial relationship — pricing, service availability, limits on the vendor's liability. A data processing agreement is a separate document governing the administrator–processor relationship under data protection law. One doesn't replace the other, even if the vendor claims "the terms cover that" — the fine described above was issued precisely in a case where a formal data processing agreement simply didn't exist.
When the vendor uses another subcontractor
Sometimes a software vendor itself relies on another entity for part of the processing — external hosting, for instance. Before signing, it's worth asking directly whether the vendor plans such further sub-processing and under what terms it discloses it. That's one question worth asking before signing, not something to discover by accident later.
What to check before data goes further
If the vendor's answer is "yes, we use a subcontractor", it's worth asking whether that fact is written into the data processing agreement itself, not just mentioned verbally. A document missing that is the same kind of gap that led to the fine described above.
Deleting data after the relationship ends versus the duty to keep it
After ending a relationship with the office, a client can request that their data be deleted. Under Article 17 GDPR, an administrator must delete data when, among other cases, it's no longer needed, when consent has been withdrawn and no other basis applies, after an objection to direct marketing, when processing is unlawful, or when the law requires it (UODO, The right to erasure in practice). A response to such a request should come without delay, no later than within a month; if the matter is complex, the deadline can be extended by another two months, with notice given before the first month is up (UODO, same page).
When an administrator can refuse deletion
The same source notes that the right to erasure isn't absolute: an administrator can refuse when the data is necessary to comply with a legal obligation — and the duty to keep accounting records under the accounting act is exactly that kind of case — or to establish, exercise or defend legal claims (UODO, same page). That means a client's deletion request and the duty to keep their accounting documents for a set period can collide, and deciding a specific case — whether and to what extent to refuse — is worth checking with a lawyer or a data protection officer.
Both the administrator and the processor are responsible for protecting personal data — that's a general principle stated directly by UODO (UODO, notice of 21 July 2025), so an accounting office's responsibility as administrator doesn't disappear just because the data physically sits with the vendor.
Do it yourself: a checklist before connecting a new vendor
Before anyone at the office clicks "I accept" on a new system, it's worth going through the five points below:
| Question for the vendor | Why check it |
|---|---|
| Is there a signed written data processing agreement? | Without one, entrusting data is undocumented |
| Does the agreement specify the subject, duration, data type and categories of people? | UODO treated missing these as a violation |
| Has the vendor described its security measures? | A claim without a description isn't enough to call it checked |
| Does the vendor disclose using subcontractors? | Further sub-processing without the administrator's knowledge is added risk |
| When is the annual review of the agreement scheduled? | Agreements age; the scope of a vendor relationship changes |
10 / 40 = 0.25, or 25% of vendors having their documentation in order — the rest need work before an audit finds them.A simple order looks like this:
- List every vendor with access to the office's client data.
- For each one, check whether a written data processing agreement exists and covers the required elements.
- Ask about security measures and subcontractors wherever an agreement is missing or incomplete.
- Set an annual review date for each agreement.
- Log the review result — even a short note — instead of relying on memory.
When a system runs this process
The same checklist can be run manually in a spreadsheet, but it's easy to lose track of one agreement's review date among dozens of others:
- 01New vendor
- →02checklist completed
- →03agreement checked
- →04review date set
At Aura, this process runs through CRM and automations together with tasks with a deadline and an assigned person (Tasks): a new vendor enters the system, a task with a deadline reminds about the annual agreement review, and the review result is logged against the same vendor. The system doesn't decide on its own whether a given agreement meets GDPR requirements — that's still a decision for the person responsible at the office, ideally with a lawyer involved. What the system does is track the deadline and pass the task along before the review gets forgotten:
- 01New vendor in the system
- →02task with a deadline
- →03reminder before review
- →04agreement verified
- →05status logged
If vendor and agreement data lives in several places at once — a spreadsheet, an inbox, an accounting system — keeping it consistent is a job for integrations between systems (Integrations), and if a vendor exposes data of its own through API access to data (API), it's worth knowing exactly what goes out and to whom. The office's own clients, whose data reaches the vendor this way, are easier to track as customer data in one place (Customer Data) instead of five scattered lists. More on where client data physically ends up during automation is covered in automation and GDPR, and what can realistically be handed to a system, and what can't, in process automation.
When you actually need a lawyer to check the agreement
Assessing whether a specific vendor's agreement meets GDPR requirements in your situation is a job for a lawyer or a data protection officer, not something to settle alone over coffee in fifteen minutes. The office owner can prepare the checklist and collect documents from the vendor — the final compliance judgment is best left to someone who does this professionally.
How much such automation actually costs a company depends on scope — the 2026 ranges and what changes them are covered in how much does process automation cost. Before settling on a specific tool, it's also worth checking where to even start tidying up processes in a small company — four thresholds instead of a general analysis are covered in where to start automation in a small business.
Frequently asked questions
How is a data processing agreement different from terms of service?
Terms of service govern the commercial relationship with a vendor — price, availability, limits on the vendor's liability. A data processing agreement is a separate document governing on what basis the vendor may process the office's clients' personal data. One doesn't replace the other.
What exactly must a data processing agreement contain?
Per UODO, a data processing agreement specifies, among other things, the subject and duration of processing, its nature and purpose, the type of personal data and the categories of people it concerns, plus the administrator's duties and rights.
Is a vendor's good reputation enough instead of checking it?
No — in the case described above, UODO fined the entity precisely for not checking whether the vendor provided sufficient data-protection guarantees, regardless of how reputable the vendor seemed.
Can a client demand their data be deleted after the relationship with the office ends?
Yes, but the administrator can refuse if the data is necessary to comply with a legal obligation — for example, the duty to keep accounting records under the accounting act. A specific situation is worth checking with a lawyer or a data protection officer.
Who is responsible if the vendor causes a data protection breach?
Both the administrator (the office) and the processor (the vendor) are responsible for protecting personal data — a general principle stated by UODO, regardless of which side the actual mistake happened on.
How often should data processing agreements with vendors be reviewed?
Once a year — a simple rhythm that catches whether the scope of a vendor relationship has changed and whether the agreement still matches what actually happens with client data.