This article covers why there is no statutory expiry, what actually invalidates consent, the evidential problem with old records, how to think about refreshing, and the case where consent was the wrong basis from the start.

There Is No Expiry Date In The Regulation

Search for a number and you will find twelve months, twenty-four months, and confident statements that consent must be refreshed annually. None of these comes from the GDPR. Article 7 sets conditions for consent and says nothing about duration.

What does exist is a strong expectation that consent remains current. Regulators consistently advise reviewing consents and refreshing them where anything material has changed, and the accountability principle in Article 5(2) requires you to be able to demonstrate the consent you are relying on is valid — present tense. How consent is collected, recorded, versioned and withdrawn in the first place is the consent management guide's subject; this article is only about what happens to it afterwards.

The distinction matters practically. A fixed expiry gives you a rule to follow and a false sense of safety, because consent collected badly is invalid on day one and consent collected well for unchanged processing does not spoil at month thirteen. Ageing is a poor proxy for the thing that actually goes wrong.

What Actually Stops Consent Being Valid

Four things, none of them time.

The purpose changed. Consent is specific to the purposes described when it was given. Adding a new use for the data means the existing consent does not cover it, whether that happened last week or three years ago.

The scope crept. More data types, new recipients, a new subprocessor category, a transfer to a country that was not in the picture. Each takes the processing outside what the person agreed to.

The information stopped being true. Consent must be informed, and it was informed by a specific description. If your privacy information has moved on and the consent record points at wording that no longer reflects reality, the basis for that consent has quietly gone.

It was withdrawn — and the withdrawal did not reach the processing. Article 7(3) requires withdrawal to be as easy as giving, and a preference toggle that updates a table but does not stop a downstream job is a withdrawal in form only.

Notice that three of the four are things you did, not things the data subject did. Consent decays because organisations change around it.

The Evidential Problem With Old Records

Article 7(1) requires you to be able to demonstrate that the person consented. In practice that becomes harder with age for reasons unrelated to validity.

A five-year-old consent record usually says who and when. It rarely says what they were shown. The banner has been redesigned twice, the privacy notice rewritten, the purposes reworded, and nobody versioned any of it — so the record can prove an interaction occurred and cannot prove it was informed.

That is a documentation failure rather than a legal one, and it is worth separating because the fix is different. You do not need to re-collect consent because it is old. You need to be able to reconstruct what was on screen at the time, which means storing the version of the wording alongside the timestamp, and keeping old versions.

If you cannot do that for existing records, say so internally, and decide deliberately whether to re-collect or to move the processing to a basis you can actually evidence. What you should not do is treat an unversioned record as though it demonstrates something it does not.

How To Think About Refreshing

Refresh on change, and review on a cadence.

On change is the real trigger. New purpose, new recipient category, materially rewritten notice, a shift in what the processing does. That is when existing consent stops covering the activity and re-collection is genuinely required.

On a cadence is hygiene rather than obligation. An annual review of what you hold consent for, what it says, and whether it still matches the processing is reasonable for most companies, and it is one of the recurring jobs that has to land on someone rather than being nobody's.

There is a trap in re-permission campaigns worth naming, and it has a precedent. Emailing a dormant list to ask people to re-confirm is itself processing, and if the original consent was invalid you have no basis for the email either.

In March 2017 the ICO fined Flybe £70,000 for sending 3,333,940 emails titled "Are your details correct?" to people who had already opted out, and Honda £13,000 for 289,790 emails asking customers to clarify their marketing preferences. Both argued the messages were service emails sent to help them comply. The ICO held that an email asking whether someone wants marketing is itself marketing, and that both had therefore breached the electronic marketing rules. The enforcement head's summary was that businesses cannot break one law to get ready for another.

Note the statute: those were fines under the UK's electronic marketing regulations rather than under data protection law, which is a distinction worth keeping straight. The lesson transfers regardless. If consent was never valid, a campaign to renew it compounds the problem rather than resolving it.

When Consent Was The Wrong Basis All Along

A large share of "does our consent expire" questions are really a symptom. The processing has been running for years, the consent record is thin, and the underlying discomfort is that consent was never the right basis.

That is worth examining directly rather than papering over with a refresh. If the processing is necessary to deliver a contracted service, contract is the basis and consent was never needed. If it is ordinary business processing a reasonable person would expect, legitimate interests with a documented assessment is usually the right home. Consent belongs where the person genuinely has a free choice — and that condition is harder to satisfy than most teams assume.

Changing basis is not something to do casually, because the rights attached differ and switching retrospectively alters what someone could have exercised. But correcting a basis that was wrong from the start, deliberately and with a record of the reasoning, is better than maintaining an expensive consent apparatus that was never load-bearing.

One boundary: none of this touches the separate ePrivacy consent required to store or read information on a device. That requirement has its own logic, and reconsidering your Article 6 basis does not remove it.

Common Mistakes With Consent Expiry

Adopting an arbitrary expiry period. A twelve-month rule is not in the regulation. It creates work where nothing changed and misses the cases where the purpose shifted in month three, which are the ones that actually matter.

Treating age as the problem. Old consent for unchanged processing, properly collected and properly evidenced, is still valid. Recent consent for processing that has quietly expanded is not. Time is the wrong axis.

Running a re-permission campaign on invalid consent. If the original consent did not support contacting these people, it does not support contacting them to ask about consent. This has produced enforcement action, and it is entirely avoidable.

Storing the timestamp and not the wording. Article 7(1) requires you to demonstrate valid consent, which includes that it was informed. Without the version of what was shown, the record cannot do that, and no amount of refreshing fixes historical gaps.

Refreshing instead of reconsidering. If you find yourself renewing consent for processing the person cannot realistically refuse, the answer is not a better renewal cycle. It is that consent was the wrong basis and something else should be carrying the processing.

FAQ

How long is GDPR consent valid for?

For as long as it accurately describes the processing, the person has not withdrawn it, and you can still demonstrate it was validly given. There is no maximum in the regulation. Any specific figure you find has been supplied by whoever wrote the article rather than by the law.

Do we need to re-collect consent if we change our privacy notice?

It depends on whether the change is material to what people agreed to. Fixing typography or restructuring for clarity does not affect validity. Adding a purpose, a recipient category or a transfer does, because the consent was specific to what was described. The test is whether someone who agreed to the old wording would recognise the new processing.

What if we cannot tell what people were shown when they consented?

Then you cannot demonstrate the consent was informed, and you should treat that as a gap rather than assume it holds. Decide deliberately whether to re-collect properly, or whether another lawful basis genuinely applies to that processing. Start versioning your consent wording now so the problem stops growing.

Does withdrawal delete the data?

Not automatically — they are separate rights. Withdrawal stops further processing based on that consent going forward, and does not affect the lawfulness of processing already carried out. Erasure is a distinct request under Article 17, though in practice a withdrawal often triggers one, and you should be clear with people about which they are exercising.

Closing Thought

The search for an expiry date is really a search for a rule that would let this be handled without thinking about it — set a period, schedule a job, stop worrying. The regulation declines to provide one, and that refusal is consistent with everything else in it: you are not given a threshold to clear, you are made accountable for a position you can defend. Consent does not go stale on a schedule. It goes stale when the company changes and the consent record does not, which is a governance problem wearing a legal costume.

Which means the useful artefact is not a renewal calendar but a versioned record of what people were told and when. ComplyDog provides a cookie consent banner alongside a compliance portal on your own domain covering your DPA, subprocessor list, data subject request handling and security page. It does not audit whether your existing consents were validly collected or decide whether consent was the right basis in the first place — and on this question, those are the two things actually worth doing.

This article covers what the condition requires, the conditionality test in Article 7(4), the imbalance and bundling problems Recital 43 identifies, where a B2B SaaS runs into all three, and what you have to be able to show later.

One Of Four Conditions, And The One That Breaks

Article 4(11) defines consent as a freely given, specific, informed and unambiguous indication of the data subject's wishes by a statement or clear affirmative action. All four have to hold.

The other three are largely solvable by design. Specific means separate agreement per purpose rather than a bundle. Informed means the person knew the controller's identity, the purposes and their rights. Unambiguous means a positive act — no pre-ticked boxes, no inferring agreement from silence or continued use.

Freely given is different because it is not about how the request is worded. It is about the relationship the request sits inside, and a company cannot fix an imbalance of power by improving its copy. That is why this condition tends to be the one that fails on facts nobody thought were part of the consent question at all. The broader mechanics of collecting, recording and managing consent — banners, granularity, records, withdrawal flows — are a subject in their own right; what follows is only the condition itself.

Article 7(4): Conditionality Is The Test

Article 7(4) supplies the operative rule. In assessing whether consent is freely given, utmost account is taken of whether the performance of a contract, including the provision of a service, is made conditional on consent to processing that is not necessary for the performance of that contract.

Read that carefully, because it is narrower and sharper than the paraphrases. It does not prohibit conditionality outright — it makes conditionality a heavily weighted factor against validity where the processing is not necessary for the service.

The test therefore folds back into necessity. If the processing is genuinely required to deliver what the person asked for, you probably should not be using consent at all; contract is the appropriate basis. If it is not required, then withholding the service from someone who declines is precisely the pattern Article 7(4) targets.

That produces an uncomfortable symmetry worth stating plainly: the processing you most want consent for is usually the processing that consent covers least well.

Recital 43: Imbalance And Bundling

Recital 43 names two situations directly.

Imbalance of power. Consent is presumed not to be freely given where there is a clear imbalance between the data subject and the controller. The recital names public authorities, and the reasoning applies with obvious force to employer and employee. An employee asked to consent is not positioned to refuse, which is why consent is the wrong basis for almost all workplace processing and why security monitoring and workplace surveillance run on legitimate interests instead.

Bundling. Consent is presumed not to be freely given where it does not allow separate consent to different processing operations despite it being appropriate in the individual case. One checkbox covering analytics, marketing and third-party sharing is a bundle, and separating them is the fix.

Both are presumptions rather than absolute prohibitions, which means they can in principle be displaced. In practice, displacing them requires facts most companies do not have.

Where A B2B SaaS Runs Into This

Three patterns recur, and all three are ordinary product decisions rather than compliance mistakes.

Conditioning a free tier on analytics consent. If the analytics is not necessary to deliver the free product, requiring consent as the price of entry is squarely within Article 7(4). The strength of your position depends on how genuinely optional the alternative is — and it is why whether product analytics needs consent is a harder question than it first appears.

Asking employees to consent. To monitoring, to photographs, to internal directories, to processing during onboarding. The imbalance presumption applies, and the correct response is usually to identify the real basis rather than to collect a signature.

Cookie walls. Blocking access unless a visitor accepts non-essential tracking is the same structure as the free-tier case, and supervisory authorities have treated it sceptically. A genuine, equivalent alternative changes the analysis; a nominal one does not.

A fourth situation is worth naming because it catches people out: consent from children below the applicable age is not valid at all, and that age varies by Member State rather than being a single European figure.

Proving It Later

Article 7(1) puts the burden on you: where processing is based on consent, the controller must be able to demonstrate that the data subject consented. Not that a consent flow existed — that this person consented, to this purpose, at this time.

That means a record carrying who, what they were shown, when, by what mechanism, and which version of the wording was on screen. A consent log without the version of the notice cannot demonstrate the consent was informed, because you cannot reconstruct what was said.

This is the same evidential problem that shows up in a completely different corner of the business, when a DPA is accepted by click-through and nobody records what was presented or who accepted it. Valid without a record and provable are different things, and only one of them survives being questioned.

Withdrawal completes the picture. Article 7(3) requires it to be as easy to withdraw as to give, and withdrawal has to reach the processing, not just a preference table.

Common Mistakes With Freely Given Consent

Making the service conditional on consent to processing it does not need. This is the specific pattern Article 7(4) singles out. If the processing were necessary, contract would be the right basis; if it is not, withholding the service is the problem.

Asking employees for consent. The imbalance presumption in Recital 43 means workplace consent is rarely valid. Collecting it anyway produces a document that looks like compliance and provides none, while obscuring what the real basis was.

Bundling purposes into one checkbox. Analytics, marketing and third-party sharing are different processing operations and need separate agreement. A single "I agree" is the textbook example the recital describes.

Treating continued use as agreement. Consent requires a clear affirmative action. Scrolling, browsing, or not objecting is not a statement of wishes, and a banner that says continued use implies agreement does not create consent.

Keeping the consent but not the context. Article 7(1) requires you to demonstrate consent was given. A timestamp without the wording, the version and the mechanism cannot show it was informed, which means it cannot show it was valid.

FAQ

Can we ever make a service conditional on consent?

Rarely, and only where the processing is genuinely necessary for the service — in which case contract is the better basis anyway. Article 7(4) does not ban conditionality outright, but it weighs heavily against validity, and the burden of showing consent was free despite it sits with you. Treat conditionality as a signal you have chosen the wrong basis.

Is consent from a business contact freely given more easily than from a consumer?

Not automatically. The condition is about the individual's freedom to refuse, not about the commercial context. A business context can affect reasonable expectations in a legitimate interests balancing test, but it does not relax the freely given requirement where consent is the basis you are relying on.

Does an incentive invalidate consent?

Not necessarily, but it depends on scale and framing. A modest benefit for opting into something optional is generally acceptable. An incentive large enough that refusing carries a real detriment starts to look like a penalty, which is the structure the condition is aimed at.

We collected consent years ago under a bundled checkbox. Is it still good?

Almost certainly not, if it was bundled. Consent that did not meet the conditions when given was never valid, and time does not cure it. The practical response is to identify whether another basis genuinely applies to that processing, and to re-collect properly where it does not.

Closing Thought

The reason freely given catches so many organisations is that it is the only consent condition you cannot fix at the interface. Specific, informed and unambiguous are all solved by better design — separate the purposes, say more, require a click. Freely given asks a question about the relationship rather than the request, and no amount of interface work changes whether an employee can say no to their employer or whether a visitor can decline without losing the thing they came for. That is why the honest response is usually not a better consent flow but a different lawful basis.

Which makes this a design decision that happens well before anyone writes the banner. ComplyDog provides a cookie consent banner alongside a compliance portal on your own domain with your DPA, subprocessor list, data subject request forms and security page. It does not decide whether consent is the right basis for a given purpose, or whether your free tier makes it conditional — those are product judgements, and they are the ones that determine whether the banner is doing anything at all.

This article covers what Recital 49 supports, where the balancing test gets difficult, the line between securing systems and monitoring staff, why scope and retention decide the outcome, and what this looks like across an actual stack.

Recital 49 Does Most Of The Work

Recital 49 identifies processing to the extent strictly necessary and proportionate for ensuring network and information security as constituting a legitimate interest. That covers resisting unauthorised access, preventing damage to systems, stopping denial-of-service attacks, and detecting malicious code.

Two words in that formulation carry the weight: strictly necessary and proportionate. It is not a general authorisation to collect anything security-flavoured. It supports processing that is genuinely needed for the security purpose and no more.

The three-part assessment for legitimate interests — purpose, necessity, balancing — still has to be run and documented, and that page covers how each part works. What Recital 49 gives you is an unusually strong starting position on the purpose test, and a reasonable expectation that people anticipate their service provider defends its systems. It does not pre-answer necessity or balancing, and those are where real assessments fail.

Where The Balancing Test Actually Gets Difficult

Against external attackers the balance is straightforward. The data subject is often an unauthenticated party attempting something unauthorised, the intrusion is minimal, and the interest is obvious.

It gets harder in three places.

Your own users. Fraud and abuse detection processes ordinary customers as well as bad actors, because you cannot tell them apart in advance. Everyone is assessed so that a few can be identified. That is defensible and it is a real intrusion, and the assessment has to say so rather than pretending only the guilty are processed.

Your own staff. Access logging, endpoint monitoring and anomaly detection produce a detailed record of what individual employees did and when. The employment relationship carries an imbalance of power that weakens reasonable expectations as a justification.

Scope creep. A system built for security acquires a second audience. Access logs get used to settle a performance question. Endpoint data answers a productivity query. The moment security telemetry is used for a non-security purpose, the Recital 49 argument stops covering it — you have a new purpose, needing its own basis and its own assessment.

The Line Between Securing Systems And Monitoring People

This is the distinction the whole subject turns on, and it is worth drawing precisely.

Securing systems asks whether something is wrong: unusual access patterns, credential stuffing, exfiltration signatures, privilege escalation. Individuals appear because activity has to be attributable, not because anyone is the subject of interest.

Monitoring people asks what a named individual is doing: keystrokes, screen contents, application time, productivity scoring. The individual is the point.

Systems built for the first can be operated as the second without any technical change, which is why the boundary needs writing down and enforcing rather than assuming. Monitoring employees at work is a distinct subject with a different analysis, its own transparency requirements, and in many jurisdictions a works council or consultation dimension. Recital 49 does not reach it, and a security justification stretched over it is the specific move that fails.

The practical test: could you explain this system to the people it watches, in plain terms, and would they recognise the description? If the honest answer involves not mentioning a capability, the capability has outgrown the basis.

Scope, Retention And Access Decide The Outcome

Because the purpose test is easy here, assessments live or die on necessity and proportionality — which come down to three operational decisions.

Scope. Collect the fields the detection actually uses. Full request payloads, message bodies and screen contents are rarely necessary for security and enormously expand the intrusion. Necessity is assessed against what the security purpose needs, not what the tooling can capture.

Retention. Security data has a genuine investigative half-life, and it is shorter than most defaults. Ninety days serves most detection and forensics; multi-year retention of everything is a storage-limitation problem wearing a security justification, and it converts a monitoring system into a standing archive of employee behaviour.

Access. Who can query it, whether queries are logged, and whether anyone outside security can reach it. An unrestricted log platform that the whole engineering team can search is a different proposition from a controlled one, and it is the version that fails a balancing test.

Get those three right and the assessment writes itself. Get them wrong and no amount of Recital 49 saves it.

What This Looks Like Across A Real Stack

Most of this data does not sit in a system labelled "security." It sits in application logs, cloud provider audit trails, endpoint agents, identity provider records and CI pipelines — and the personal data in the last of those is rarely where anyone expects to find it.

Three things follow. Every one of those systems belongs in your record of processing activities with the security purpose and the legitimate interests assessment attached. Your privacy information has to state that you rely on legitimate interests and describe them, because transparency is independent of basis. And people retain the right to object under Article 21, which for security monitoring will often be refused — but refused with reasoning that was written down beforehand rather than improvised.

Third-party security vendors are processors and need Article 28 terms, and they belong on your subprocessor list. That is where a security tool most often goes unregistered, because it was adopted by the team least likely to be asked for a vendor form.

Common Mistakes With Security Monitoring Assessments

Treating Recital 49 as the whole assessment. It gives you a strong purpose test and nothing else. Necessity and balancing still have to be worked through and written down, and those are the parts a regulator reads.

Letting security telemetry answer non-security questions. Using access logs to settle a performance dispute creates a new purpose with no basis. The technical capability is identical, which is exactly why the rule has to be organisational.

Collecting full payloads because the tool can. Capturing everything and filtering later inverts the necessity test. Proportionality is assessed on what you collect, not on what you look at.

Setting retention by default rather than by decision. Most logging platforms ship with a retention period nobody chose. For security data that period is a decision about how long you keep a behavioural record of your staff, and it should be made deliberately.

Not telling anyone. Legitimate interests removes the need to ask permission, not the need to be open. Undisclosed monitoring fails on transparency even where the basis itself would have held.

FAQ

Do we need consent from employees for security monitoring?

No, and consent would be the wrong basis. In an employment relationship consent is rarely freely given because of the imbalance of power, and monitoring that stops when someone declines is not a security control. Legitimate interests is the appropriate basis, supported by a documented assessment and clear notice to staff.

Can someone object to being security-monitored?

They can object under Article 21, and you must consider it on their particular circumstances. For genuine security monitoring the objection will often be refused, because you can usually demonstrate compelling legitimate grounds. What matters is that the refusal follows a real reassessment and is explained, rather than being a form response.

Does this cover fraud detection as well as intrusion detection?

Broadly yes — fraud prevention is widely accepted as a legitimate interest and the reasoning parallels network security. Note the difference in who is processed: fraud detection assesses your own customers rather than external attackers, so the balancing test carries more weight and the transparency obligation is more visible.

How long can we keep security logs?

There is no fixed period. Keep them as long as the security purpose genuinely needs, decided by you and written down with a reason. Most detection and investigation work happens within weeks, so long default retentions usually reflect a platform setting rather than a judgement. If the honest reason is "in case we need it," that is not a retention period.

Closing Thought

Security monitoring is unusual among GDPR questions because the lawful basis is the easy part and the discipline is the hard part. Recital 49 hands you a purpose almost no supervisory authority will argue with, and that generosity is precisely what makes the failure mode subtle: an assessment written once, a system whose scope quietly expands, a retention period nobody set, and a capability that was built to catch intruders being used to answer a question about an employee. None of those is a basis problem. All of them are the reason the basis stops covering what the system does.

The durable version is narrow scope, a retention period someone chose, controlled access, and a written boundary about what the data may not be used for. ComplyDog hosts a compliance portal on your own domain with your DPA, subprocessor list, data subject request forms and a security page — which is where the security posture you have built becomes something a buyer can check. It does not scope your logging, set your retention or write your balancing test; those stay with whoever runs the systems.

This article covers what Article 8 actually says, why published country tables contradict each other, the figures we could corroborate, when the provision is engaged, and what verification is expected of you.

Article 8 Sets Sixteen, With A Floor Of Thirteen

Where an information society service is offered directly to a child and processing is based on consent, Article 8(1) makes that consent lawful only where the child is at least 16. Below that age, processing is lawful only if consent is given or authorised by the holder of parental responsibility. Member States may legislate a lower age, but not below 13.

Article 8(2) adds the operational half: the controller must make reasonable efforts to verify that consent is given or authorised by the holder of parental responsibility, taking into consideration available technology.

Two consequences follow immediately. There is a legitimate range of 13 to 16 across the Union, so the answer is jurisdictional rather than European. And "reasonable efforts" is a proportionality standard, not a specification — what is reasonable scales with the risk of the processing.

Why The Tables You Find Online Disagree

Search this question and you will find country-by-country tables. Compare a few and you will find they conflict, sometimes on major markets. In preparing this article we found live sources published as recently as 2025 stating a figure for France that the French implementing law contradicts, alongside better-sourced material giving the correct one.

There are three reasons, and knowing them is more useful than any single table.

Most tables date from 2018. A great many were compiled while Member States were still legislating, and they recorded expectations rather than enacted law. Several countries landed somewhere other than predicted, and the tables were never revisited.

Spain is the cleanest illustration. EU-level tracking from the transposition period listed it at 13, explicitly flagged as draft law. What Spain actually enacted was 14. Every table that copied the draft figure without the flag has been wrong ever since, and there are a great many of them.

Copies propagate faster than corrections. A table published once is quoted, reformatted and republished, and each copy carries the original's errors without its date.

The underlying question is genuinely more complicated than one number. National rules differ not only on the age but on whether a child's consent alone is ever sufficient, and on how parental authorisation interacts with general capacity law. A single column flattens distinctions that matter in practice.

The Figures We Could Corroborate

Below are the positions we could confirm against at least two independent, credible sources as at 8 August 2026. This is not all twenty-seven Member States, and it is not offered as a complete table — we did not verify the remainder to the standard the rest of this article is held to, and publishing them anyway is exactly the failure described above.

Confirm your own markets against the national implementing law or the relevant supervisory authority before relying on any figure, including these. That is not a disclaimer for its own sake — it is the only method that survives contact with a regime where twenty-seven legislatures each hold a pen.

Article 8 Is Only Engaged If Consent Is Your Basis

This is the part that resolves the question for most B2B SaaS companies, and it is routinely skipped.

Article 8 conditions the validity of consent. If your lawful basis for a given purpose is contract, legal obligation or legitimate interests, Article 8 does not apply to that purpose. A child using a service under a contract does not trigger a parental consent requirement merely by being a child — which is why picking your lawful basis deliberately changes what obligations you inherit.

That is not a loophole and it is not a reason to relabel consent as something else. Children remain a group whose data merits specific protection, transparency obligations still require language a child can understand, and where you have chosen consent it must still meet every ordinary condition — including that it is freely given, which is harder to establish for a child than an adult.

The provision also applies specifically to services offered directly to a child. A workplace tool that a sixteen-year-old apprentice happens to use is in a different position from a service designed and marketed for teenagers.

What "Reasonable Efforts To Verify" Actually Means

Article 8(2) asks for reasonable efforts taking into account available technology, and the EDPB's consent guidelines frame the measures as proportionate to the nature and risks of the processing.

In practice that produces a sliding scale rather than a standard. A low-risk service might reasonably rely on a self-declared date of birth with sensible design around it. A service processing sensitive data, profiling, or serving targeted advertising will be expected to do considerably more, and a tick-box will not be defensible.

Two design points are worth stating. Asking for a birth date is itself collecting personal data, so collect the minimum that answers the question. And an age gate that teaches children to enter a false year is worse than useless — it produces a record that says the user is an adult, which is a documented inaccuracy rather than a defence. This is also where signup and trial flows tend to be the only place the question is ever asked, and where it is most often not asked at all.

Common Mistakes With Children's Consent

Treating 16 as the European answer. It is the default, not the rule. Operating across the Union means the applicable age varies by where the child is, and using one figure means being wrong in a predictable subset of your markets.

Copying a table without checking its date. Most published tables were compiled in 2018 from expected rather than enacted positions. A figure without a date and a source is not information you can rely on.

Applying Article 8 when consent is not your basis. The provision conditions consent. Working through a parental consent process for processing you actually perform under contract creates obligations you did not have and muddles the record of what your basis is.

Using an age gate as a compliance artefact. A gate that any child can pass by picking an earlier year does not evidence anything. Worse, it records an assertion you know may be false, which is a weaker position than not asking.

Forgetting the transparency half. Article 12 requires clear and plain language, particularly for information addressed to a child. A privacy notice written for procurement lawyers does not meet that standard, whatever the age of consent is where the child lives.

FAQ

Our product is B2B. Do we need to worry about this at all?

Usually not, because Article 8 applies to information society services offered directly to a child, and a workplace tool is not that. But check two things: whether your free tier or self-serve signup is genuinely restricted to business users, and whether your terms set a minimum age you actually enforce. Products acquire under-16 users through consumer-style signup flows more often than their positioning suggests.

Which country's age applies — where the child is, or where we are?

Where the child is. The GDPR applies to offering services to people in the Union based on their location, so a company in one country serving users across several must apply each relevant national age. That is the practical reason a single figure does not work.

What happens if we get consent from a child below the applicable age?

The consent is not valid, so the processing has no lawful basis unless another one genuinely applies. You would need to stop the processing, consider deletion, and decide whether anyone needs to be told. Discovering this late is more common than discovering it early, because nothing in a signup flow flags it.

Does the UK still follow the GDPR age of consent?

The UK operates a separate regime since Brexit, and its age sits at the floor of 13 rather than the default of 16. If you serve both the UK and EU markets you are dealing with two regimes rather than one, which is true of a good deal more than this provision.

Closing Thought

The genuinely interesting thing about this question is not the number, it is what happens when a regulation designed to harmonise a market hands twenty-seven legislatures a range and lets each pick. You get exactly what you would expect: a spread from 13 to 16, a set of national rules that interact with domestic capacity law in ways no comparison table captures, and an internet full of confidently wrong summaries frozen at the moment the laws were still being drafted.

Which means the honest answer to "what is the GDPR age of consent" is a method rather than a figure — check your markets, against national law, with a date on it. ComplyDog hosts a compliance portal on your own domain covering your DPA, subprocessor list, data subject request forms and security page, which is where your positions become something a customer can read. It does not check national implementing law for you, and on this question there is no substitute for doing that per market.

This article covers why the term is undefined, the four factors regulators actually apply, the worked examples that anchor them, where the phrase carries consequences, and how to reach a defensible position about your own product.

The Regulation Never Defines It, Deliberately

Recital 91 is the closest the text comes, describing large-scale processing operations as those aiming to process a considerable amount of personal data at regional, national or supranational level, which could affect a large number of data subjects. It then gives one clear negative: processing by an individual physician, other health care professional or lawyer, concerning their own patients or clients, should not be considered large scale.

The Article 29 Working Party — the predecessor to the European Data Protection Board — addressed this directly in its guidelines on data protection officers, and its position is worth quoting in substance: it is not possible to give a precise number, either for the amount of data or the number of individuals, that would apply in all situations. It left open the possibility that standard practice might develop over time for common processing activities.

That refusal is not evasion. A fixed threshold would be gamed immediately and would produce absurd results across sectors with very different data intensities. The cost is that you have to reason rather than look up an answer.

The Four Factors Regulators Apply

The Working Party's guidelines recommend four factors, and supervisory authorities including Ireland's Data Protection Commission repeat them:

The number of data subjects concerned — either as a specific number, or as a proportion of the relevant population. The second half matters. Ten thousand people is a different proposition depending on whether it is ten thousand out of a hundred million or ten thousand out of forty thousand.

The volume of data and the range of different data items being processed. Breadth counts as well as depth: many fields about each person weighs more than one field about many.

The duration or permanence of the processing. A one-off collection is not the same as continuous, indefinite processing.

The geographical extent of the processing. A single town differs from several countries.

These are weighed together rather than scored. Nothing says two of four triggers anything on its own.

The Examples That Anchor The Factors

Abstract factors are hard to apply, so the worked examples do more work than the criteria. The Working Party treated the following as large scale: patient data processed by a hospital in the regular course of business; customer data processed by an insurance company or a bank; personal data processed for behavioural advertising by a search engine; and travel data on a public transport system.

Not large scale: an individual physician's patient records, or an individual lawyer's client data including criminal conviction information.

The pattern is instructive. What moves an activity into "large scale" is a combination of population coverage and data intensity, not revenue or staff. A behavioural advertising system and a solo medical practice may hold comparable sensitivity per person; they differ enormously in reach.

Why It Is Not About Your Headcount

This is the point most often got wrong, and it is worth being blunt. The Working Party framed large scale with reference to the number of data subjects rather than the size of the organisation. A company with a handful of employees can be processing on a large scale if it serves a large customer base; a company with many employees serving a small clientele is unlikely to be.

For a SaaS business that inverts the intuition entirely. A four-person analytics product with two million monitored end users is a stronger candidate than a two-hundred-person consultancy with sixty clients. The relevant population is your users and your users' users, not your payroll — which is the same reason almost nothing else in the GDPR turns on headcount either.

The other thing to hold onto is "core activities." The obligations that use "large scale" attach to core activities — the operations inextricable from what you sell — rather than to ancillary processing every company does. Payroll is not a core activity for a software company even though it is continuous and involves sensitive data.

Reaching A Defensible Position On Your Own Product

You will not find a number, so the deliverable is a reasoned, dated, written assessment. In practice that means writing down, per processing activity: how many people, what proportion of the relevant population, how many data items and of what kinds, how long you keep it, and where those people are.

Then state a conclusion and the reasoning behind it. A short document saying "we consider this large scale because of the following three factors" is worth far more than a confident verbal position, because the phrase appears in provisions where being wrong is expensive: the data protection officer obligation, the circumstances requiring a data protection impact assessment, and several places where special category data is involved. Each of those is its own subject and worth taking properly if you land near the line.

The activities that most often push a SaaS towards it are the ones running quietly in the background across the entire user base — and internal tools and dashboards are frequently where that breadth becomes visible, because they are the systems with access to everything at once. All of it belongs in your record of processing activities with the assessment attached.

Common Mistakes With "Large Scale"

Looking for a number. There isn't one, and searching for a threshold produces confident answers from sources that invented them. The absence is deliberate and the correct response is a documented assessment, not a figure.

Assuming a small company cannot qualify. The test counts data subjects, not employees. A tiny team with a large user base is precisely the profile that surprises people when the question is finally asked properly.

Counting only your direct customers. For a B2B SaaS the data subjects are usually your customers' end users, and there are far more of them. Assessing scale against your account list rather than the people in the database understates it by orders of magnitude.

Including ancillary processing in the assessment. The obligations turn on core activities. Payroll, recruitment and internal IT are real processing that belongs in your records, but they are not what makes a software company's processing large scale.

Deciding once and never revisiting. Scale is the one factor that changes on its own while nothing else does. An assessment made at ten thousand users is not evidence about a position at two million, and nobody gets a prompt when the line is crossed.

FAQ

Is there any number of users that definitely counts as large scale?

No, and any source giving one has made it up. The assessment weighs the number of people against the relevant population, alongside data volume, duration and geography. Two million users of a global consumer product and two million records covering most of a small country are treated very differently, which is exactly why a bare number cannot work.

Does processing special category data automatically make it large scale?

No — sensitivity and scale are separate questions. Special category data raises the stakes of the answer, because several obligations combine "large scale" with Article 9 data, but a small volume of health data is still a small volume. The two criteria have to be assessed independently and then read together.

We are a processor, not a controller. Does this apply to us?

Yes. The obligations that use "large scale" apply to processors as well as controllers, and a processor serving several controllers may be operating at a scale that none of them reaches individually. Assess your own aggregate processing rather than assuming your customers' assessments cover you.

Who decides whether we are right?

You do, in the first instance, and a supervisory authority does if it is ever examined. That asymmetry is the argument for writing the assessment down with a date and the factors you weighed. A documented position that a regulator disagrees with is a much better place to be than no position at all.

Closing Thought

The undefined term is doing something deliberate here, and it is worth understanding rather than resenting. A number would let organisations engineer themselves just underneath it, and it would mean the same figure applied to a national health system and a hobby forum. Leaving it open transfers the work to you and, with it, the accountability — which is the pattern the whole regulation follows. You are not told what to conclude; you are required to reason and to show your reasoning.

Which makes the deliverable a short written assessment rather than a search for the right answer. ComplyDog hosts a compliance portal on your own domain covering your DPA, subprocessor list, data subject request handling and security page, and it is the layer buyers read once you have done the underlying thinking. It does not count your data subjects or decide whether your processing is large scale — that judgement is specific to your product, and it has to be yours.

This article covers when the choice actually happens, what each of the six is genuinely for, the order to work through them, what rules a basis out, and where your decision has to show up afterwards.

You Pick Per Purpose, Before You Process

The unit of decision is the purpose, not the company and not the dataset. The same customer email address might be processed under contract to deliver the service, under legal obligation to keep an invoice record, and under legitimate interests to send a product-change notice. Three purposes, three bases, one field in one table.

The timing matters as much as the choice. Article 5(1)(a) requires processing to be lawful, and Article 5(2) requires you to demonstrate it. A basis identified after a complaint arrives is not a basis, it is a justification — and the difference is visible to anyone reading the dates on your documentation.

The harder constraint is that you cannot swap. Regulators are consistent that you should not switch basis part-way through unless there is a genuine reason, because the rights attached to each basis differ. Erasure is close to absolute against consent and qualified against contract. Portability applies to consent and contract and not to legitimate interests. Telling someone their data was processed under consent, then relying on legitimate interests when they withdraw, retrospectively changes what rights they had. That is the specific thing not to do.

What Each Of The Six Is Actually For

Consent, 6(1)(a). The person has genuinely agreed. Powerful where there is real choice, fragile everywhere else, and heavy to administer because it must be as easy to withdraw as to give.

Contract, 6(1)(b). Processing necessary to perform a contract with the person, or to take pre-contractual steps at their request. "Necessary" is doing the work: it covers delivering the service they signed up for, not everything you would like to do with the resulting data.

Legal obligation, 6(1)(c). A statutory duty, not a contractual one and not a commercial norm. Tax record retention qualifies; a customer's security questionnaire does not.

Vital interests, 6(1)(d). Life-or-death situations. Almost never relevant to a B2B SaaS and worth knowing mainly so you can rule it out quickly.

Public task, 6(1)(e). Official authority or a task in the public interest. Not available to most private companies.

Legitimate interests, 6(1)(f). Your interest or a third party's, balanced against the person's rights. The most flexible and the most demanding, because it requires a documented three-part assessment. How that assessment works — the purpose, necessity and balancing tests, and the documentation each requires — is a subject in its own right and this article does not repeat it.

The Order To Work Through Them

Work top-down and stop at the first that genuinely fits.

Is it legally required? If a statute compels the processing, 6(1)(c) is the answer and there is nothing to weigh. This is the smallest category and the easiest to confirm.

Is it necessary to deliver what they asked for? If the person cannot receive the service without it, 6(1)(b) applies and you are done. Test it honestly: could you deliver the product without this processing? If yes, it is not necessary, whatever its business value.

Would a reasonable person expect it, and can I justify it? That is 6(1)(f) territory, and it needs the assessment before you rely on it, not after.

Does the person have a genuine free choice? Only then is consent appropriate. Consent chosen because it feels safest is usually the worst option available — it is the most easily invalidated and the most operationally expensive.

The order matters because working bottom-up produces the classic failure: reaching for consent, discovering it cannot be freely given in your context, and then retrofitting legitimate interests to a process already built around a checkbox.

What Rules A Basis Out

Several constraints remove options before you get to weigh them.

Special category data. Article 9(1) prohibits processing health, biometric, racial, political, religious, trade union, genetic and sex life data unless an Article 9(2) condition also applies. You need a lawful basis under Article 6 and a condition under Article 9. Legitimate interests is not one of the Article 9(2) conditions.

Public authorities cannot rely on legitimate interests for processing carried out in the performance of their tasks.

Children and information society services. Where you rely on consent for a service offered directly to a child, Article 8 adds a parental consent requirement below an age that varies by Member State — which is a real constraint on choosing consent, not a detail.

Direct marketing. Whatever basis you pick, Article 21(2) gives an unqualified right to object, with no balancing available to you at that point.

And separately from all of this, storing or reading information on someone's device carries its own consent requirement under the ePrivacy rules. Whether product analytics needs consent is the clearest worked example of two regimes producing two different answers to what looks like one question.

Where Your Decision Has To Show Up

Choosing is half the work. The other half is that the choice is visible in three places, and inconsistency between them is what gets noticed.

Your privacy information has to state it: Articles 13(1)(c) and 14(1)(c) require the purposes and the legal basis. Where you rely on legitimate interests, a separate provision — Article 13(1)(d) for data collected from the person, Article 14(2)(b) where it was not — requires you to name the interests themselves.

Your record of processing activities should carry it per activity, which is what makes it possible to answer a rights request correctly rather than generously.

Your assessments — the legitimate interests assessment, the consent records — are the evidence that the decision was made rather than assumed.

The place this most often falls apart is data you did not collect directly. When personal data arrives from a third party or a public source rather than the person, the basis question is identical but the paper trail is thinner, and there is a separate obligation to tell people you hold it.

Common Mistakes With Lawful Bases

Picking one basis for the whole company. A basis attaches to a purpose. An organisation that says "we rely on legitimate interests" has not made a decision, it has skipped one, and it will not survive the first question about a specific processing activity.

Treating consent as the safe default. Consent is the most easily invalidated basis and creates the most ongoing work. Where the person has no real choice, consent is not merely weak — it is invalid, and the processing it was supposed to support has no basis at all.

Stretching contract necessity. Article 6(1)(b) covers what is necessary to deliver the service. Product analytics, marketing, enrichment and scoring are not necessary to deliver it, however normal they are, and accepting terms of service is not consent to them.

Switching basis when the first one becomes inconvenient. Moving from consent to legitimate interests when someone withdraws retrospectively changes their rights. If a basis was wrong, fix it deliberately and tell people; do not quietly substitute.

Documenting the conclusion but not the reasoning. "Legitimate interests" written in a cell is not an assessment. What matters is why the other bases did not fit and what was weighed — because that is what you will be asked for.

FAQ

Can I rely on more than one lawful basis for the same processing?

You should identify the single most appropriate basis for each purpose rather than listing several as a hedge. Naming a fallback suggests the primary one might not hold, and it makes your privacy information ambiguous about which rights apply. Where a genuinely different purpose exists, that is a separate entry with its own basis.

Does legitimate interests mean I do not have to tell anyone?

No. Transparency is independent of your basis. You must state that you rely on legitimate interests and describe what those interests are, and people retain the right to object. What legitimate interests removes is the need to ask permission first, not the need to be open about it.

What if I realise the basis we have been using is wrong?

Fix it deliberately. Work out the correct basis, assess whether the processing was lawful in the interim, correct your privacy information and your records, and consider whether people need to be told. The failure mode is silently updating a spreadsheet and hoping nobody compares versions.

Is "we've always done it this way" ever a legitimate interest?

No. Longevity is not an interest — it is an explanation of how the processing started. A legitimate interest has to be a specific, current, articulable purpose that you could state to the person concerned. If the honest answer is that nobody remembers why the processing exists, that is a signal to stop it rather than to justify it.

Closing Thought

The reason lawful basis feels harder than it is comes down to a mismatch in how the question is usually asked. Teams want to know which basis is best, as though the six were options on a menu with different levels of protection. They are not. They are descriptions of six different situations, and in almost every case the facts have already decided which one you are in. The work is not choosing well — it is looking honestly at what you are doing and naming it accurately, which is uncomfortable precisely when the honest name is "we would like to do this and nobody asked."

Once decided, the basis has to stay visible in your privacy information, your record and your assessments. ComplyDog hosts a compliance portal on your own domain covering your DPA, subprocessor list, data subject request handling and security page, which is where the outward-facing half of this ends up. It does not choose your bases or write your assessments — those are judgements about your own processing, and they are the part that has to come first.

This article covers why scope has no size test, what Article 30(5) actually says, why Article 37 is about scale and nature rather than staff count, what genuinely changes as a SaaS grows, and the one place a staff number moves a real figure.

Scope Has No Size Test

Article 3 sets territorial scope by establishment and by targeting. If you are established in the Union, or you offer goods or services to people in the Union, or you monitor their behaviour there, the regulation applies. There is no clause about employees, revenue or funding stage.

The same is true of the substantive obligations. Lawful basis, transparency, security, data subject rights, breach notification and the accountability principle all attach from the first record you hold. A two-person company that suffers a breach has the same 72-hour assessment obligation as a large one.

This is worth stating clearly because a great deal of advice aimed at small companies implies otherwise, and much of it is generic enough to leave the impression that the rules loosen below some line. They do not. What genuinely varies is proportionality: Article 24 asks for measures appropriate to the nature, scope, context and purposes of processing and the risks involved, which means a small company with low-risk processing can do less and defend it. That is a different claim from being exempt, and a general affordable implementation approach for a new company is about how to sequence the work rather than about which parts you can skip.

Article 30(5) Is The Only Real Number, And It Is A Ceiling

The one headcount figure in the regulation is in Article 30(5), which disapplies the record-keeping obligations for an enterprise employing fewer than 250 persons — unless the processing is likely to result in a risk to the rights and freedoms of data subjects, or the processing is not occasional, or it includes special category data under Article 9(1) or criminal conviction data under Article 10.

Read the carve-outs and the exemption evaporates for essentially every SaaS company. Running customer accounts is not occasional. Payroll is not occasional. A CRM is not occasional. The exemption was written for genuinely sporadic processing — the kind of one-off activity a small organisation does a few times a year — and it does not describe a business whose product holds user records continuously.

Two details are worth knowing. The 250 figure counts the enterprise's total employees, not the number involved in the processing. And "fewer than 250" is a ceiling above which the exemption is unavailable at all, rather than a safe harbour below it. Ireland's Data Protection Commission ran a sweep of thirty organisations' records in early 2022 and asked those without one to explain why; the exemption was available to some, and the fact that it had to be justified rather than assumed is the useful part.

The practical conclusion is the same one most regulators reach: treat the record of processing activities as mandatory regardless of size. That page covers the obligation itself, its mandatory fields and this exemption in its own right; what follows here is only the question of what genuinely changes as you grow.

Article 37 Is About What You Do, Not How Many You Are

The second place numbers appear is the data protection officer obligation, and it is not a headcount test either. Article 37(1) requires a designation where the controller is a public authority, where core activities require regular and systematic monitoring of data subjects on a large scale, or where core activities involve large-scale processing of special category or criminal offence data.

Both operative triggers turn on the nature and scale of the processing. A ten-person analytics company whose entire product is behavioural monitoring is far closer to the threshold than a two-hundred-person company selling invoicing software. Growing the team changes neither.

"Core activities" is doing real work in that sentence: it means the processing that is inseparable from what you sell, not administrative processing every company does. Payroll and HR are not core activities for a software company even though they involve special category data.

Whether a particular business crosses the line, and what the role requires once it does, is a bigger question than this article. The point here is that you will not answer it by counting employees.

What Actually Changes As You Grow

The triggers that genuinely change your obligations are events, not numbers, and they are mostly commercial.

Your first EU or UK user. Territorial scope engages. If you have no establishment there, this is also where an Article 27 representative comes into view — and that obligation applies regardless of company size, which surprises founders more than anything else on this list.

Your first enterprise buyer. Nothing legal changes, but the evidence burden does. Vendor reviews ask for documents that already had to exist, and this is where most companies discover which ones do not.

Your first special category data. Health, biometrics, or anything under Article 9(1). Constraints tighten sharply and several previously comfortable positions stop working.

Your first EU establishment. A subsidiary or staff on the ground moves you into Article 3(1), changes your lead supervisory authority analysis, and removes the Article 27 obligation by replacing it with something larger.

Your first serious incident. The 72-hour clock does not care how many people you employ, and it is the moment your documentation is tested rather than described.

The One Place Staff Count Genuinely Moves A Number

There is a real headcount threshold, and it is not in the GDPR at all — it is the UK data protection fee, which is a separate registration obligation administered by the ICO.

Its tiers use turnover or staff count, and the criteria are alternatives rather than cumulative, which several secondary sources get wrong. Staff count includes overseas staff, averaged monthly across the financial year. It is genuinely a number, it genuinely changes what you pay, and it is completely separate from anything in the GDPR itself — whether you have to register with the ICO and what it costs is its own question with its own answer, and conflating the fee with compliance is a frequent error.

Everything else that feels like it scales with headcount is really scaling with something else: more staff means more systems, more vendors, more access to manage and more data. The obligations did not change. Your surface did.

Common Mistakes With Size And GDPR

Believing the fewer-than-250 exemption applies to you. It requires the processing to be occasional, low-risk and free of special category data as well as under the headcount. Continuous customer accounts fail the first test on their own.

Deferring documentation until "we are big enough." The record of processing activities is cheapest to build when there are eight systems rather than eighty. Waiting means reconstructing history from memory and expense reports.

Assuming a DPO obligation arrives at a certain team size. It arrives with regular systematic monitoring at scale or large-scale special category processing as core activities. Some very small companies are caught; many large ones are not.

Confusing the ICO fee with GDPR compliance. Paying the fee is a UK registration obligation. It does not demonstrate compliance with anything else, and being exempt from it does not exempt you from UK GDPR.

Treating proportionality as permission to skip. Article 24 lets a small company implement lighter measures where the risk is genuinely lower. It does not let you omit a lawful basis, a retention position or a breach process, and "we are small" is not a documented risk assessment.

FAQ

Is there a minimum company size below which GDPR does not apply?

No. There is no lower threshold for scope in Article 3 or for the substantive obligations. A sole trader processing EU personal data is within scope. What varies is what proportionate measures look like, not whether the regulation applies.

We are a US company with a handful of EU users. Does the regulation really apply?

If you are targeting them rather than merely being reachable, yes. Mere accessibility of a website from the EU is not enough on its own; indicators like EU currencies, languages, EU-targeted advertising or region-specific support point to intentional offering. A handful of users you deliberately signed up is different from one who found you by accident.

Does the fewer-than-250 exemption mean we do not need a data map?

Practically, no. Even where the Article 30 obligation were disapplied, you still need to know what you hold to answer data subject requests, name a lawful basis, set retention and assess a breach. The record is the artefact that makes all of those possible, which is why it is worth having regardless.

When should we start taking this seriously?

Before the first EU user, if you can, because retrofitting is more expensive than sequencing. The realistic answer for most founders is at the first enterprise sales conversation, when someone asks for evidence and the cost of not having it becomes a deal timeline rather than an abstraction.

Closing Thought

The question contains an assumption worth examining, which is that compliance obligations scale with company size the way most business obligations do. Employment law, financial reporting and tax all have thresholds, so it is reasonable to expect data protection to have them too. It largely does not, because the regulation is built around risk to individuals rather than capacity of organisations, and a small company can create a great deal of risk. Ten people with a database of two million users is not a small data protection problem.

Which means the useful question is not "are we big enough yet" but "what do we actually hold, and can we show it." Checked 8 August 2026, that remains the thing every buyer, regulator and data subject asks for first. ComplyDog hosts a compliance portal on your own domain covering your DPA, subprocessor list, data subject request handling and security page, which is the answering layer once you have the underlying record. It does not build the record, set your retention periods or tell you whether your processing is large-scale — those are the judgements that come first, and they do not get easier by waiting.

This article covers why the two questions separate, how narrow the strictly-necessary exemption is, where legitimate interest genuinely helps and where it cannot rescue you, what changes with server-side or first-party analytics, and how logged-in product analytics differs from website analytics.

There Are Two Questions Here, With Different Answers

The mistake that causes most of the confusion is treating "do I need consent for analytics" as one question. It is two, asked of two different laws.

Question one. Are you storing information on, or gaining access to information already stored on, the user's device? Cookies, localStorage, device fingerprinting and most SDK identifiers all qualify. Under the ePrivacy Directive as implemented nationally — PECR in the UK — this requires consent unless the access is strictly necessary for a service the user has explicitly requested.

Question two. What is your lawful basis under Article 6 for processing the personal data you then hold? Consent under 6(1)(a), contract under 6(1)(b) and legitimate interests under 6(1)(f) are the candidates.

They can produce different answers, and the first constrains the second. If you needed consent to set the identifier and did not obtain it, having a legitimate interest in the analysis does not make the collection lawful. Getting this order right is what separates a defensible analytics setup from one that looks defensible.

The Strictly Necessary Exemption Is Narrower Than It Reads

"Strictly necessary" means necessary to deliver the service the user asked for — a session cookie that keeps them logged in, a load-balancing cookie, a cookie remembering items in a basket, and the cookie that stores their consent choice.

Analytics is not strictly necessary in that sense, however useful it is to you. The user asked for the product, not for the measurement of their use of it. Regulators have been consistent on this point, checked 8 August 2026, and the fact that the analytics improves the product the user requested does not convert it into something the user requested.

Some supervisory authorities have taken a more relaxed view of genuinely first-party, aggregate-only audience measurement, but the conditions attached are strict and vary by country. It is not a general exemption and building a product on the assumption that it is available in your market is a poor bet.

Where Legitimate Interest Helps, And Where It Cannot

Legitimate interest under Article 6(1)(f) is a real and useful basis for analytics, and it is frequently the right one for the processing stage — analysing usage patterns to improve a product is a textbook legitimate interest, subject to a documented balancing test and an honest read of user expectations.

What it cannot do is displace the consent requirement for the device access step, because that requirement comes from separate legislation. This is the single most common error on this topic and it appears in a lot of otherwise careful writing, including material that correctly says analytics can rely on legitimate interest without adding that the cookie still needs consent. Both statements can be true at once; only stating the first produces a setup that fails at the first step.

The practical position for most B2B SaaS: obtain consent for non-essential storage and access, then rely on legitimate interest for the subsequent analysis where that is genuinely more appropriate than consent, and document the balancing test. Whether the vendor you use can be configured to work that way is a separate matter, and whether Google Analytics is GDPR compliant covers the configuration and transfer side of that question in detail. This article stays on the basis.

Server-Side And First-Party Analytics Change The Analysis, Not Always The Answer

Moving collection server-side is often described as a way around consent. It is more accurate to say it changes which question is engaged.

If the server-side setup still relies on an identifier stored on the device — a first-party cookie set by your own domain, a persistent ID in localStorage — you are still storing and accessing information on the device and question one still applies. The data path changed; the trigger did not.

Where server-side genuinely helps is question two and the transfer position: less data leaves the browser, you control what is forwarded, and you can strip identifiers before anything reaches a third country. Those are real benefits for the balancing test and for the transfer analysis. They are not a consent exemption.

Truly stateless measurement — no device identifier at all, no cross-session linking, aggregate counts only — sits differently, and is the closest thing to an exemption available. It is also, by construction, much less useful than the analytics most teams want.

Logged-In Product Analytics Is A Different Conversation

Website analytics and in-product analytics are usually treated as one topic and they are not quite the same.

Inside an authenticated product, you are already processing the user's personal data under a contract with your customer. The device-access question still applies, but the framing changes: your customer is the controller, you are the processor, and the consent obligation is theirs to discharge with their users rather than yours to discharge directly. What you owe your customer is the ability to honour that — a way to turn analytics off, or to not fire it before their consent signal arrives.

Two things are worth stating plainly to customers. Contract necessity under 6(1)(b) covers what is needed to deliver the service; it does not stretch to behavioural analytics, and the same limit applies to free trial and beta users, whose acceptance of terms does not import a basis for measurement. And session recording is its own case with its own analysis — whether session replay is legal under GDPR turns on questions this article does not settle.

Common Mistakes With Analytics Consent

Answering the cookie question with a lawful basis. Legitimate interest is an Article 6 answer to an Article 6 question. It does not address the separate requirement to obtain consent before storing or accessing information on a device.

Firing the analytics tag before the consent signal arrives. A banner that appears while the tracker has already loaded is the most frequently detected failure in this area, and it is a configuration problem rather than a legal one.

Treating anonymised as a synonym for aggregated. Truncating an IP address or hashing an identifier usually produces pseudonymous data, which is still personal data. Genuine anonymisation is a high bar and it is not reached by removing one field.

Relying on contract necessity because the user accepted terms. Article 6(1)(b) covers processing necessary to perform the contract. Measuring how someone uses the product is not necessary to provide it, and accepting terms of service is not consent to analytics.

Assuming a self-hosted tool removes the question. Self-hosting resolves the international transfer problem and improves the balancing test. It does not change whether you are storing an identifier on the user's device, which is where the consent requirement comes from.

FAQ

Do we need consent for analytics on a B2B product where users are at work?

Yes. The consent requirement for device storage and access attaches to the person using the device, not to whether they are acting in a business capacity. Business context can affect the balancing test at the Article 6 stage, but it does not remove the first question.

Can we make product analytics a condition of using a free tier?

That is difficult. Consent must be freely given, and conditioning access on consent to processing that is not necessary for the service is the situation the "freely given" condition was written to address. A free tier does not change the analysis, though the strength of your position depends on how genuinely optional the alternative is.

What about error monitoring and performance tools — do those need consent too?

Ask the same two questions. Where the tool is genuinely necessary for security or to deliver the service and stores nothing beyond what that requires, a stronger case exists for the strictly-necessary route. Where it also builds a user profile or links sessions over time, it has moved into the same territory as analytics.

Our customer's users are the data subjects. Whose job is the consent?

Where you act as processor, the controller is your customer and the obligation to obtain consent is theirs. Your obligation is to make it possible — to respect a consent signal, to allow analytics to be disabled, and to describe accurately in your documentation what fires and when. Silently collecting regardless of their configuration puts them in breach and you in breach of your instructions.

Closing Thought

The reason this question generates so much contradictory advice is that the two regimes have different tempers. GDPR is a risk-balancing instrument: it gives you six bases, asks you to reason, and rewards a documented judgement. The ePrivacy consent rule is not like that. It is a rule with a narrow exemption and no balancing available, and reasoning well about the second question does nothing for the first. Most bad analytics advice is the sound of someone applying GDPR habits to an ePrivacy question.

Getting it right is mostly sequencing: consent gate first, basis and balancing test second, both written down. ComplyDog provides a cookie consent banner alongside a compliance portal on your own domain covering your DPA, subprocessor list, data subject request forms and security page. It does not configure your analytics stack, write your balancing test or decide whether a given tool is strictly necessary — those are decisions about your product that stay with your team.

This article covers why you sit in both roles, who inside each organisation has authority to sign, whose paper prevails, whether a signature is required at all, and what to record once it is done.

You Are On Both Sides Of This Relationship

The role you occupy is decided by who determines the purposes and means of the processing, not by who is larger or who sends the invoice.

Your customer decides what data goes into your product, why, and for how long. That makes them the controller and you the processor for their data. Downstream, you decide which hosting provider, which error tracker and which email service to use, and for those relationships you are the controller and they are the processor.

There is a third slice people miss. You are also a controller for your own account and billing data — the customer's admin contacts, your usage records, your support history. Your customer is not instructing you on that, you are doing it for your own purposes, and it needs its own basis and its own description. Conflating it with the processor role is what produces DPAs that promise to delete "all data" on termination and then cannot, because some of it is yours to keep. What a DPA has to contain in either direction is set out in the canonical DPA guide; this article is only about the signing.

Who Inside Each Company Has Authority

The signatory is the legal entity, not the individual. The individual signs on the entity's behalf, and the entity named has to be the one that actually holds the relationship.

Three things go wrong here often enough to be worth checking. The wrong group entity gets named — the US parent signs when the contracting party is the UK subsidiary, or vice versa. The individual has no delegated authority, which is common when a DPA is routed to whoever happened to receive the questionnaire. And the entity named in the DPA does not match the entity on the master services agreement, which creates a genuine question about which contract governs what.

Practical rule: the DPA should be signed by the same entity that signed the underlying commercial agreement, by someone with authority to bind it. If your DPA is accepted through a self-serve flow, the flow should capture who accepted it and confirm they were authorised — which matters more than it sounds, because that record is the only evidence you will have.

Whose Paper Wins

Neither side has a legal right to insist on theirs. In practice it follows leverage, and the pattern is consistent: the larger party's template is used, and below a certain deal size the vendor's standard terms are accepted without negotiation.

For a small SaaS selling to enterprise, that means you will receive your customer's DPA and be asked to sign it. This is where the terms that hurt tend to appear — audit rights with short notice, deletion commitments on impossible timescales, sub-processor approval rights that require consent for each change rather than notice with a right to object, and liability positions inconsistent with the main agreement.

Two things make this manageable. Have your own DPA published and accessible so it is offered before theirs arrives, which resolves a surprising proportion of cases. And know which of your standard terms you can actually meet, because a negotiated commitment you cannot deliver is worse than one you refused. If the exchange started with a security review, the same principle applies as with the questionnaire itself — the document pack is easier to hand over than to reconstruct under time pressure.

Does It Actually Need A Signature?

Not in the sense most people mean. Article 28(9) requires the contract or other legal act to be in writing, including in electronic form. There is no requirement for a wet signature, and no requirement for a standalone document.

That means several forms are valid: a signed standalone DPA, a schedule to the master services agreement, terms incorporated by reference from a URL where the incorporation is clear and the customer has notice, and click-through acceptance in an account settings page. The last is how most self-serve SaaS handles it and it is entirely defensible when implemented properly.

What "properly" requires is that the terms were presented, the acceptance was a positive act, and you can evidence both later. A URL in a footer that nobody was directed to is not incorporation.

Two qualifications are worth carrying. National contract law still governs whether a party has actually agreed, and merely making a DPA visible is unlikely to be enough in most Member States — a positive act is needed. And the EDPB has recommended including signatures precisely so there is no difficulty demonstrating the contract is in force. Valid without a signature is not the same as easy to evidence without one. Where you do want a signed document — enterprise deals, procurement processes that require one, or simply because a countersigned PDF is easier to produce in a review — an e-signature service handles it, and DPA signing through Dropbox Sign is the kind of integration that turns this from a task into a link.

What To Record When It Is Signed

The signing is not the deliverable. The record is, because everything you will be asked afterwards is a question about the record.

Capture the entity on each side, the individual who signed and their role, the date, the version of the terms, whether it was a signature or an acceptance and by what mechanism, the sub-processor authorisation model and notice period, and where the executed copy lives. If transfer clauses were incorporated, note which instrument and which modules — that detail is the one most likely to be needed and least likely to have been written down.

Do the same in the other direction for every vendor DPA you accept, and keep the two registers in the same place. The question "who signed what, when, and which version" is asked in every serious vendor review, and it is far cheaper to answer from a register than from an inbox. The prior question of which vendors need a DPA at all determines how long that register needs to be.

Common Mistakes With DPA Signing

Signing the wrong entity. A group company that is not party to the commercial agreement signing the DPA creates a contract between parties with no underlying relationship. Match the entity to the master agreement every time.

Accepting a customer's DPA without reading the sub-processor clause. Per-change approval rights are common in enterprise templates and operationally severe. You cannot add a hosting region or swap an email provider without collecting consents you will not get promptly.

Treating a published DPA as executed. Publishing terms is an offer. Until the counterparty accepts them by a recorded positive act, nothing is in place, and "it is on our website" is not an answer to a due diligence question.

Losing the version. Vendors update their DPAs, sometimes materially. A register entry without a version and date cannot tell you what you agreed to, and re-deriving it after the fact is often impossible.

Letting whoever received the request sign it. DPAs routed through support or sales get signed by people with no authority to bind the company. It is not usually fatal, but it is exactly the defect a thorough reviewer finds.

FAQ

Can our customer refuse to sign a DPA and still use the product?

They can decline to sign yours, but the obligation under Article 28 falls on them as controller, so declining leaves them exposed rather than you. In practice, some customers ignore the DPA entirely. Making it available and recording that it was offered is the sensible position, and many providers make acceptance a condition of the account.

Is a click-through DPA legally valid?

Yes, where it is implemented properly. Article 28(9) requires writing including electronic form, not a signature. The terms must have been presented, accepted by a positive act, and both facts must be evidenced. A pre-ticked box or a link nobody was shown does not meet that. The EDPB nevertheless recommends signatures, so treat click-through as valid but harder to prove.

Do we need to re-sign when the DPA is updated?

It depends on the change mechanism in the existing agreement. Many DPAs allow updates on notice, in which case no re-signature is needed but the notice and effective date should be recorded. Material changes to sub-processing, transfers or liability usually warrant a fresh acceptance, and the safer course is to obtain one.

Who signs when a reseller or agency sits in the middle?

Follow the data rather than the invoice. If the reseller only bills and never touches personal data, your DPA is with the end customer. If the reseller administers the account and handles data on the customer's behalf, there are two relationships to paper and both need to be described, not one.

Closing Thought

The reason this question is asked so often is that it exposes something uncomfortable: most SaaS companies have a clear answer for the direction facing their customers and a vague one for the direction facing their vendors. The customer-facing DPA is polished, published and reviewed by a lawyer, because it appears in sales conversations. The vendor-facing side is a folder of PDFs and a few acceptances nobody recorded, because nobody sells to you. The second half is the one an auditor reads first.

Keeping both directions in one place, with versions and dates, is most of the work. ComplyDog hosts a compliance portal on your own domain covering your DPA, subprocessor list, data subject request handling and security page, with DPA signing through DocuSign and Dropbox Sign so the customer-facing side becomes a link rather than an email thread. It does not negotiate a customer's template for you or decide whether their audit clause is acceptable — those remain commercial judgements.

This article covers the test itself, the four categories every vendor list splits into, the suppliers people wrongly include, the ones they wrongly leave out, and how far down the chain the obligation reaches.

The Test Is Processing On Your Behalf

Article 28(1) frames it plainly: where processing is to be carried out on behalf of a controller, the controller uses only processors providing sufficient guarantees. Article 28(3) then requires the relationship to be governed by a contract or other legal act containing a specific set of terms.

Two conditions have to hold. There must be personal data, and the vendor must be handling it for your purposes rather than their own. Spending money with a supplier is irrelevant. So is the size of the contract, and so is whether the vendor is a technology company.

The most useful reframing is to stop asking "is this a big enough vendor to need paperwork" and start asking "if this vendor did something unexpected with the data, would I be the one who had to explain it." Where the answer is yes, they are processing on your behalf. The canonical DPA guide covers what a DPA contains and sets out the controller, processor and joint-controller roles in the abstract. What follows here is the applied sorting exercise: the suppliers people wrongly include, the ones they wrongly leave out, and how to find the ones nobody registered.

The Four Categories Your Vendor List Splits Into

Processors. They hold or handle personal data for your purposes: hosting, email delivery, CRM, support desk, analytics, error tracking, payroll software, backup providers. Article 28 contract required.

Independent controllers. They receive personal data but decide their own purposes and carry their own obligations: your bank, your accountant, your auditor, your law firm, an insurer. No DPA — you are not instructing them, and asking them to sign one misdescribes what they do.

Joint controllers. You and the vendor genuinely determine purposes and means together. Rarer than it is invoked, and where it is real, Article 26 requires a transparent arrangement setting out respective responsibilities rather than an Article 28 contract. Co-marketing arrangements and some embedded-partner integrations land here.

No personal data. Your CDN serving static assets with no logs reaching you, a design tool holding no customer records, a monitoring service that only sees aggregate metrics. Nothing required, but check rather than assume — most of these do log something.

The categories are not stable over time. A tool that started as category four moves to category one the day someone enables a feature that ingests user identifiers.

Vendors People Wrongly Think Need One

The most common unnecessary request goes to professional services firms. Accountants, auditors and lawyers are independent controllers with their own regulatory duties; they will usually decline to sign a DPA and they are right to.

Banks and payment institutions are the same. A payment processor is often a controller for the transaction data it must retain under financial regulation, even where it is a processor for other parts of the flow, and the position is usually set out in their own terms rather than negotiable.

Landlords, cleaners, utility providers and recruiters that source candidates on their own account also sit outside. So does a vendor whose product genuinely never receives personal data — though that group is smaller than it looks, because "we only send anonymous events" usually turns out to mean pseudonymous ones.

The cost of getting this wrong is not just wasted effort. A DPA signed with a party who is not a processor creates a document that describes a relationship neither side is operating, and that is worse evidence than having correctly concluded none was needed.

Vendors People Wrongly Leave Out

The gaps are more consistent than the false positives, and they cluster in engineering and internal tooling.

Error tracking and session tools capture user identifiers and payload fragments. Internal chat carries customer data the moment support pastes a ticket into a channel. CI and repository providers hold whatever ends up in fixtures and build output. AI and LLM vendors process whatever you send them, which is frequently customer content. Transcription and meeting-notes tools record named individuals saying things. Freelancers and agencies are their own question, and whether a contractor needs a DPA turns on whether they work under your direct authority rather than on their invoice.

The pattern is that these tools are adopted by individual teams on a credit card, without procurement, and they never reach the vendor list. The most reliable way to find them is not a survey but the card statement and the SSO application list, checked against the register you think you have.

Then there is the origin of most of this work. The reason companies build a vendor register at all is usually that a customer asked, and the request typically arrives inside a security questionnaire — which is why understanding what a SIG questionnaire is and why one just landed tends to precede the vendor review rather than follow it.

How Far Down The Chain It Goes

Your obligation is with your direct processors. Their obligation is with theirs. Article 28(2) requires a processor not to engage another processor without your prior specific or general written authorisation, and Article 28(4) requires them to impose the same data protection obligations downstream, remaining fully liable to you if the sub-processor fails.

That is why a subprocessor list matters and why the notification mechanism in a DPA is worth reading. General authorisation with a notice period and a right to object is the standard arrangement, and the practical question is whether you actually receive and review those notices or whether they route to an unmonitored address.

You do not sign contracts with your processors' processors. You do need to know who they are, because your customers will ask, and because the transfer position of a sub-processor two levels down can be the thing that makes your own answer wrong.

Common Mistakes With Vendor DPAs

Sending a DPA to every supplier on the ledger. It burns credibility with vendors who correctly refuse, and it buries the ones that matter. Sort the list first, then send.

Assuming free tools do not count. A free tier processes personal data exactly like a paid one. Free plans are also where you are least likely to find acceptable Article 28 terms, which is a reason to check rather than a reason to skip.

Treating the vendor's published DPA as accepted by default. Most require a positive step — a form, a signature, or acceptance in account settings. An unaccepted published DPA governs nothing, and this is the most common finding in a vendor review.

Never revisiting the classification. Vendors change what they do. A tool that held no personal data at adoption may now ingest user identifiers because someone enabled an integration eighteen months later.

Recording the DPA but not the version or date. When a vendor updates their terms, you need to know which version you agreed to and when. A register entry that says "DPA signed" and nothing else cannot answer the question a buyer eventually asks.

FAQ

Does a vendor who only stores encrypted data still need a DPA?

Yes. Encrypted personal data is still personal data if anyone can decrypt it, and storage is a processing operation under Article 4(2). Encryption is a security measure that improves your position considerably — including under Article 34(3)(a) after a breach — but it does not take the vendor outside Article 28.

What about a vendor outside the UK or EEA?

They still need a DPA, and they need a transfer mechanism as well. Those are two separate requirements and satisfying one does not satisfy the other. Many vendor DPAs incorporate transfer clauses by reference, which is fine, but confirm rather than assume.

Do we need a DPA with our own customers?

Usually the reverse — in a typical B2B SaaS relationship your customer is the controller and you are the processor, so you provide the DPA and they accept it. Where you also process their end users' data for your own purposes, you are a controller for that part and it needs describing separately.

How do we find vendors nobody registered?

Three sources catch most of them: the company card statement, the SSO or identity provider's application list, and DNS or outbound traffic if you have visibility. Ask teams as well, but ask against a list rather than asking an open question, because people do not think of the free tools as vendors.

Closing Thought

The instinct to send a DPA to everyone comes from a reasonable place — it feels like the cautious option, and caution is usually right in compliance work. Here it is not, because the document is a description of a relationship rather than a shield. Signing one with your accountant does not protect you; it records a claim about how you work with them that neither of you is acting on, and that inaccuracy is the thing that reads badly later. The cautious option is actually the accurate one.

The work that makes this tractable is a vendor register somebody keeps current, with a classification and a contract status against each entry. ComplyDog hosts a compliance portal on your own domain with your DPA, an auto-updating subprocessor list, data subject request forms and a security page, and it can handle DPA signing through DocuSign or Dropbox Sign. It does not classify your suppliers or decide which ones are processors — that judgement is yours, and it is the part that takes the afternoon.

This article covers what the accountability principle actually asks for, what one person can realistically hold, the recurring work that has to land somewhere, where a formal appointment obligation sits, and what the real failure mode looks like.

The Regulation Asks For Accountability, Not Headcount

Article 5(2) puts responsibility on the controller for the principles in Article 5(1) and requires it to be able to demonstrate compliance. Article 24 requires appropriate technical and organisational measures, reviewed and updated, taking into account the nature, scope, context and purposes of processing and the risks involved.

Both provisions scale with what you do, not with how many people you employ. A ten-person company processing health data for hundreds of thousands of users carries more obligation than a sixty-person company selling project management software to other businesses. Headcount is a poor proxy and the regulation does not use it as one.

What "demonstrate" means in practice is documentation: a record of processing activities, lawful bases you can name for each activity, retention periods somebody decided, a vendor list, and evidence that decisions were made rather than defaulted into. A single person can hold all of that. What a single person cannot do is hold it in their head.

That distinction is the whole of the argument. An undocumented programme run by three capable people demonstrates nothing, because there is no artefact to produce and no way to show a decision was taken rather than assumed. A documented programme run by one person produces the record on request. Regulators, buyers and data subjects all ask for the same thing, and it is never a headcount.

What One Owner Can Realistically Carry

The realistic shape for a company under roughly a hundred people is one accountable owner with a defined slice of their week, plus named contributors who do specific pieces within their existing roles.

The owner is usually a founder, a head of operations, a general counsel where one exists, or a technically literate ops person. What matters is that they have enough authority to say no to a product decision and enough proximity to engineering to know when something has changed. A privacy owner who finds out about a new subprocessor from a blog post is not positioned to do the job.

Named contributors then hold specific pieces: engineering owns access control and retention implementation, support owns the first response to data subject requests, whoever runs procurement owns vendor review. The owner does not do those things. They make sure they exist, they are current, and there is a record.

Time is the honest constraint. In a steady month this is a few hours. In the month a large customer runs a vendor review, or a subprocessor changes, or a request comes in that is not routine, it is much more — and how long that kind of review actually takes is the part that surprises people who budgeted for the steady state.

The Work That Has To Land Somewhere

Four things recur regardless of company size, and unowned versions of them are what actually fail.

Keeping the record current. New tools, new integrations, new data flows. The record of processing activities is only useful if it reflects this quarter.

Handling data subject requests on the clock. One month under Article 12(3), extendable by two further months for complex requests. This includes the awkward ones — portability requests in particular need a decided position before the first one arrives rather than after.

Reviewing vendors before they are adopted. Not after, because after means renegotiating or migrating.

Being ready for an incident. Article 33's 72-hour clock starts when you become aware, and a first draft of the assessment process written under pressure is a bad draft.

Keeping the privacy notice true. It is the one compliance artefact the public can read, and it drifts silently — a new subprocessor, a new purpose, a changed retention period, and the published description quietly stops matching what you do. Nobody complains, which is exactly why it goes unnoticed for years.

A periodic compliance audit is the mechanism that catches drift in all four. Quarterly is enough for most companies; the trigger events matter more than the calendar.

Where A Formal Appointment Obligation Sits

Article 37 requires a designated data protection officer in three situations: public authorities, controllers whose core activities require regular and systematic monitoring of data subjects on a large scale, and those whose core activities involve large-scale processing of special category or criminal offence data.

The important word is "core activities," and the qualifiers are about scale and nature. A company is not pushed over the line by growing from forty staff to ninety. It is pushed over by what it does — starting to process health data, or making large-scale behavioural monitoring the product rather than an incidental feature.

Whether your particular circumstances trigger that obligation, what the role requires in terms of independence and reporting, and how it differs from simply having an owner, is a bigger subject than this article covers and worth taking properly if you think you are near the threshold. The point here is narrower: it is not a headcount question, and the number of employees you have will not answer it.

Common Mistakes With Privacy Ownership

Assigning it to a role rather than a person. "Legal owns it" or "ops owns it" means nobody's name is on it. A named individual who knows they are accountable behaves differently from a function that has been mentioned in a policy.

Splitting ownership across founders without a decision-maker. Two people who both feel partly responsible produce slower decisions than one person who is fully responsible, and they produce no record of who decided what.

Hiring before documenting. A new privacy hire inherits an undocumented estate and spends their first quarter reconstructing it. Writing down what you already do is cheaper than paying someone to discover it, and it makes the hire more useful when it happens.

Treating the owner as a reviewer rather than a participant. If privacy review happens after the architecture is chosen and the vendor is signed, it produces objections nobody can act on. The owner needs to be early enough to change the decision.

Leaving the role behind when the person leaves. Privacy ownership is one of the responsibilities most likely to evaporate during a handover, because it is nobody's job title. It belongs on the offboarding checklist explicitly.

FAQ

At what size should we hire a dedicated privacy person?

There is no threshold in the regulation, and in practice it is driven by what you process rather than how many people you employ. The usual triggers are entering a regulated sector, taking on enterprise customers with heavy due diligence, processing special category data, or reaching the point where the existing owner cannot keep the record current. Volume of work is a better signal than headcount.

Can our lawyer or our security lead own this?

Either can, and both are common. A security lead usually has better proximity to systems and worse fluency in lawful bases; a lawyer is the reverse. What matters more is authority and time. The arrangement that fails is the one where the owner has the fluency but no standing to change a product decision.

Is an external consultant enough?

For advice, often yes. For accountability, no — Article 5(2) puts responsibility on the controller and you cannot contract it away. An external adviser works best alongside an internal owner who holds the decisions, not instead of one.

What is the minimum documentation a single owner should maintain?

A record of processing activities, a vendor and subprocessor list with contract status, a lawful basis noted for each processing activity, retention periods, a data subject request log, and a short incident response runbook. That set is achievable for one person and it is what you will be asked for.

Closing Thought

The question is usually asked as a resourcing question and it is really a design question. A privacy programme fails from work that nobody owns rather than from work that too few people do — a subprocessor added without review, a retention period never decided, a request handled by whoever happened to open the inbox. None of those are fixed by more people. They are fixed by one person knowing they are accountable and having somewhere to write things down.

That is also why documentation is the first investment rather than the last. ComplyDog hosts a compliance portal on your own domain with your DPA, subprocessor list, data subject request forms and security page, which turns the recurring answering work into a link and gives a single owner a place to keep it current. It does not make anyone accountable, decide your lawful bases or run your vendor reviews — the point of naming an owner is that those stay with a person.

This article covers the three positions a contractor can occupy, the statutory provision that separates them, the factors that decide which applies, what to put in place for each, and why the answer has consequences beyond data protection.

The Question Is Whose Authority, Not Whose Payroll

GDPR has a category most people forget sits between "employee" and "vendor." Article 4(10) defines a third party as anyone other than the data subject, controller, processor, "and persons who, under the direct authority of the controller or processor, are authorised to process personal data." Article 29 then says those persons must not process personal data except on the controller's instructions. Article 32(4) repeats the obligation as a security measure.

That category is what covers your employees. It is why you do not sign a DPA with your own staff. And nothing in the wording limits it to people on payroll — it turns on direct authority, not on employment contracts or tax treatment.

So the real question for a freelancer is which side of that line they sit on. If they work under your direct authority, they are within Article 29 and no DPA is required. If they process personal data on your behalf but under their own operational control, they are a processor and Article 28 applies. This is genuinely unsettled at the margins: when the EDPB consulted on its guidelines covering the concepts of controller and processor, one of the formal responses asked it to clarify precisely how Article 29 applies to external workers whose position is close to that of employees. The question being asked by a European federation of data protection officers is a fair signal that it is not obvious.

The Three Positions A Freelancer Can Occupy

Under your direct authority. A long-term contract developer who works in your systems, uses your accounts, follows your security policies, takes day-to-day direction from your team and has no independent discretion over the data. Functionally an employee for these purposes. Article 29 applies; no DPA.

A processor. An agency, a studio or an independent specialist who processes personal data for you but decides how they do it, works on their own infrastructure, serves other clients with the same setup, and exercises operational control. Article 28 applies and a contract is required.

Their own controller. A recruiter, an accountant, an occupational health provider or a lawyer who determines their own purposes and is subject to their own professional obligations. They are not processing on your behalf at all. No DPA — though a data-sharing position needs recording, and if you genuinely set the purposes jointly, Article 26 joint controllership brings its own arrangement requirement.

Most freelance relationships in a small SaaS fall into the first two, and companies default to the second because it feels safer. That default is not free: it means the contract commitments in Article 28(3) actually have to be met by someone who probably cannot meet them.

What Actually Decides It

There is no bright line, and the assessment is fact-specific. The factors that matter are the ones that show who exercises control in practice.

Whose systems is the work done on — your laptop, your SSO, your repositories, or theirs? Who sets the method, not just the outcome? Is the person integrated into your team, in your standups and your Slack, or engaged for a defined deliverable? Do they serve other clients with the same infrastructure? Do they have discretion over how personal data is handled, or do they follow your process?

The more integrated the person is, the stronger the argument that they act under your direct authority. Independent legal analysis of self-employed contractors reaches the same conclusion — the more integrated they are into the organisation, the more persuasive the case that they are in a position akin to an employee. Checked 8 August 2026, that remains the mainstream reading, and it has not been settled by a court.

Where you land, write it down. A one-line note in the engagement record saying which position the person occupies and why is cheap, and it is the difference between a considered judgement and an accident.

What To Put In Place For Each

For someone under your direct authority, you need documented instructions, a confidentiality commitment, access scoped to what the work requires, and offboarding that actually revokes it. Most companies already have an NDA in place, which covers the secrecy part and nothing else — the difference between confidentiality and processor obligations is exactly what separates a DPA from an NDA, and it is why one cannot substitute for the other.

For a processor, you need the Article 28 contract, and the terms that usually cause trouble with a small supplier are deletion or return at the end of the engagement, prior authorisation for anyone they bring in, and processing strictly on documented instructions. Ask a solo freelancer to commit to those and you often discover the relationship is really the first kind.

There is a third consideration that catches people out. If the contractor is outside the UK or EEA and personal data reaches them there, you have a transfer to handle on top of everything else, and the instrument you need for that is a separate question from the DPA itself.

This article is deliberately narrow — it is about employment status and the authority test. The broader question of which vendors need a DPA at all covers the rest of your supplier list.

Common Mistakes With Contractor Data Access

Signing a DPA with everyone to be safe. A DPA with someone who is actually under your direct authority misdescribes the relationship and commits both sides to obligations neither will meet. An unperformed contract is worse evidence than no contract, because it shows you knew the obligation existed.

Relying on the NDA. Confidentiality is one sub-paragraph of the eight things Article 28(3) requires. It says nothing about deletion, sub-processing, assisting with data subject requests or allowing audits, which are the terms that actually bite.

Giving contractors the same standing access as employees and no more paperwork. Whichever position they occupy, access should be scoped and time-bound to the engagement. The most common finding in a vendor review is an active account belonging to someone whose contract ended eleven months ago.

Treating overseas contractors as a purely contractual question. A developer in a third country receiving personal data is an international transfer. It needs a transfer mechanism regardless of how you have classified them for Article 28 purposes.

Assuming an agency's contract covers the individuals it supplies. If you contract with an agency, your Article 28 relationship is with the agency, and the individuals they place work under the agency's authority. If those individuals in practice take direction from you, the paperwork and the reality have diverged and only one of them is what a regulator looks at.

FAQ

Does a freelancer with read-only access still need a DPA?

Read-only access is still processing — retrieval and consultation are both listed as processing operations in Article 4(2). Whether a DPA is required depends on the authority question, not the permission level. A read-only contractor under your direct authority needs instructions and confidentiality; a read-only independent processor still needs Article 28 terms.

What if the contractor never touches customer data, only our internal systems?

Your own staff records are personal data too, so internal-only access does not remove the question. It usually reduces the volume and sensitivity, which affects how much scrutiny the arrangement warrants, but the analysis is the same one.

Can we just add data protection clauses to the services agreement?

Yes. Article 28 requires a contract or other legal act containing the required terms; it does not require a standalone document. A well-drafted schedule to the services agreement is entirely sufficient and often more likely to be signed than a separate DPA.

Does classifying a contractor as under our direct authority create employment risk?

It can, and it is worth flagging to whoever handles your contracts. The factors that support direct authority — integration, your systems, your direction, your process — are close relatives of the factors used to assess employment status for tax and employment rights purposes. The two analyses are legally distinct but they read the same evidence.

Closing Thought

There is an awkward symmetry in this question that is worth naming. The argument that avoids the DPA — this person works under our direct authority, in our systems, following our instructions, integrated into our team — is very close to the argument that they are not really a contractor. You can be comfortable on the data protection side or comfortable on the employment side, and the same set of facts is doing the work in both. Most companies resolve this by not thinking about it in one place at a time, which is fine until someone reads both files.

The honest resolution is to describe the relationship as it actually is and accept the consequences on both sides. ComplyDog can help with the part that faces outward — a compliance portal on your own domain covering your DPA, subprocessor list, data subject request forms and security page, including automated DPA signing through DocuSign and Dropbox Sign when a contract genuinely is needed. Deciding whether a particular contractor is a processor is a judgement about your own working arrangements, and no tool makes it for you.

This article covers how personal data ends up in a codebase, why deleting it is not a revert, what CI retention does that you did not configure, how this differs from a logging problem, and what to actually do about it.

The Places Personal Data Ends Up In A Codebase

Nobody commits a customer database. Personal data reaches repositories by smaller routes, and every one of them looks harmless at the moment it happens.

Test fixtures and seed data are the largest source, because the fastest way to build a realistic fixture is to copy a real record. Bug reports carry screenshots with a real user's name, email and sometimes their session content. Debug output pasted into an issue thread contains a real payload. A .env file with a support mailbox, an on-call phone number or an API key tied to a named account gets committed once and never noticed. Analytics or migration scripts embed a sample of live rows so somebody could check the output.

CI adds its own layer. Build logs capture environment variables and request payloads. Test artefacts include the screenshots the browser tests took, which include whatever the seeded user was called. Failed-job output is verbose by design, and verbose output is exactly the output that contains data.

Deletion Is Not A Revert, And That Is The Hard Part

Everywhere else in your stack, deleting personal data means running a delete. In git, a commit that removes a file leaves the file in history, reachable by hash, present in every clone and every fork, and mirrored into whatever backup or archive service you have connected.

Removing it properly means rewriting history — filtering the object out, force-pushing, invalidating every existing clone, and coordinating with everyone who has one. On a shared repository that is disruptive enough that teams routinely decide not to. That decision is understandable and it is also a decision to retain personal data indefinitely, which is a storage limitation problem under Article 5(1)(e) whether or not anyone frames it that way.

Two consequences follow. First, prevention is worth far more here than remediation, because remediation is genuinely expensive. Second, if you receive an erasure request and the data is in git history, you need an honest answer about what you can and cannot remove rather than a confident one. That is the same discipline that applies to deleting personal data from backups, where the practical constraint is similar and the accepted approaches — putting data beyond use, or maintaining a suppression record — are worth borrowing.

CI Retention Is A Setting Somebody Else Chose

Build logs and artefacts have a retention period. On most managed CI platforms that period is a default nobody on your team selected, it is measured in weeks or months, and it applies to output that may contain personal data.

Treat it as a retention decision, because it is one. Find the current setting, decide what it should be, and write the decision down with a reason. Where artefacts contain screenshots or payloads, a shorter period is almost always defensible and rarely costs anything, since nobody investigates a build from four months ago.

The other half is access. Repository and pipeline access is usually granted broadly — every engineer, often every contractor, sometimes every employee with an SSO account. If the pipeline output contains personal data, that access list is the recipient list for it, and it is generally much wider than the access list for the production database holding the same information.

This Is A Place Problem, Not A Logging Problem

There is a neighbouring question that answers differently and it is worth keeping apart. Whether the entries your application writes are personal data, how long you keep them and what lawful basis covers them is a question about logging as a practice, and it has its own answer. So does the narrower question of whether a given identifier in a log line counts as personal data.

What this article covers is different: personal data ending up in places built to hold code rather than data. The controls are different too. Log retention is a configuration decision on a system you designed to receive data. Repository hygiene is a prevention problem on systems that were never meant to receive it — secret scanning and pre-commit hooks, synthetic rather than copied fixtures, redaction in bug templates, artefact retention limits, and a rule about what may be pasted into an issue.

The nearest neighbour is test data generally. Whether you may use production data in a test environment is the question one step upstream, and if the answer there is disciplined, most of this problem never reaches your repository.

What This Costs When It Goes Wrong

The realistic failure is not a regulator reading your commit history. It is a repository access incident where the exposure assessment has to include everything in history rather than everything currently checked out, and those are very different numbers.

That assessment is what determines whether Article 33 notification to a supervisory authority is required within 72 hours and whether Article 34 communication to affected individuals follows. It is hard to run quickly if nobody knows what is in the history, which is the argument for keeping an eye on it before you need to.

It also determines what your insurer will and will not do. Whether cyber insurance is worth carrying for a SaaS turns partly on the forensic and notification costs of exactly this kind of incident, which are the costs cover genuinely addresses.

Common Mistakes With Repos And CI Output

Building fixtures by copying production rows. It is the fastest way to a realistic test and it puts real people into a system with no retention policy and very wide access. Generated or synthetic fixtures cost an afternoon once and remove the problem permanently.

Treating a deleted file as deleted data. A commit that removes a file leaves it in history, in every clone and every fork. If the data genuinely needs to go, it needs history rewriting, and if it does not, say so honestly rather than reporting a deletion that did not happen.

Leaving CI artefact retention on the platform default. Someone else picked that number and they did not know your build logs contain payloads. It is a retention decision about personal data and it should be made deliberately and recorded.

Pasting real payloads into issues and pull requests. Issue threads are searchable, exportable, often visible to contractors, and retained for the life of the project. A redacted example demonstrates the bug just as well.

Assuming a private repository is a security control that resolves the question. Private controls who can reach it, not what is in it or how long it stays. The access list for a private repo is usually wider than the access list for production, which is the opposite of what most people assume.

FAQ

Is source code itself personal data?

Generally no — code is not information relating to an identifiable person. But authorship metadata is: commit messages carry names and email addresses, and blame history links individuals to specific changes. That is employee personal data with an indefinite retention period, which is worth knowing even though it is rarely the pressing problem.

Do I have to rewrite git history if someone requests erasure?

Not automatically. The right to erasure is not absolute, and you may weigh technical feasibility, though inconvenience alone is a weak argument. What matters is that you assess it properly, document the reasoning, tell the person plainly what you have and have not removed, and stop the data being used. An unexplained refusal is the failure mode.

Does GDPR apply to a private repository nobody outside the company can see?

Yes. The regulation applies to processing, not to publication. A private repository holding personal data is processing that data, needs a lawful basis, a retention position and appropriate security. Being private is one of the security measures, not an exemption from the rest.

Do our CI and repository providers need a DPA?

If they host repositories or run pipelines containing personal data, they are processing it on your behalf and Article 28 applies. Most major providers publish one and it needs accepting rather than assuming. They also belong on your subprocessor list, which is where they are most often missing.

Closing Thought

The pattern here is that engineering systems accumulate personal data in exactly the places where nobody has authority to delete it. A product manager can decide a customer table's retention period. Nobody owns the retention period of a four-year-old test fixture, and everyone who could rewrite the history has a good reason not to. That is why this problem grows quietly rather than dramatically, and why the only cheap intervention is upstream — stop the data getting in, because getting it out is genuinely hard and will stay that way.

Practically, that means secret scanning, synthetic fixtures and an artefact retention setting somebody chose on purpose. ComplyDog covers the customer-facing half — a compliance portal on your own domain with your DPA, subprocessor list, data subject request handling and security page — which is what a buyer reviews when they ask how you handle their data. It does not scan your repositories, rewrite git history or set your CI retention, and no compliance tool can; that part belongs to whoever owns the pipeline.

This article covers why internal tools carry the same obligations as customer-facing ones, where staff data enters the picture, why access control is the operative safeguard, how these systems belong in your Article 30 record, and what buyers ask about them.

The Data Is The Same Data

Data mapping exercises almost always start at the product. Someone lists the signup flow, the billing integration, the email provider and the analytics stack, and stops when the customer-facing surface is covered. The internal admin panel — the one that lets support search every account by email, view a user's session history and impersonate them — is not on the list, because nobody thinks of it as a place data goes. It is a window onto data that is already somewhere else.

That intuition is wrong in a specific way. The admin tool is not just a view. It usually adds something: an internal notes field, a support ticket history, a risk flag, a churn score, an exported CSV sitting in someone's downloads folder. Those are new personal data, created by you, about your customers' users, and frequently with no retention period attached.

Metabase dashboards, retool panels, internal Slack alerts carrying customer identifiers, and the analytics warehouse that everyone queries directly are all the same story. Personal data flows into places that were never in scope because they were built for staff.

Your Own Staff Are Data Subjects

The second half is simpler and gets missed more often. Employee and contractor personal data — accounts, access logs, HR records, performance notes, internal directory entries — sits inside these tools, and GDPR does not carve out processing about your own people.

There is a boundary worth drawing carefully here. Monitoring people at work — keystroke logging, screen capture, productivity scoring — is a separate subject with its own lawful basis analysis, and workplace cameras and premises monitoring belong to the physical premises case rather than to this one. This article is about the tools themselves and the access they grant, not about surveillance of the people using them.

What is in scope here is mundane and still real: staff account records need a retention period, offboarded employees need their access revoked and their data handled, and an internal directory that quietly retains leavers for years is a storage-limitation problem in exactly the way a stale customer table is.

Access Is The Control That Actually Matters

Article 32 requires appropriate technical and organisational measures, and for an internal tool the measure that carries the most weight is access control. Article 32(4) makes the related point explicitly: anyone acting under your authority with access to personal data must not process it except on your instructions.

That translates into a small number of concrete things. Read access should be scoped rather than universal — support does not need the whole table to answer a ticket. Impersonation, the "log in as this user" feature that exists in almost every B2B SaaS admin panel, needs to be logged, attributable and ideally consented to or at least disclosed. Exports need to be constrained, because an unconstrained CSV export is a data breach waiting for a laptop to be stolen.

The distinction worth holding onto is between a tool being secure and a tool being scoped. Most internal panels are secure — behind SSO, on the VPN, with MFA. Far fewer are scoped, and a fully authenticated engineer with production database access is a much larger surface than the login page they came through.

Internal Systems Belong In Your Article 30 Record

If a system processes personal data, it goes in your record of processing activities with a purpose, categories of data and data subjects, recipients, retention and a description of security measures. Internal tools qualify, and leaving them out is the most common gap we see when a record is reviewed.

The same applies to data subject requests. When a customer's user exercises a right to erasure, the deletion has to reach the internal notes field and the exported dataset in the warehouse, not only the production row. A DSR process that covers the product and misses the admin layer produces a confident, incorrect response.

Test and staging environments are the closest neighbour to this problem and deserve their own treatment — whether you can use production data in a test environment is a distinct question with a distinct answer, and it is where a lot of internal exposure actually lives.

Common Mistakes With Internal Tools And Dashboards

Mapping the product and calling it the data map. Internal admin panels, warehouses and BI dashboards are processing systems. A map that stops at the customer-facing surface will always be incomplete, and it will be incomplete in the direction of the systems with the widest access.

Treating authentication as sufficient scoping. SSO and MFA control who gets in. They say nothing about what a person can see once inside. Blanket read access to every customer record is a design decision, and it is one you have to justify.

Leaving impersonation unlogged. Logging in as a user is the single most sensitive capability in most B2B products. If it is not attributable to a named person with a timestamp and a reason, you cannot investigate a complaint about it, and you cannot demonstrate it was not abused.

Forgetting internal notes when handling erasure. Support notes, risk flags and internal comments are personal data about the person they describe. A deletion that clears the production record and leaves the notes behind has not done what you told the data subject it did.

Assuming staff data is out of scope because it is your own team. Employee, contractor and applicant records are personal data with the same obligations. Retention periods for leavers are the specific thing that gets skipped, usually because nobody owns the internal directory.

FAQ

Do internal tools need to appear in my privacy notice?

Your privacy notice describes purposes and recipients, not individual pieces of software, so you do not need to name the tool. But if an internal system does something a reader would not expect — support staff viewing session recordings, or an internal risk score attached to their account — the purpose belongs in the notice even though the tool does not.

Does a customer's data subject request reach my internal dashboards?

Yes. The request applies to all personal data you hold about the person, wherever it sits. If your warehouse holds a copy, your admin panel holds notes, or an export sits in cloud storage, those are in scope. Building the request process around the production database alone is the reliable way to answer wrongly.

Are we allowed to give engineers production access at all?

There is no prohibition, but there is an expectation that access is necessary and controlled. Break-glass access with logging, time limits and a recorded reason is defensible. Standing, unlogged, unrestricted production access for everyone in engineering is much harder to justify if you are ever asked to.

Do internal tools built in-house need a DPA?

Not with yourself. A tool you build and host does not involve a third party, so there is no processor and no Article 28 contract. The moment you build it on a third-party platform — a hosted BI tool, a low-code internal app builder, a managed warehouse — that provider is a processor and does need one.

Closing Thought

Internal tools escape scrutiny for a structural reason rather than a careless one. Compliance work is organised around things customers see, because those are the things customers ask about, and the admin panel has no external surface to review. So the system with the broadest access in the entire company is often the one with the least documentation, and it stays that way until a support engineer exports something they should not have or a buyer asks who can see their data and the honest answer turns out to be everyone.

Working out who can see what is a mapping exercise, and it is worth doing before the question arrives from outside. ComplyDog gives you a compliance portal on your own domain covering your DPA, subprocessor list, data subject request forms and security page, which is what buyers ask to see once they start asking. It does not scope your admin permissions, audit your access logs or build your Article 30 record — those stay internal work, and this is one of the areas where the internal work is the whole job.

This article covers why public does not mean non-personal, what lawful basis scraping actually runs on, the Article 14 duty and its one-month clock, how narrow the disproportionate-effort exception really is, and where this bites inside a normal B2B SaaS.

Public Availability Is Not A Property Of The Data

Article 4(1) defines personal data as information relating to an identified or identifiable natural person. There is no clause about where you found it. Recital 26 sets the identifiability test — whether identification is reasonably likely using means available to you or to anyone else — and that test is indifferent to whether the source page required a login.

A public LinkedIn profile, a company team page, a GitHub commit history, a conference speaker list and a review with a display name are all personal data. So is a business email address in the form firstname.lastname@company.com, which is the format most scraped B2B lists are made of.

The practical consequence is that scraping does not create a special category of lower-obligation data. It creates ordinary personal data with a worse paper trail, because you have no signup record, no consent log and no timestamp for when the person entered your systems.

One thing this article does not cover: training machine-learning models on scraped corpora is a different question with its own developing guidance, and none of the reasoning below is intended to answer it.

Your Lawful Basis Is Article 6, And It Is Rarely Consent

You cannot obtain consent from someone who does not know you exist, so scraping runs on Article 6(1)(f), legitimate interests, or it runs on nothing. That means a documented balancing test before collection, not a rationalisation afterwards.

The balancing test is harder for scraped data than for data someone handed you, and the reason is reasonable expectations. A person who published their work email on a company site expects to be contacted about that company's business. They do not necessarily expect to be enriched, scored, profiled against firmographic data and held for three years.

Two constraints do real work here. Article 5(1)(b) purpose limitation means the interest you documented is the only one you may pursue — a list collected to research a market cannot quietly become a sales list. And Article 21 gives an unqualified right to object where processing is for direct marketing, with no balancing exercise available to you at that point. Where scraped contact data is used for outreach, separate marketing rules apply on top of the GDPR analysis; that is its own subject and this article does not attempt it.

Article 14 Is The Obligation Almost Everyone Skips

When personal data is obtained from someone other than the data subject, Article 14 rather than Article 13 applies, and it carries a timing obligation Article 13 does not: within a reasonable period after obtaining the data and at the latest within one month, or at the point of first communication with the person if that comes sooner.

Article 14 also requires something Article 13 does not — under 14(2)(f) you must tell the person the source the data came from, and whether it came from a publicly accessible source. That is a specific disclosure about your scraping, not a generic line in a privacy notice.

The information itself is the same set that any privacy notice or privacy policy has to carry: identity, purposes, lawful basis, recipients, retention, rights. What changes is that you have to actively deliver it to people who never visited your site, and you have to do it on a clock.

The Disproportionate-Effort Exception Is Narrower Than Its Reputation

Article 14(5)(b) lifts the obligation where providing the information proves impossible or would involve a disproportionate effort. This is the provision scraping operations lean on, and it is read far more restrictively than most teams assume.

The text itself narrows it. It names the situations it has in mind — archiving in the public interest, scientific or historical research, statistical purposes, subject to the Article 89(1) safeguards — and commercial lead generation is not among them. Recital 62 gives the three factors to weigh: the number of data subjects, the age of the data, and any appropriate safeguards you have adopted.

Read those three factors honestly and a typical B2B scrape fails. The dataset is small enough to notify, the data is recent, and you hold the person's email address, which makes notification not merely possible but cheap. Impossibility is not the same as inconvenience.

Where the exception genuinely applies, it is not a free pass either. You are expected to document the assessment per project rather than adopt it as policy, and to publish a public notice describing the scraping. UK readers should note separately that the Data (Use and Access) Act 2025 restructures these transparency exceptions in UK GDPR, including a route in Article 13 that EU GDPR does not have. We have not verified which of those provisions are in force as at 8 August 2026, and the commencement is staged — confirm the current position with the ICO before relying on it.

Where This Actually Bites In A B2B SaaS

Most SaaS companies scrape without calling it scraping. An enrichment vendor appends firmographic and contact data to your signups. A competitor-monitoring script pulls pricing pages that carry named testimonials. A support tool ingests public review sites. A hiring workflow collects candidate profiles from public sources.

Each of those is Article 14 territory, and in the enrichment case there is a second problem: your vendor obtained the data, so you need to know their source to make your own 14(2)(f) disclosure. Most enrichment contracts do not tell you, and the ones that do describe it in a way that would not survive being read out to a regulator.

The work email addresses that make up these lists are the clearest case, because the identifiability question is settled and the volume is high. And every one of these flows belongs in your record of processing activities, listed with its source, its basis and its retention period, which is usually the point at which somebody notices the list has been sitting there since 2023.

Common Mistakes With Scraped Personal Data

Treating public as a lawful basis. Public availability is a fact about the source, not a legal ground. You still need one of the six bases in Article 6, and you still need to be able to name which one before you collect anything.

Writing the legitimate interests assessment after the scrape. A balancing test produced in response to a complaint is evidence of the problem, not a defence. It has to exist before collection, name the specific interest, and be revisited when the purpose changes.

Assuming Article 14 does not apply because there was no relationship. The absence of a relationship is precisely what triggers Article 14 rather than Article 13. Having never spoken to the person is the condition for the obligation, not an exemption from it.

Invoking disproportionate effort as a blanket policy. The exception is assessed per project against the number of people, the age of the data and your safeguards. Applying it to every dataset by default is the pattern regulators look for.

Keeping scraped records indefinitely because they cost nothing to store. Storage limitation under Article 5(1)(e) applies to data you never asked for as much as to customer data. A scraped list with no retention period is an accumulating liability attached to people who do not know you hold it.

FAQ

Does GDPR apply if I only scrape company information, not people?

Company data about a legal person is outside the GDPR under Recital 14. In practice the two are rarely separable — a company page carries named staff, direct dial numbers and individual email addresses, and those are personal data. If your scrape returns anything attached to a named human, treat the dataset as personal data.

Do I have to notify every person on a scraped list individually?

That is the default under Article 14, within one month or at first contact if sooner. You can be relieved of it where notification is genuinely impossible or disproportionate, but that is a per-project assessment weighing the number of people, the age of the data and your safeguards — not a standing policy, and not satisfied by a privacy page nobody is directed to.

Is scraping data that someone deliberately made public still a privacy issue?

Yes, because publishing data for one purpose is not agreement to every other purpose. Someone who put their email on a company site to receive customer enquiries has not agreed to be added to a prospecting database. Purpose limitation under Article 5(1)(b) is the provision that carries the point.

What if a vendor does the scraping and sells me the list?

You are a controller for what you then do with it, and your Article 14 obligations are yours rather than theirs. You need to know the source well enough to disclose it under 14(2)(f), and you need contractual assurance about how the data was obtained. If the vendor will not tell you, you cannot comply, and that is a reason not to buy the list.

Closing Thought

The uncomfortable part of Article 14 is that it is the one obligation that makes scraping visible to the people you scraped. Every other requirement can be met internally — write the assessment, set the retention period, secure the store — and nobody outside the company ever knows. Notification is different. It tells a stranger you have been holding their data, and it invites them to object. That is not an accident of drafting. It is the point of the provision, and it is why the disproportionate-effort exception gets argued so hard by people whose real objection is not the effort.

If your prospecting, enrichment or research flows are the ones nobody has mapped yet, the fix starts with writing them down rather than buying anything. ComplyDog hosts a compliance portal on your own domain covering your DPA, subprocessor list, data subject request handling and security page, which makes the answering side of this easier when a buyer or a data subject asks. It does not build your Article 30 record for you, decide your lawful basis, or notify a scraped list — those are judgement calls that stay with you.

This article covers the wording that settles it, the one genuine nuance about who you are actually targeting, which lawful basis fits a free trial, why beta programmes raise sharper questions, and what to do with the data when the trial ends.

The Wording Settles It

Most GDPR questions require you to reason from principles. This one does not.

Article 3(2)(a) extends the regulation to organisations outside the Union where processing relates to "the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union." The EDPB's Guidelines 3/2018 on territorial scope, checked on 8 August 2026, put it plainly: whether an activity counts as an offer of goods or services does not depend on whether payment is made in exchange.

That phrase was drafted precisely because the free-service business model was already dominant. Legislators anticipated exactly the argument that unpaid users are outside scope, and closed it in the text.

The same conclusion follows from the definition side. Article 4(1) defines personal data by reference to an identifiable natural person. Nothing about the definition, or about data subject rights, is conditioned on a commercial relationship. Recital 14 also confirms that nationality and residence are irrelevant; what matters is that the person is in the Union.

The One Genuine Nuance

There is a real qualifier, and it is not about payment.

Recital 23 says that the mere accessibility of your website in the Union, the mention of an email or postal address, or a phone number without an international dialling code, does not by itself demonstrate an intention to offer goods or services to people in the Union. The EDPB adds that where services are inadvertently or incidentally provided to someone in the EU, the related processing does not fall within territorial scope.

The test is whether you envisage offering your service to people in one or more Member States. Indicators include using a Member State language or currency, mentioning EU customers, running EU-targeted advertising, or offering delivery or support in the region. This mirrors the "directing activities" line of CJEU case law under the Brussels regime, in Pammer and Hotel Alpenhof.

So a genuinely domestic US product that one German developer happens to find and sign up for is in a different position from a product with a Europe page, euro pricing and a Berlin-timezone support rota. Note how narrow this actually is in practice: most SaaS companies with a self-serve trial are targeting a global market by design, and the moment you accept EU signups as a matter of course you have answered the question. It is also a poor foundation for a compliance position, because it depends on continuing not to want the customers.

Which Lawful Basis Fits A Trial

The absence of payment does not mean the absence of a contract. A trial user has accepted your terms of service, which is a contract, so Article 6(1)(b) is generally available for the processing necessary to provide the trial: account creation, authentication, delivering the product, support.

Where teams overreach is everything else. Product analytics, behavioural scoring, sales outreach and enrichment are not necessary to perform the trial contract, and stretching 6(1)(b) to cover them is a common and visible error. Legitimate interests under 6(1)(f) is usually the right basis for analytics and follow-up, provided you have done and documented the balancing test. Non-essential cookies and similar tracking have their own consent requirement under the ePrivacy rules regardless of which GDPR basis you rely on.

The signup form itself deserves a moment. Work email addresses collected at signup are personal data, which is straightforward but has consequences for what you can do with them afterwards, as our article on work email addresses sets out. If you enrich those signups from a data vendor, Article 14 applies and you owe the person information you did not have to give when they typed the address in themselves.

Beta Programmes Raise Sharper Questions

Betas are where the assumptions get riskier, because the informality of the arrangement is mistaken for informality in the obligations.

Beta software typically collects more than production software: verbose telemetry, session recordings, crash dumps with fuller context, feedback forms. Each is processing that needs a basis and a retention period, and "we needed the data to fix bugs" is a purpose, not a lawful basis.

Two specific traps recur. Beta participants are often told their feedback will be used to improve the product, which is fine, and are then quoted in marketing, which is a different purpose requiring its own basis. And betas frequently run on non-production infrastructure with weaker access controls, which is an Article 32 problem rather than a lawful basis one, and the same family of risk as copying live records into a staging environment.

A free beta with EU participants is also a service offering under Article 3(2)(a). If you have no EU establishment, that can be the thing that triggers the representative requirement discussed in our article on Article 27.

What Happens When The Trial Ends

This is the operational question, and the one most teams have never answered deliberately.

Storage limitation under Article 5(1)(e) means personal data must be kept no longer than necessary for the purposes it was processed for. When a trial expires without conversion, the purpose that justified most of the processing has ended. The account, its contents, the telemetry and the enrichment data all need a decided retention period.

The default in most products is indefinite, because nobody chose otherwise and deleting things is work. That is not a position you can defend, and it accumulates: a product with a popular free trial can hold more personal data about people who never became customers than about those who did.

Sales follow-up complicates it, legitimately. Retaining a lapsed trial contact for a defined period on a legitimate interests basis is often defensible; retaining it for six years because the CRM has no expiry field is not. Pick a period, write down why, and automate it, which is what automated retention cleanup is for.

Common Mistakes With Free Trial And Beta Users

Believing unpaid users are out of scope. Article 3(2)(a) applies irrespective of whether payment is required. This is the misconception the wording was written to prevent.

Stretching contractual necessity across everything. Article 6(1)(b) covers processing needed to deliver the trial. Analytics, scoring and outreach need their own basis, usually legitimate interests with a documented assessment.

Keeping expired trial data indefinitely. Storage limitation applies from the moment the purpose ends. Unconverted trials are the largest pool of undecided retention in most SaaS products.

Treating beta participants as informal collaborators. Enthusiasm is not consent, and a Slack channel is not a lawful basis. Betas usually collect more data than production, not less.

Assuming a free tier does not trigger the representative requirement. If Article 3(2) reaches you and you have no EU establishment, a free product can be exactly what puts you in scope.

FAQ

Does GDPR apply if we do not charge users anything?

Yes. Article 3(2)(a) covers the offering of goods or services irrespective of whether payment is required, and the definition of personal data does not depend on a commercial relationship. Free products, trials and betas all fall within scope on the same terms as paid ones.

Do trial users have the same rights as paying customers?

Yes, in full. Access, rectification, erasure, portability, objection and the rest apply identically. A trial user can submit an access request the day after signing up, and the one-month response clock runs exactly as it would for a customer.

How long can we keep data from an expired free trial?

As long as you have a purpose that justifies it, and no longer. Sales follow-up on a legitimate interests basis for a defined period is often defensible; indefinite retention because nobody set an expiry is not. Decide the period and automate its enforcement.

Do we need consent to email trial users about the product?

Not necessarily. Service messages about the trial itself are part of delivering it. Marketing messages are a separate purpose with their own rules under both GDPR and the applicable electronic communications regime, which differ depending on the recipient and the market.

Closing Thought

The reason this question persists is not that the law is ambiguous, because on this narrow point it is unusually clear. It persists because free users feel like a different category commercially, and it is easy to let a commercial intuition harden into a legal assumption nobody checked.

The more awkward observation is what the answer implies about volume. A product with a generous free tier probably holds personal data on far more people who never paid than people who did, distributed across analytics, CRM and telemetry systems that were built for growth rather than deletion. ComplyDog hosts a compliance portal on your own domain with self-serve data subject request handling, your subprocessor list and your security page, which matters more when the requests can come from anyone who ever signed up. It does not decide your retention periods, which is the part that needs a human to make a call.

This article covers what each instrument is, the modular structure that trips people up, why BCRs are rare, how the Data Privacy Framework changes the picture, and which one your vendors are actually using.

Two Instruments, Two Very Different Costs

Both sit in Chapter V of the GDPR, which governs transfers of personal data outside the EEA, and both are what the regulation calls appropriate safeguards.

Standard contractual clauses are adopted by the European Commission under Article 46(2)(c). The current set comes from Commission Implementing Decision (EU) 2021/914 of 4 June 2021, published in the Official Journal on 7 June 2021, replacing clauses that dated from 2001, 2004 and 2010. You adopt them by signing them. No regulator approves your particular use, and no one grants you permission.

Binding corporate rules sit in Article 47. They are a set of internal policies binding on every entity in a corporate group, and they must be approved by a lead supervisory authority through the consistency mechanism, with the European Data Protection Board issuing an opinion. Approval is a formal regulatory process that typically runs to a year or more.

The practical difference follows from that. SCCs are available to anyone. BCRs are available to organisations willing to fund a long regulatory approval process, and they only help with intra-group transfers. A BCR does nothing for the transfer to your payment processor.

The Modular Structure Is Where People Go Wrong

The 2021 clauses are not a single document. They contain four modules and you use the one matching the relationship:

Module One — controller to controller. Module Two — controller to processor. Module Three — processor to processor, which is what applies when you are a processor for your customer and you engage a sub-processor outside the EEA. Module Four — processor to controller.

Picking the wrong module is a real and common error, and it is not cosmetic: the obligations differ meaningfully between them. A SaaS company is usually the importer under Module Two when contracting with EU customers, and the exporter under Module Three when it passes data to its own vendors. Both can be true simultaneously, in the same data flow.

There is also a separate instrument that shares the date and confuses almost everyone. Commission Implementing Decision (EU) 2021/915, also of 4 June 2021, sets out standard contractual clauses between controllers and processors under Article 28(7). Those are model DPA terms for use inside the EEA. They are not a transfer mechanism, they do not appear in Chapter V, and adopting them does nothing to legitimise a transfer to a third country.

Why Almost No One Has BCRs

The approval burden explains the scarcity. Article 47(2) sets out what BCRs must contain, including the structure of the group, the transfers covered, the binding nature internally and externally, the application of the general data protection principles, the rights of data subjects, and acceptance of liability by an EU-established member of the group for breaches by members outside it.

That last element is the one that stops most projects. An EU entity must accept liability for what its non-EU affiliates do with personal data. That is a commercial decision as much as a legal one.

The result is that BCRs are held by large multinationals and almost nobody else. They are also more common on the controller side than the processor side. Among the twelve vendors examined for this blog on 7 August 2026, exactly one had approved BCRs: Twilio, which publishes a Processor Policy covering Segment. Very few processors hold them, which is why our look at whether Segment is GDPR compliant treats it as the unusual case that it is.

Where The Data Privacy Framework Fits

Neither instrument is needed where an adequacy decision covers the transfer, because under Article 45 the transfer requires no additional safeguard at all.

This matters enormously for US transfers. The EU-US Data Privacy Framework was adopted in July 2023, and where a US recipient is certified under it, transfers to that recipient are covered by adequacy. That is why the dominant pattern in vendor contracts is now DPF first, with SCCs sitting behind as a fallback if certification lapses or does not cover the transfer.

Any resource still describing the position as "Privacy Shield was invalidated, so use SCCs" is describing 2020 rather than today. Cloudflare's addendum states that a transfer to the US under the DPF is not a restricted transfer at all, and provides that Cloudflare will notify customers if its certification lapses, at which point the SCC provisions engage. That is the structure to expect.

Our guide to international transfers covers the broader transfer landscape and the mechanisms available. Note that the DPF postdates parts of it, so check the date on anything describing the post-Schrems II position.

Which One Your Vendors Are Actually Using

You will rarely choose between these instruments in the abstract. You will encounter them in a vendor's paperwork and need to work out what you have got.

The patterns from the vendor DPAs verified on 7 August 2026 are consistent. Zapier incorporates the SCCs automatically if the DPF is invalidated or does not cover, including the C2P and P2P modules, the Swiss amendments, the UK Addendum and Brazilian clauses. Sentry puts the DPF first with SCCs behind it, applying Modules Two and Three. Vercel is the outlier, relying on the SCCs and a UK transfer instrument rather than the DPF.

Two things to record every time: which mechanism applies, and which module. A DPA that says "the SCCs apply" without specifying the module has left the most consequential question open.

Note also that transfers and storage location are separate questions. A vendor can rely on the DPF and still store your data in Frankfurt, or rely on SCCs and store it in Virginia. The question of whether the law requires EU storage at all is a different one entirely.

Common Mistakes With Transfer Mechanisms

Signing SCCs without selecting a module. The 2021 clauses only work once you specify which of the four applies and complete the annexes. An unmodularised set of clauses is an incomplete contract.

Confusing Decision 2021/915 with Decision 2021/914. The first provides model Article 28 terms; the second provides transfer clauses. Same date, entirely different function, and the numbers differ by one digit.

Treating BCRs as an aspiration for a small company. Approval requires a lead supervisory authority, an EDPB opinion and an EU entity accepting liability for its affiliates. For most companies that effort is better spent elsewhere.

Assuming BCRs cover external vendors. They bind members of your corporate group. Every transfer to a third party still needs its own mechanism.

Repeating the post-Schrems II position without checking the date. The Data Privacy Framework was adopted in July 2023 and changed the default for US transfers. Guidance written before then, including some still ranking well, describes a landscape that has moved.

FAQ

Do I need SCCs if my vendor is certified under the Data Privacy Framework?

Not for that transfer while the certification holds, because adequacy under Article 45 removes the need for an additional safeguard. Most vendor DPAs still incorporate SCCs as a fallback, which is sensible given the litigation history of adequacy decisions covering the United States.

Can a small company get binding corporate rules approved?

In principle yes, in practice almost never. Approval runs through a lead supervisory authority and an EDPB opinion, typically takes a year or more, and requires an EU group entity to accept liability for non-EU affiliates. BCRs also only cover intra-group transfers, so a small group gains little.

Which SCC module applies to my SaaS?

Usually Module Two when an EU customer sends you personal data as their processor, and Module Three when you pass that data to your own sub-processors outside the EEA. Both commonly apply to the same data at different stages of its journey.

Do the SCCs cover UK transfers?

Not by themselves. The UK operates its own regime, using either the International Data Transfer Agreement or the UK Addendum bolted onto the EU clauses. Vendors serving both markets typically incorporate the Addendum, but check rather than assume.

Closing Thought

The choice framed in the title is not really a choice for most readers, and presenting it as one obscures what actually matters. Nobody weighs SCCs against BCRs the way they might weigh two vendors. One is available to you and the other realistically is not.

The useful work is knowing which mechanism each of your vendors relies on, which module they selected, and what happens if the underlying adequacy decision falls over again, because it has twice. ComplyDog hosts a compliance portal on your own domain covering your DPA, subprocessor list, data subject request handling and security page, which keeps that record in one place rather than scattered across signed PDFs. It does not negotiate transfer terms with your vendors, which remains a job for someone reading the actual clauses.

This article covers who the obligation catches, what the exemption actually requires, what a representative does and does not do, how the UK equivalent differs, and how to tell whether the requirement has been met.

Who The Obligation Catches

Article 27(1) is short: where Article 3(2) applies, the controller or processor shall designate in writing a representative in the Union.

Everything therefore turns on Article 3(2), which brings non-EU organisations into scope where processing relates to offering goods or services to data subjects in the Union, irrespective of whether payment is required, or to monitoring their behaviour within the Union.

Two consequences follow that surprise people. A free product counts, because payment is expressly not the test. And behavioural monitoring is a low bar: analytics, session tracking and profiling of EU visitors all qualify.

If you have an establishment in the EU, Article 3(1) applies instead and Article 27 does not bite. This is why creating an EU subsidiary that actually performs the processing is a genuine alternative to appointing a representative, though it is a much larger commitment.

The Exemption Is Cumulative

Article 27(2)(a) disapplies the obligation for processing which is occasional, does not include large-scale processing of special category data under Article 9(1) or criminal offence data under Article 10, and is unlikely to result in a risk to the rights and freedoms of natural persons, taking into account the nature, context, scope and purposes of the processing. Article 27(2)(b) exempts public authorities.

Read that carefully, because every condition must be satisfied. Failing any one of them defeats the exemption entirely.

"Occasional" is the condition that removes most SaaS companies. A product that processes EU user data continuously, as a normal part of its operation, is not processing occasionally. The EDPB has interpreted this narrowly and consistently, and a subscription service running every day is a poor candidate.

The honest position is that the exemption was written for genuinely sporadic processing, not for small companies. Being small is not the test. A two-person SaaS with EU customers processes personal data continuously and is caught, while a company that processes one EU applicant's CV a year may not be.

What A Representative Actually Does

The mandate must be in writing, and the representative must be established in a Member State where the data subjects whose data you process are located.

The representative acts as the addressee for supervisory authorities and data subjects on all issues relating to processing. In practice that means receiving correspondence from regulators, being reachable by individuals exercising their rights, and maintaining a copy of your record of processing activities so it can be produced on request.

Three things it is not. It is not a data protection officer: different role, different criteria, different independence requirements, and one person can hold both only if the conflicts work out. It is not a shield: designating a representative does not reduce your own responsibility or liability by any amount. And it is not a mailbox that can be left unattended, since the representative is exposed to enforcement action taken in respect of your processing.

The appointment also has to be visible. A representative nobody can find has not been effectively designated, which is why the details belong in your privacy information alongside your other contact details.

What the role costs is worth being realistic about. Specialist providers offer it as a subscription service, typically for a few hundred euros a year at the low end, and law firms offer it at professional rates. The cheap end is genuine as far as it goes, but read what is included: some packages cover the designation and a forwarding address and stop there, leaving you to handle any correspondence that arrives. Since the representative must hold a copy of your record of processing activities and produce it to a supervisory authority on request, an arrangement where nobody maintains that record is a designation in name only.

The UK Runs A Parallel Requirement

Since Brexit there are two regimes and two representative obligations, and companies routinely satisfy one while forgetting the other.

UK GDPR carries its own Article 27. A controller or processor outside the UK, caught by the UK equivalent of Article 3(2), needs a UK representative on materially the same terms. A US company selling to both markets therefore needs an EU representative and a UK representative, and they cannot be the same entity unless that entity is established in both.

The vendors examined for this blog show the pattern clearly. Zapier's documentation states it has both EU and UK representatives, and Calendly's addendum records representatives designated in the EEA and the UK, both checked 7 August 2026. When two US SaaS companies of very different sizes have independently concluded they need both, that is a reasonable signal for a company in the same position. The mechanics of what Zapier does with the rest of its transfer paperwork are covered in our look at whether Zapier is GDPR compliant.

The UK obligation sits alongside a separate and frequently confused one: paying the ICO's data protection fee, which is a different requirement with different criteria and is covered in our guide to ICO registration. The two get conflated constantly, and they are unrelated: one is a designation obligation under UK GDPR, the other an annual payment under the Data Protection Act 2018. Satisfying either does nothing for the other.

There is a further wrinkle worth checking before you assume symmetry. The EU representative must sit in a Member State where your data subjects are, so if your EU users are concentrated in Germany and your provider is established in Ireland, that is a question to put to them rather than assume. Where you have users spread across many Member States, any one of them can work, but the choice is not arbitrary and should be recorded with a reason.

Common Mistakes With EU Representatives

Assuming a free product is outside scope. Article 3(2)(a) applies irrespective of whether payment is required. A free tier, an open beta and a no-charge trial all count, a point examined further in whether GDPR applies to trial users.

Reading the exemption as a small-business carve-out. It is not about company size. It is about whether processing is occasional and low risk, and continuous product processing is neither.

Treating the representative as a DPO, or vice versa. They are separate roles with separate legal bases. Appointing a DPO does not discharge Article 27, and appointing a representative does not discharge Article 37.

Appointing an EU representative and stopping there. UK GDPR carries a parallel requirement. Serving both markets generally means two appointments.

Burying the appointment. The representative exists to be contacted. If the name and address are not in your privacy information, the designation is not doing the job the article requires.

FAQ

Do we need an EU representative if we only have a handful of EU users?

Probably yes. There is no minimum user threshold in Article 3(2), and the Article 27(2) exemption turns on whether processing is occasional and low risk rather than on volume. Continuous processing of a small number of EU users still fails the occasional test.

Can our EU-based law firm act as our representative?

Yes, a representative can be a natural or legal person, and law firms and specialist providers both offer the service. Check they are established in a Member State where your data subjects are, and that the written mandate covers regulator and data subject correspondence.

Does appointing a representative reduce our liability?

No. The GDPR is explicit that designation is without prejudice to legal actions against the controller or processor. The representative is an additional point of contact and an additional enforcement target, not a substitute for your own responsibility.

What happens if we do not appoint one?

Failure to designate is an infringement in its own right and has been fined. More practically, it removes the buffer between you and a supervisory authority, and it signals to regulators and enterprise buyers that other basics may also be missing.

Closing Thought

Article 27 has been called the GDPR's hidden obligation, and the description is fair. It attracted a fraction of the attention the data protection officer requirement received, despite catching far more companies, because it applies to organisations who by definition are not in Europe and were not reading European compliance guidance.

The uncomfortable part is that the exemption most companies assume covers them was written for something else entirely. If you run a product that processes EU user data every day, you are not processing occasionally, whatever your headcount. ComplyDog hosts a compliance portal on your own domain covering your DPA, subprocessor list, data subject request handling and security page, which is where a representative's contact details and your processing record sensibly live. It does not act as your representative, which has to be a real entity in the EU.

This article covers the three tiers and how they are calculated, the exemptions and why "only" is the operative word, who is liable, what happens if you do not pay, and the questions the ICO's own guidance does not settle.

The Three Tiers And What Sets Them

Figures below are from the ICO's own guide to the data protection fee, checked 8 August 2026. Fee schedules change, so verify before you pay.

Tier 1, micro organisations, £52. You have a maximum turnover of £632,000 for your financial year or no more than 10 members of staff.

Tier 2, small and medium organisations, £78. You have a maximum turnover of £36 million or no more than 250 members of staff.

Tier 3, large organisations, £3,763. Everything that does not meet tier 1 or tier 2.

The conjunction matters more than anything else on this page. It is or, not and. Plenty of secondary guidance renders it as "and," which produces the wrong answer for exactly the profile a funded SaaS often has: eight employees and turnover above the threshold, or substantial headcount on modest revenue. Either limb alone puts you in the tier.

Staff numbers are defined broadly to include employees, workers, office holders and partners, counted as a monthly average across your financial year, with each part-time person counted as one. The ICO is explicit that it does not matter whether staff are based in the UK or overseas. A UK company with a distributed engineering team counts all of them.

Paying by direct debit takes £5 off at the point of payment. There are also fixed positions for some organisations: charities pay tier 1 regardless of size, as do small occupational pension schemes, and public authorities categorise on staff numbers alone.

One quiet default is worth knowing. The ICO states that it regards all controllers as eligible for tier 3 unless and until they tell it otherwise.

The Exemptions, And Why "Only" Does All The Work

You do not need to pay if you process personal data only for one or more of a listed set of purposes: staff administration; advertising, marketing and public relations; accounts and records; not-for-profit purposes; personal, family or household affairs; maintaining a public register; judicial functions; or processing without an automated system. Members of the House of Lords, elected representatives and prospective representatives have been exempt since 1 April 2019.

Read the list and then read the word before it. The exemption applies where those are the only purposes. A SaaS company processes customer data to deliver a product, which appears nowhere on that list, so the exemption fails at the first hurdle no matter how well the other purposes fit.

The exemption is genuinely useful to a narrow set of organisations: a holding company with no trading activity, a small consultancy keeping only its own accounts and staff records, a business that has genuinely never automated anything. It is not a startup exemption and there is no revenue floor.

One rule overrides all of this and is worth knowing because it catches organisations that would otherwise be exempt. The ICO states that any company using CCTV for crime prevention purposes must pay the fee regardless of any other aspect of its business, and that such organisations need not take the self-assessment at all because the answer will always be yes. An office with a camera on the door is enough. The same applies to a dashcam used for work purposes, which the ICO treats as non-domestic and therefore in scope.

Two further points that catch people. Being exempt from the fee does not exempt you from anything else in UK GDPR; your other obligations are untouched. And the register is public, which means anyone assessing you as a vendor can check whether you are on it in about fifteen seconds.

Who Is Actually Liable

The obligation falls on controllers. The ICO's guidance frames the requirement as applying where you are processing personal data as a controller.

For a B2B SaaS this produces a distinction worth being precise about. For your customers' end-user data you are typically a processor, and that role does not itself trigger the fee. For your own employee records, your marketing contacts, your billing data and your website analytics, you are a controller.

That might look like a route to an exemption, since staff administration, marketing and accounts are all on the exempt list. It usually is not, because a product business is a controller for more than that: prospect data you enriched rather than collected, support records, security logging, and anything you use to improve the product rather than to run the account. Establishing which hat you wear for which dataset is the same exercise as maintaining your record of processing activities, and doing one gives you the other.

What Happens If You Do Not Pay

The ICO publishes its position plainly. Failure to pay or renew can attract a monetary penalty of up to £4,000 on top of the fee owed, and its registration FAQ states that fines range from £400 to £4,000. It writes to organisations it believes should be registered, with a response deadline, whether or not a fee turns out to be due.

This is enforced rather than theoretical. The ICO reports issuing 126 monetary penalties for non-payment between May 2021 and January 2022, and it publishes the names of most organisations it fines. Note the economics too: the top of the penalty range is roughly seventy-seven times the tier 1 fee, for an obligation that costs less than a team lunch to discharge. This is not an area where non-compliance is a considered risk position.

Renewal is annual and it is your responsibility, though the ICO does send reminders. Reassess your tier at renewal, because the thresholds are the kind of thing a company crosses without noticing.

Payment is also not the same as compliance, and it is worth saying because the confusion is common. Registration funds the regulator and puts you on a public list. It does not certify anything, and it is a much weaker signal than a completed security audit or the evidence a buyer will actually ask for, in the same way that regulators' published wording matters more than vendor summaries when working out whether testing obligations apply to you.

Common Mistakes With ICO Registration

Reading the tier criteria as "and" rather than "or." Either turnover or staff count puts you in a tier on its own. This single misreading is the most common source of wrong payments.

Counting only UK staff. The ICO states that staff based overseas count too. A UK entity with a distributed team may be in a higher tier than headcount in the London office suggests.

Assuming the exemption list covers a SaaS. It applies only where the listed purposes are your sole purposes. Delivering a product to customers is not on the list, so the exemption fails immediately.

Confusing the fee with compliance. Registration is an administrative payment. It does not certify your practices and it does not answer a customer's security review.

Forgetting to reassess at renewal. Tiers are based on the last financial year. Crossing a threshold changes the fee, and the register does not update itself.

FAQ

Do I need to register with the ICO if I am a processor, not a controller?

The fee obligation is framed around processing as a controller. Most SaaS companies are controllers for something, though, including their own staff and marketing data, so the question is usually not whether you hold controller data but whether any exemption covers all of it.

Does a non-UK company have to pay the ICO fee?

This is the question the published guidance answers least clearly, and it depends on your connection to the UK rather than on where you are incorporated. Use the ICO's own registration self-assessment, and if the result is ambiguous for your structure, get it confirmed rather than inferred.

How much is the ICO fee for a startup?

£52 for tier 1, which covers organisations with turnover up to £632,000 or no more than 10 staff, less £5 if you pay by direct debit. Most early-stage companies sit here, moving to £78 as they grow.

Is the ICO register public?

Yes. Anyone can search it and download registration certificates, which means prospective customers and partners can check your entry without asking you. It is a small thing that occasionally comes up during vendor review.

Closing Thought

For a £52 annual payment this topic generates a remarkable amount of confusion, and most of it traces to one conjunction and one adverb. Turnover or staff, not both. Processing only for the listed purposes, not mostly.

There is a smaller point underneath that is worth sitting with. The register is public, the fee is trivial, and checking it takes seconds, which makes an absent registration a cheap and unusually reliable signal to anyone assessing you. It is one of the few compliance facts about your company that a stranger can verify without your cooperation. ComplyDog hosts a compliance portal on your own domain covering your DPA, subprocessor list, data subject request handling and security page, which is where the things buyers actually ask for belong. It does not pay your ICO fee, which takes about five minutes on the ICO's own site.

This article covers why the fine is the wrong thing to insure, what the position actually is jurisdiction by jurisdiction, what cyber policies genuinely pay for, the compensation exposure people forget, and when buying a policy is a commercial decision rather than a compliance one.

Nothing In The Regulation Requires It

There is no insurance obligation in the GDPR. Article 32 requires appropriate technical and organisational measures, and insurance is neither: it transfers financial consequences after the fact rather than reducing the likelihood or severity of an incident.

Where insurance does appear is in commercial paperwork. Enterprise buyers frequently ask for evidence of cyber liability cover during vendor review, and it turns up alongside the SOC 2 report and the pen test summary in the document pack that arrives with a security questionnaire. That is a contractual expectation, not a regulatory one, and it is worth being clear which you are responding to.

The Fine Is Probably Not Insurable

This is the part most marketing material glosses. Administrative fines under Article 83 must be effective, proportionate and dissuasive, and that word is the problem: a penalty designed to deter loses its deterrent effect if the wrongdoer can insure against paying it.

The picture across Europe, per a February 2026 survey of leading jurisdictions checked on 8 August 2026, is that administrative fines are generally viewed as punitive and therefore uninsurable, particularly where conduct was intentional or wilful. Treat this as a moving position: it is unsettled in several member states and untested in the courts in others. In Germany the question is assessed as a matter of public policy under section 138(1) of the Civil Code, and the dominant view in legal scholarship is that cover for fines is incompatible with public policy and therefore void, with insurers offering it risking regulatory attention. In Italy, fines from the Garante are generally regarded as uninsurable punitive sanctions. In Ireland the point has not reached the courts and the 2018 Act is silent, leaving the analysis to the ex turpi causa doctrine.

The UK is less settled than either extreme. Practitioners have argued the position is not clear cut for infringements that were negligent rather than intentional, and one line of argument holds that because the ICO weighs a range of factors rather than moral turpitude alone, some fines could be insurable. Separately, penalties for the two criminal offences the Data Protection Act 2018 created — intentionally or recklessly re-identifying individuals from anonymised data, and altering records to prevent disclosure in response to a subject access request — will not be insurable.

What follows practically: read your policy for the phrase "to the extent insurable by law." It appears in most wordings and it is doing significant work. It means the insurer pays where local law permits and not otherwise, and the question of whether local law permits is frequently unresolved.

What A Policy Genuinely Pays For

The uninsurability point applies to fines. It does not extend to the costs around them, and public policy concerns do not generally preclude cover for those.

A realistic cyber policy responds to forensic investigation, legal advice during a regulatory investigation, defence costs, notifying affected individuals, credit monitoring where offered, public relations support, business interruption, and extortion payments where lawful.

For a small SaaS, this is the meaningful exposure. A serious breach involving EU users produces a 72-hour notification clock under Article 33, an incident response engagement, external counsel, and possibly hundreds of thousands of individual notifications. Those costs land immediately and are not contingent on any regulator deciding anything. A fine, if it comes at all, arrives years later and only for a minority of incidents.

That reframing is the honest answer to the title question. Insurance is not GDPR protection. It is protection against the operational cost of an incident that GDPR obligations make more expensive to handle.

The Exposure People Forget

Article 82 gives any person who has suffered material or non-material damage as a result of an infringement the right to receive compensation from the controller or processor. That is civil liability, not a regulatory fine, and it does not raise the same public policy problem.

This matters more each year. Claims for non-material damage, including distress, have been brought across several member states, and the aggregate exposure from a large breach can exceed anything a supervisory authority would impose. Civil liability is ordinary insurable risk.

There is also a defensive point that is easy to miss. Article 34(3)(a) removes the obligation to notify affected individuals where you have applied appropriate protection, such as encryption rendering the data unintelligible. Not having to run a mass notification is a genuine cost avoidance, which is one reason the question of what Article 32 actually requires on encryption is worth settling before an incident rather than during one.

When Buying Cover Is The Right Call

Treat it as a commercial decision with a clear test: could an incident of realistic size threaten the company's survival, and does a customer contract require the cover?

For an early-stage SaaS with a handful of customers and no sensitive data, the honest answer is often no, and the premium is better spent on the controls that reduce the chance of the incident. Once you hold data for enterprise customers, process special category data, or have contracts specifying minimum cover, the calculation changes quickly.

If you do buy, three things are worth checking. Whether fines are covered "to the extent insurable by law" or excluded outright. Whether cover extends to regulatory investigation costs where no fine ultimately follows, since that is a common and expensive scenario. And whether your subprocessors' failures are covered, given that your liability to customers rarely stops at your own perimeter. Those answers sit alongside the rest of your control evidence, which a periodic compliance audit is the natural place to review.

Common Mistakes With Cyber Insurance And GDPR

Buying a policy expecting it to pay a GDPR fine. In most European jurisdictions it cannot, and the standard "to the extent insurable by law" wording means the insurer is not promising that it will.

Treating insurance as a compliance control. It transfers financial consequences; it does not reduce risk. Article 32 asks what measures you have implemented, and a policy is not one of them.

Overlooking Article 82 compensation claims. Civil claims by individuals do not raise the public policy problem that fines do, are insurable, and in a large breach can exceed the regulatory exposure.

Assuming cover extends through your supply chain. Your liability to customers usually includes your subprocessors' failures. Whether your policy follows that liability is a question to ask before signing.

Answering a buyer's insurance question with a regulatory one. Requests for evidence of cover come from contracts, not the GDPR. Saying the regulation does not require insurance does not answer what the customer asked.

FAQ

Does GDPR require cyber insurance?

No. Nothing in the regulation obliges an organisation to hold insurance, and Article 32 is concerned with technical and organisational measures rather than financial transfer. Requirements to hold cover come from customer contracts and procurement policies.

Will cyber insurance pay my GDPR fine?

Usually not. Administrative fines are widely treated as punitive and uninsurable on public policy grounds, with the position varying by member state and unsettled in several. Most policies cover fines only "to the extent insurable by law," which frequently means not at all.

What does cyber insurance actually cover for a data breach?

Typically forensic investigation, legal and regulatory defence costs, notification of affected individuals, credit monitoring, public relations, business interruption and some third-party liability. For most small companies these costs are the real financial exposure from an incident.

Do enterprise customers require cyber insurance from vendors?

Frequently, yes, often with a specified minimum limit written into the contract. It commonly appears in security questionnaires and vendor onboarding packs alongside requests for a SOC 2 report and a penetration test summary.

Closing Thought

The uncomfortable truth about cyber insurance and the GDPR is that the product is often sold against the risk it is least able to cover. Headline fines make the case for a policy, and the policy is least likely to pay them.

That is not an argument against buying cover. It is an argument for buying it for the right reason, which is that a breach generates immediate, large, unavoidable costs long before any regulator forms a view, and those costs are exactly what a policy is built for. ComplyDog hosts a compliance portal on your own domain covering your DPA, subprocessor list, data subject request handling and security page, which reduces the paperwork burden when a customer asks what you have in place. It does not reduce your premium, and no compliance tool should claim to.

This article covers where that line actually falls, why the employer paying for the account changes nothing, the separate marketing rules that cause most of the confusion, why your own staff's addresses are in scope too, and what it means for your systems.

The Test Is Identifiability, Not Ownership

Article 4(1) defines personal data as information relating to an identified or identifiable natural person. There is no carve-out for information created in a work context, none for information an employer pays for, and none for information a person shares in a professional capacity.

sam.smith@acme.com identifies Sam Smith. It probably also reveals where Sam works, and combined with a public staff directory it may reveal Sam's role and seniority. That it exists because Acme bought a mailbox is legally irrelevant. Acme is a legal person, and the GDPR is concerned with natural ones.

It is worth noting that the American vocabulary points the other way here. Classification guides written around personally identifiable information routinely file work email addresses as non-sensitive, which is a judgment about breach impact rather than about legal scope. Under the GDPR the two questions are separate: sensitivity affects your risk assessment, identifiability decides whether the regulation applies at all.

This is worth stating plainly because the opposite belief is widespread and often held confidently. A useful sanity check: if Sam left Acme tomorrow and asked what you held about them, "your work email address" is obviously part of the answer.

Where The Line Actually Falls

The distinction is between addresses that identify a person and addresses that identify only a function.

Clearly personal data: sam.smith@acme.com, s.smith@acme.com, sam@acme.com in a company of eleven people. Clearly not, in most circumstances: info@acme.com, support@acme.com, billing@acme.com, where the mailbox is a queue and no individual is identifiable from it.

The middle is where care is needed. sales@acme.com at a two-person company effectively names a person. An initials-based scheme identifies people just as well as a full name where the population is small enough. Recital 14 confirms the regulation does not cover the personal data of legal persons, but the shield only holds while the address genuinely refers to the organisation rather than a person within it.

Note also that generic today does not mean generic forever. An address that once fed a shared inbox and now routes to one named person has quietly changed category, and nothing in your systems will flag that.

Two Different Laws, Two Different Questions

Most of the confusion on this topic comes from a genuine rule that answers a different question.

In the UK, the PECR rules on direct marketing by electronic mail do not apply to corporate subscribers in the way they apply to individuals, so consent is not required in the same terms when marketing to a corporate body. That is a real distinction and it is why B2B marketing operates differently from B2C.

It is not a statement about personal data. The address is still personal data, the UK GDPR still applies to processing it, and you still need a lawful basis, a retention period and transparency. What changes is which consent rule applies under a separate piece of legislation, not whether the data is in scope.

The failure mode is a straight line from "we don't need consent for B2B email" to "so it isn't personal data," and everything downstream of that inference is wrong: the record of processing, the response to an access request, the deletion obligation. The marketing rules themselves are a separate topic with their own complexities and are not covered here.

Your Own Employees' Addresses Count Too

Teams that reason carefully about customer contacts often overlook their own staff.

Every employee address in your directory, your version control history, your ticketing system and your access logs is personal data about that person. Employment does not create an exception; it creates a processing relationship with its own transparency obligations, and staff have the same rights of access and rectification as anyone else.

This matters most at offboarding. A departing employee's address persists in commit messages, audit trails, shared documents and years of ticket history. Deleting the mailbox does not delete the personal data, and in many cases you have good reasons to retain some of it. What you need is a decided position rather than an accidental one.

What This Means For Your Systems

Three consequences follow, and none is exotic.

Access requests reach your CRM. If a business contact asks what you hold, the answer includes their work address and everything attached to it: notes, call logs, enrichment fields, lead scores, and any inferred data your tooling added. Enrichment is worth particular attention, because data you bought rather than collected triggers Article 14's separate information obligation.

Your Article 30 record needs a line for business contacts. It is a distinct category of data subject with its own purposes, lawful basis and retention.

And retention needs a decision. Most CRMs keep contacts indefinitely by default because that is the commercially convenient setting, not because anyone assessed it. A contact who has not responded in four years and never became a customer is difficult to justify holding on a legitimate interests basis. Vendor contracts already reflect this reality; Calendly's data processing addendum, checked 7 August 2026, lists invitee data including email addresses among the categories it processes, and the specifics of how that flows are set out in our look at whether Calendly is GDPR compliant.

The related question of whether an IP address in the same record is personal data has its own, more contested answer, which we cover in is an IP address personal data.

Common Mistakes With Work Email Addresses

Concluding that B2B means out of scope. The marketing consent rules differ for corporate subscribers. The definition of personal data does not, and conflating the two produces a compliance position that fails at the first access request.

Treating any address at a company domain as corporate. The domain is not the test. A named individual at a corporate domain is identifiable and therefore in scope.

Forgetting enrichment data has a separate obligation. Contacts sourced from a data vendor rather than collected directly fall under Article 14, which requires you to inform the person, generally within one month.

Excluding employees from data mapping. Staff addresses in ticketing systems, repositories and audit logs are personal data. Internal systems are routinely missed because the mapping exercise started with customer-facing products.

Assuming deleting the mailbox deletes the data. The address persists in commit history, ticket threads, shared documents and backups. Removing the account closes one copy and leaves the rest untouched.

FAQ

Is info@company.com personal data?

Generally no. A genuinely generic mailbox identifies a function rather than a person, and Recital 14 confirms the GDPR does not cover the data of legal persons. The exception is a small organisation where everyone knows the shared address reaches one particular individual.

Does GDPR apply to B2B contact data?

Yes, where the contact is an identifiable person. Business context does not remove data from scope. Separate marketing rules for corporate subscribers may change whether consent is required for a given message, but the underlying processing obligations still apply.

Can I keep a work email address after someone leaves the company?

Sometimes, but you need a reason and a limit. Retaining an address in historical records for contractual or audit purposes is often justifiable. Keeping it in an active marketing list once you know the person has moved on generally is not.

Do I need consent to store a work email address?

Usually not. Consent is one of six lawful bases and rarely the right one for business contacts. Legitimate interests commonly fits, provided you have carried out and documented the balancing test rather than assuming the outcome.

Closing Thought

The instinct behind this question is usually not really about definitions. It is a hope that business contact data sits in a lighter regime, because treating it the same as consumer data makes a pipeline built on scraped and enriched contacts look considerably less comfortable.

It does not sit in a lighter regime. The one genuine difference is a marketing consent rule in separate legislation, and it has been asked to carry far more weight than it can bear. If the practical problem is knowing what you hold and being able to show it, ComplyDog hosts a compliance portal on your own domain with self-serve data subject request handling, your subprocessor list and your security page. It does not clean up your CRM, which is the part that usually needs doing.

This article covers the case that decided it, the test the courts actually apply, why the static and dynamic distinction matters less than people expect, what the 2025 SRB judgment changed, and what all of it means for your logs.

The Case That Settled It

Patrick Breyer, a German politician, objected to federal government websites logging visitor IP addresses. The question referred to the Court of Justice was whether a dynamic IP address, held by a website operator who could not by itself link it to a person, was personal data.

In its judgment of 19 October 2016 in Case C-582/14, the Court said it could be. Reasoning from Recital 26 of the then-applicable directive, it observed at paragraph 43 that because the recital refers to means likely reasonably to be used by the controller "or by any other person," it is not required that all the information enabling identification be in the hands of one person.

The Court then set the qualifier that does the real work. It is personal data where the operator has legal channels enabling it to obtain the additional information from the internet service provider, in that case by contacting the competent authority after a cyberattack. That combination amounted to a means reasonably likely to be used.

The Test Is What You Could Reasonably Do

Recital 26 of the GDPR carries the same standard: account should be taken of all the means reasonably likely to be used to identify the person, judged against objective factors including cost, time required, available technology and technological developments.

Breyer supplied the negative limb. Identification is not reasonably likely where it is prohibited by law or practically impossible, requiring a disproportionate effort in time, cost and manpower, so that the risk of identification appears in reality to be insignificant. That threshold is high. "We have not tried" does not clear it, and neither does "we would need to ask someone."

This is why the honest answer is conditional rather than a flat yes, and why it is still a usable answer. You are not being asked whether identification is theoretically conceivable. You are being asked whether a route exists that you could realistically take. For a SaaS operator with an abuse process, a legal team and a relationship with a hosting provider, that route usually exists.

It is also why the question is better asked in the regulation's own vocabulary. The GDPR does not use the term PII, and the American frameworks that do tend to sort data into fixed categories rather than assess identifiability in context. If you need the wider taxonomy, our guide to personally identifiable information covers it; it classifies an IP address as context-dependent, which is correct as far as it goes and is precisely the point at which the legal analysis has to start rather than stop.

The same reasoning underpins the boundary between pseudonymised and genuinely anonymous data, which our article on anonymisation versus pseudonymisation works through in more detail.

Static Versus Dynamic Matters Less Than People Think

The received wisdom is that static IPs are personal data and dynamic ones are not. Breyer was specifically about a dynamic address, and it still found personal data.

The practical problem is worse than the legal one. A website operator receiving a request cannot generally tell at the moment of collection whether the address is static or dynamic, whether it belongs to a residential connection or a corporate NAT gateway shared by four hundred employees, or whether it is a VPN exit node. The Article 29 Working Party made this point early: operators will rarely be able to distinguish, and will therefore have to treat all IP addresses as personal data to be on the safe side.

That is not timidity. It is the only operable rule when the distinguishing fact is invisible to you at collection time.

What The SRB Judgment Changed In 2025

On 4 September 2025 the Court of Justice decided EDPS v SRB, Case C-413/23 P, setting aside a 2023 General Court judgment. It is the most significant development on the meaning of personal data since Breyer.

The Court explicitly confirmed the relative approach: "personal" is not an absolute property of data. The same pseudonymised dataset can be personal data for the organisation holding the key and non-personal for a recipient who cannot reverse it and has no other reasonable route to identification. It also held that personal opinions are inherently linked to their author and are therefore personal data, and that transparency obligations are assessed from the controller's perspective at the point of collection.

For IP addresses the direction is consistent with Breyer rather than contrary to it: the question is always whose hands the data is in. What SRB adds is that the answer can legitimately differ between you and a vendor you send data to. It does not mean you can send IP addresses to an analytics provider and declare the problem theirs. Your own assessment is unchanged, and your duty to tell people what you collect is expressly unaffected.

This is a live area. The EDPB's pseudonymisation guidelines were still moving through consultation during 2025, and commentators disagree about how far SRB reaches. Treat the relative approach as settled and the downstream consequences as contested.

What This Means For Your Logs And Analytics

If your servers log IP addresses, you are processing personal data and the ordinary obligations apply: a lawful basis, a retention period, a line in your Article 30 record, and disclosure in your privacy information.

That is usually manageable. Security logging has a strong legitimate interests case, provided you have actually done the balancing exercise and written it down. Retention is where teams get caught, because default log retention is often indefinite and nobody chose it.

Vendor contracts confirm the position rather than complicate it. Cloudflare's data processing addendum describes personal data in Customer Logs "such as IP addresses," and Sentry's schedule lists IP address among the categories of personal data it processes, both checked 7 August 2026. When two major infrastructure vendors write this into their own contracts, arguing that IP addresses are not personal data becomes a difficult position to hold.

The broader question of what else in a log file counts, and how to set retention for logging as a practice, belongs to our article on whether server logs count as personal data.

Common Mistakes With IP Addresses And Personal Data

Assuming the US concept of PII settles it. Frameworks that treat an IP address as merely "linked" information are answering a different question under a different law. The GDPR asks about identifiability, not about membership of a category list.

Treating dynamic addresses as automatically outside scope. Breyer concerned a dynamic address and found it could be personal data. The allocation method is not the test.

Truncating the last octet and calling the result anonymous. Partial masking reduces risk but rarely eliminates identifiability, particularly when the truncated address sits beside a session identifier, a user agent and a timestamp in the same row.

Logging indefinitely because storage is cheap. Retention has to be justified against purpose. An unbounded security log is not a security control, it is an unassessed risk with a lawful basis nobody wrote down.

Assuming a vendor's assessment covers yours. SRB confirms the analysis is relative to the holder. That your analytics provider concludes it cannot identify anyone says nothing about your own position.

FAQ

Is an IP address always personal data under GDPR?

Not automatically, but usually in practice. The test is whether means reasonably likely to be used exist to identify the person, judged from the position of whoever holds the address. For most website and SaaS operators such means do exist, which is why the working assumption should be that it is personal data.

Does the Breyer ruling still apply under GDPR?

Yes. It was decided under the earlier directive, but Recital 26 of the GDPR carries essentially the same identifiability standard, and later case law including the 2025 SRB judgment has built on Breyer's relative approach rather than departing from it.

Can I avoid GDPR by not storing IP addresses at all?

For that data point, yes, and it is a legitimate design choice. Many analytics configurations can discard or hash the address at collection. Be aware that your hosting provider, CDN and error tracker are probably still logging it independently of your application.

Are IP addresses personal data if we only use them for security?

Yes. Purpose does not change classification. Security is a strong basis for processing them under legitimate interests, but it does not take the data outside the regulation, and you still owe retention limits and transparency.

Closing Thought

The reason this question keeps being asked is that the answer is genuinely relative, and relative answers are unsatisfying to anyone hoping to tick a box. An IP address is not personal data in the way a passport number is. It is personal data because of what you, specifically, could do with it.

That is uncomfortable, because it means your own capability is part of the legal test, and capability grows. The team that could not identify a visitor in 2019 may have an abuse workflow, a support tool and a data warehouse that jointly can in 2026. If you want the processing that depends on this to be documented somewhere you can actually maintain, ComplyDog hosts a compliance portal on your own domain covering your DPA, subprocessor list, data subject request handling and security page. It will not make the classification question go away, because nothing does.

This article covers what each instrument actually is, the eight terms Article 28(3) demands, why the confidentiality overlap causes the confusion, what happens if you rely on the wrong one, and how the distinction shows up in real vendor paperwork.

What An NDA Is, And What It Is Not

An NDA is ordinary contract law. Two parties agree that certain information will not be disclosed, define what counts as confidential, set a duration, carve out exceptions for information already public or independently developed, and agree a remedy for breach.

Nothing about that is data protection law. An NDA is enforceable between the parties who signed it and creates no rights for anyone else. Crucially, the people whose personal data you are discussing are not parties to it, cannot enforce it, and gain nothing from its existence.

An NDA also protects information in the abstract: source code, pricing, roadmaps, customer lists, anything the definition captures. It does not care whether the information relates to an identifiable person, which is the only thing the GDPR cares about.

The Eight Terms Article 28(3) Requires

Article 28(3) is prescriptive in a way NDAs never are. The contract must set out the subject matter and duration of the processing, its nature and purpose, the types of personal data, the categories of data subjects, and the controller's obligations and rights.

It must then stipulate that the processor:

Processes personal data only on documented instructions from the controller, including as to third-country transfers. Ensures that people authorised to process the data have committed to confidentiality or are under a statutory duty of it. Takes all measures required by Article 32. Respects the conditions for engaging another processor. Assists the controller in responding to data subject requests. Assists with the obligations in Articles 32 to 36, covering security, breach notification and impact assessments. Deletes or returns the data at the end of the service, at the controller's choice. And makes available the information needed to demonstrate compliance, allowing for audits and inspections.

Note the second one. Confidentiality is a single sub-paragraph out of eight, and even there it is narrower than an NDA: it obliges the processor to bind its own authorised personnel, not merely to keep quiet itself.

Why The Overlap Causes The Confusion

Both documents contain a confidentiality clause, both get signed during vendor onboarding, and both arrive from the legal function. It is easy to conclude they are variants of the same thing.

They are not, because they answer different questions. The NDA asks: may you tell anyone? The DPA asks: on whose instructions are you acting, what may you do with the data, who else may touch it, what happens when the customer wants it back, and what happens when something goes wrong.

Confidentiality is one clause of eight in the DPA and the entire substance of the NDA. Reading across from one to the other therefore loses seven obligations, including every one that matters when a service ends or a breach occurs. This is also why a general services agreement with a confidentiality section does not qualify; Article 28 requires the terms, not merely a contract in which secrecy is mentioned.

What Actually Goes Wrong

Three failure modes recur, and none of them involve secrecy.

The first is deletion. An NDA says nothing about returning or erasing data when the relationship ends, so a vendor holding a copy of your customer records after termination is doing nothing wrong under the NDA. Article 28(3)(g) is the term that makes that a breach.

The second is subprocessing. An NDA typically permits disclosure to the recipient's own advisers and affiliates. Article 28 requires authorisation before another processor is engaged, and requires equivalent obligations to flow down. Without it you have no visibility of the chain and no route to object.

The third is instructions. Without documented instructions, a vendor is free to use your data for its own purposes and will often say so in its terms. The clause that prevents a support tool from training a model on your customers' tickets is Article 28(3)(a), not an NDA.

How This Looks In Real Vendor Paperwork

The instruments genuinely are separate in practice, and the vendor DPAs verified for this blog on 7 August 2026 show it clearly.

Typeform's data processing terms sit inside section 4 of its privacy policy, with the help centre confirming no separate signature is needed, which is a useful demonstration that a DPA is a set of obligations rather than a document type. If you are trying to work out where a given vendor's obligations actually live, the pattern across twelve vendors is set out in our look at whether Typeform is GDPR compliant and its neighbours.

Zapier's position is more pointed: its documentation states that it cannot sign DPAs issued by other companies, offering its own instead. Sentry's DPA is opt-in, entered into by the party that electronically accepts it, which means paying for the product does not put one in place. In each case the vendor's NDA, if any, is a separate matter entirely, and none of these arrangements would be discoverable from one.

If you are assembling this paperwork because a customer has sent you a review pack, the wider set of documents buyers ask for is worth understanding before you start, since the first vendor security questionnaire usually arrives with several of them attached. For the contents of the DPA itself, and what each clause is doing, our guide to what a DPA is covers it properly.

Common Mistakes With DPAs And NDAs

Accepting an NDA in place of a DPA. This is the core error. A vendor offering "we'll sign your NDA" when you asked for Article 28 terms has not answered the question, and the gap only becomes visible at termination or after an incident.

Assuming a mutual NDA covers personal data flowing both ways. Direction matters for data protection. Establish who is controller and who is processor for each flow; an NDA is silent on roles and roles determine the obligations.

Signing a DPA with no processing details filled in. Annexes left blank or completed with "as described in the agreement" fail Article 28(3)'s requirement to specify subject matter, duration, data types and categories of data subject.

Treating the DPA as the end of the vendor assessment. The contract records obligations; it does not verify that the vendor meets them. Subprocessor lists, transfer mechanisms and retention settings still need checking against the vendor's live pages.

Forgetting a DPA is needed with contractors as well as companies. A freelance developer with production access is a processor. The instrument is the same one a large vendor would sign, even if the commercial relationship is much smaller.

FAQ

Can an NDA ever satisfy GDPR requirements?

No. Article 28(3) lists eight specific obligations a processor contract must contain, of which confidentiality is one. An NDA covers that single element and none of the others, so it cannot discharge the requirement no matter how comprehensively it is drafted.

Do I need both a DPA and an NDA with the same vendor?

Usually yes. The DPA is mandatory wherever personal data is processed on your behalf. The NDA protects your commercial information, which the DPA does not touch. They cover different material and are often executed at different points in the sales cycle.

Who signs the DPA, us or the vendor?

Both, though increasingly neither signs anything. Many vendors incorporate their terms into the main agreement or make acceptance electronic, so the DPA takes effect without a signature step. Record which version applies and the date it took effect.

Does a DPA need to be a separate document?

No. Article 28 requires a contract or other legal act containing the specified terms; it does not require a standalone file. Terms incorporated into a master agreement or published online and referenced by it can satisfy the requirement perfectly well.

Closing Thought

The reason this confusion persists is that both documents feel like the same kind of obstacle: paperwork between you and a signed deal. Treated that way, whichever one arrives first gets filed and the other never gets chased.

They are not the same kind of obstacle. The NDA protects you from your vendor. The DPA protects your customers' data from both of you, and it is the one a regulator will ask to see. ComplyDog handles DPA signing through DocuSign and Dropbox Sign integrations and hosts your subprocessor list and security page on your own domain, which turns the recurring version of this request into a link. It does not draft your NDA, which remains a job for a lawyer who knows your commercial position.

This article covers what the regulation actually says, where the two-term convention came from, why it survives despite having no legal basis, which documents a B2B SaaS genuinely needs, and what regulators penalise when they look at one of these pages. It does not cover how to write the document itself.

Neither Term Appears In The Regulation

Search the GDPR for "privacy notice" and you will not find it. Search for "privacy policy" and you will not find that either. Articles 12, 13 and 14 talk about information to be provided to the data subject, and Article 12 sets the standard for how that information must be delivered: concise, transparent, intelligible, in clear and plain language, and easily accessible.

The UK regulator has settled on its own phrase. On its right to be informed guidance, checked 8 August 2026, the ICO states that Articles 13 and 14 specify what people have the right to be informed about as a minimum, and that it calls this "privacy information." That is a third term, and it is the only one with any official standing in either jurisdiction.

So the honest answer to the title question is that you are choosing a label for a document whose contents are prescribed and whose name is not. Nobody has ever been fined for the word at the top of the page.

What Articles 13 And 14 Actually Require

The two articles split on one axis: where the data came from.

Article 13 applies when you collect personal data directly from the person. Someone signs up for your trial, fills in a form, emails your support desk. Article 14 applies when you obtain it from somewhere else, including an enrichment vendor, a public source, or your customer's account when they upload their own contacts.

Article 14 is the one most SaaS companies overlook, and it carries a timing obligation Article 13 does not. Where data is obtained indirectly, the information must be provided within a reasonable period and at the latest within one month, or at the point of first communication with the person if that is sooner.

Both articles require the same broad categories: who you are, why you are processing, your lawful basis, who receives the data, whether it goes to a third country and on what safeguard, how long you keep it, and what rights the person has. Your Article 30 record of processing activities is the natural source for most of that, which is why teams who maintain records of processing activities properly find this document much easier to write and much easier to keep accurate.

Where The Two-Term Convention Came From

The convention is a practitioner one, and it is genuinely useful even though it is not law.

A notice is a notification. It tells people what you do with their data. It is not an agreement, nobody signs it, and nobody should be asked to accept it. Requiring a tick box that says "I agree to the privacy notice" is a small but revealing error, because it implies consent is your lawful basis when it usually is not.

A policy in the ordinary corporate sense is an internal governance document. It tells your own staff how to handle personal data: who can access what, how long things are retained, what to do when a request arrives, when to escalate a suspected breach. It is written for employees, not customers.

Under that convention, the page on your website is a notice and the document in your handbook is a policy. The problem is that "privacy policy" became the settled label on the open web long before the GDPR existed, browsers and app stores ask for a "privacy policy" link by name, and changing it now would confuse more people than it clarifies.

Which Documents Your SaaS Actually Needs

Three, and they are genuinely different artefacts.

The public notice, whatever you call it, covering your website visitors, trial users and customers. The internal policy, telling your team how to handle data. And usually a separate employee-facing notice, because your staff are data subjects too and Article 13 applies to their data exactly as it applies to a customer's.

Two adjacent documents are frequently confused with these and are neither. Your data processing agreement is a contract with a customer or a vendor, not a notice to individuals, and it is a different instrument again from the confidentiality agreement it often arrives beside, as DPA versus NDA sets out. Your cookie banner is a consent mechanism under the ePrivacy rules, not a substitute for the information obligation. If you tell a reader where your data is hosted and where it is transferred, that belongs in the notice under Article 13(1)(f), and the underlying question of what residency actually means is worth understanding separately before you write that line, because most claims about it are broader than the facts support.

What Regulators Penalise Is Detail, Not The Title

The enforcement record is consistent on this point. What gets criticised is vagueness.

The ICO's monetary penalty notice against TikTok, published 15 May 2023 in relation to a £12.7 million fine issued that April, set out its detailed position on Article 13 in an annex. The pattern in that document, and in the Irish decisions it aligns with, is that generic statements about recipients, transfers, lawful bases and retention are not enough. Recipients should be described by activity, sector and location. Naming "standard contractual clauses" without more does not adequately explain a transfer.

None of that turns on whether the page said notice or policy. It turns on whether a reader could work out what actually happens to their data. A page that says "we may share your data with trusted partners" fails at any title.

Common Mistakes With Privacy Notices And Policies

Treating the public notice as a contract. Asking people to tick a box agreeing to it muddles the legal picture and suggests consent is doing work it is not. Notices inform; they are not accepted.

Publishing one document and calling it done. The customer-facing notice does not cover your employees, and the internal policy is not written for the public. Most teams find they need three documents once they look properly.

Forgetting Article 14 exists. Any personal data you did not collect directly from the person triggers a separate obligation with its own one-month deadline. Enrichment tools and customer-uploaded contact lists both land here.

Describing recipients in categories so broad they mean nothing. "Service providers" tells a reader nothing. Regulators have said repeatedly that the description should let someone understand the type, sector and location of who receives their data.

Letting the notice drift from reality. The document describes your processing as it was on the day it was written. Add a subprocessor, change a retention period or open a new region and the notice is now inaccurate, which is a transparency failure in itself.

FAQ

Is a privacy notice legally required under GDPR?

The information is required, not the document. Articles 13 and 14 oblige you to provide a specified list of details to data subjects. A published notice is simply the most practical way to discharge that obligation for a website or product, which is why essentially every organisation has one.

Can I call my page a privacy policy instead of a privacy notice?

Yes. Neither term appears in the regulation and no regulator requires a particular label. "Privacy policy" is the more recognised phrase publicly and app stores ask for it by name. The wording inside the document matters; the heading does not.

Do I need a separate privacy notice for employees?

Almost always yes. Your staff are data subjects and Article 13 applies to their data as it does to customers'. Employment processing covers payroll, performance, monitoring and absence, none of which belongs in a customer-facing notice and most of which employees have a right to know about.

What is the difference between a privacy notice and a data processing agreement?

A notice informs individuals about your processing. A data processing agreement is a contract between two organisations that sets out Article 28 obligations when one processes personal data for the other. Different audiences, different legal function, and one cannot substitute for the other.

Closing Thought

The two-term debate has consumed a remarkable amount of professional energy for a distinction the law never made. It persists because it flatters a certain kind of expertise: knowing that your page is technically a notice is an easy way to sound precise without saying anything a reader benefits from.

The useful question is whether someone reading your page could work out what actually happens to their data, and most published notices fail that test regardless of their title. If you want the underlying processing to be documented well enough that the notice writes itself, that is really a records problem. ComplyDog hosts a compliance portal on your own domain covering your DPA, subprocessor list, data subject request handling and security page, which keeps the facts a notice depends on in one maintained place. It does not write your privacy notice, and no tool should claim to.

This article covers why the copy is a new purpose, what the compatibility test asks, the four options ranked by how well they survive scrutiny, why data subject rights reach staging, and the specific exposure created by non-production environments.

The Copy Is A New Purpose

You collected the data to run the service for the customer. Using it to test a release is a different purpose, and Article 5(1)(b) says personal data collected for specified purposes must not be further processed in a manner incompatible with those purposes.

Article 6(4) sets out how to assess compatibility where you are not relying on consent or a legal provision. You weigh the link between the original and new purposes, the context in which the data was collected and the relationship between you and the person, the nature of the data — with special category data weighed more heavily — the possible consequences for them, and the existence of appropriate safeguards including encryption or pseudonymisation.

Run that honestly for a full production clone into staging and the weak points appear immediately. The context in which a customer gave you their data does not obviously extend to it sitting in a developer environment. The consequences of exposure are identical to a production breach, because the data is identical. And the safeguards limb is where most teams have nothing to offer, because staging is deliberately easier to get into.

The Environment Name Is Not A Control

Article 32 requires security appropriate to the risk, and the risk attaches to the data, not the hostname. A database containing real customer records needs production-grade protection whether the environment is called production or not, and if you are not willing to apply those controls to staging, that is a finding about the copy rather than about staging.

The Four Options, Ranked

Synthetic data is generated, contains no real person, and sits entirely outside the regulation. It is the only option with no ongoing compliance cost. The objection is always that it does not reproduce real-world messiness — which is true, and is a smaller problem than teams assume for most test cases, and a genuine one for performance and edge-case work.

Anonymised extracts are also outside scope, but only if they clear a high bar: re-identification must no longer be reasonably possible by anyone, which means defeating singling out, linkability and inference rather than deleting the name column. Most "anonymised" test datasets are not. Our guide to anonymisation versus pseudonymisation sets out where the line actually falls, and it is further away than it looks.

Masked or pseudonymised subsets are the realistic middle. Replace direct identifiers, scramble free-text fields, subset to a fraction of records while preserving referential integrity. This remains personal data and remains fully in scope — but it materially reduces severity, it counts in your favour under Articles 25 and 32, and it is the option that most often survives an Article 6(4) assessment.

A full production copy is the option to justify explicitly or not take. Sometimes it is genuinely necessary — reproducing a data-dependent bug, validating a complex migration. When it is, treat it as a temporary production system: same access controls, same encryption, same monitoring, a named owner, and a hard expiry date measured in days.

The ranking matters more than the labels. The question to answer in writing is not "may we use production data" but "what is the least identifiable dataset that would actually answer our engineering question."

Rights And Retention Reach Staging

Non-production copies are the most common blind spot in rights handling, and the reason is simple: the process was designed around the production database.

An erasure request covers every copy you hold, including the staging snapshot taken three weeks ago. An access request requires you to search where the personal data is, which includes non-production systems. If your DSAR runbook queries production and nothing else, your responses have been incomplete — and the same gap applies to the other places copies accumulate, which is why this and the problem of backup copies tend to be discovered in the same week.

Retention, Previews And Contractors

Test datasets are created for a specific piece of work and then never removed, because deleting them is nobody's ticket. Storage limitation applies, so every test copy needs an expiry, and the expiry needs to be enforced by something other than good intentions. Refreshing staging from production monthly and never deleting the old copies produces an accumulating archive of customer data that appears on no data map.

Two related exposures worth naming. Preview and ephemeral environments spin up per branch and can quietly hold real data, sometimes on infrastructure tiers whose terms differ from your main plan — our piece on Vercel covers a case where the processing addendum applies only to certain plans, which is worth checking before a preview deployment touches customer records. And contractors or offshore development teams given a production dump for convenience are receiving a transfer, a disclosure, and possibly a subprocessor relationship nobody documented.

Common Mistakes With Test Data Under GDPR

Cloning production to staging as the default. It is further processing for a new purpose and needs an Article 6(4) assessment. Doing it because it is the easiest way to get realistic data is not an assessment.

Calling masked data anonymous. Masking reduces risk; it rarely achieves anonymisation. Describing a masked dataset as anonymous in a DPA or questionnaire is a statement about legal scope that a customer's counsel can check.

Excluding non-production from rights handling. Erasure and access requests reach every copy. A runbook that only queries production produces incomplete responses without anyone noticing.

Test datasets with no expiry. Copies created for one piece of work outlive it by years. Set an expiry at creation and enforce it automatically.

Weaker controls justified by the environment name. Article 32 asks about risk to the data. If the records are real, the environment being called staging changes nothing about what protection is appropriate.

FAQ

Can we copy production data into staging under GDPR?

Not without justifying it. It is further processing for a new purpose, so you need a compatibility assessment under Article 6(4) and security appropriate to the data under Article 32. In practice that means minimising what you copy, masking what you can, restricting access as you would in production, and setting an expiry — or using synthetic data instead.

Is masked production data still personal data?

Almost always yes. Masking direct identifiers leaves quasi-identifiers and structure that can single people out, so the data stays in scope with retention limits and rights attached. It is still worth doing — it reduces breach severity and strengthens your Article 6(4) position — but it is risk reduction, not an exit.

Do erasure requests apply to test environments?

Yes. The right covers the personal data you hold, wherever you hold it. If a staging snapshot contains the person's records, it is in scope. The practical answer is usually to keep test copies short-lived enough that the question resolves itself, rather than building erasure tooling for every environment.

What is the safest option for realistic test data?

Synthetic data, because it takes you out of scope entirely. Where it genuinely cannot reproduce the behaviour you need, a masked and subsetted extract with a short expiry and production-grade access controls is the realistic second choice. A full unmasked clone should be a documented exception with a named owner, not a standing arrangement.

Closing Thought

Almost every team that copies production into staging knows it is not ideal. It persists because the alternative costs engineering time now, and the risk lands later and on someone else — which is the same structure as most technical debt, with the difference that this particular debt is other people's personal data.

The useful reframing is that the question is never "is this allowed." It is "how much of this data do we actually need to answer our engineering question," and the honest answer is usually a small, masked subset that nobody had the time to build. That subset takes a week once. The full clone costs a little every month, quietly, until it doesn't.

ComplyDog keeps the records that make this visible: records of processing activities that should name every environment holding personal data, subprocessor tracking for the contractors and platforms that touch it, and a portal on your own domain for the requests that reach into all of it. You can try it free for 14 days, no credit card required.

This article covers what logs actually contain, the lawful basis for keeping them, how long to keep which kind, why logs are usually the least-governed personal data in a company, and what happens when a subject access or erasure request reaches them.

What Is Actually In Your Logs

You do not need to resolve any hard legal question to answer this. Read a day of production logs.

The predictable contents are IP addresses, user or account identifiers, timestamps, user-agent strings, request paths and referrers. Those alone identify people, and vendors say so plainly in their own contracts: Cloudflare's data processing addendum names personal data in customer logs "such as IP addresses" among the categories it processes, which we covered in our piece on Cloudflare's DPA. When a major infrastructure provider writes it into its Annex, the question is settled for practical purposes.

The unpredictable contents are the problem. Stack traces embed the variables that were in scope when something failed, which routinely means email addresses, names and identifiers. Verbose request logging captures full bodies, including whatever a user typed. Integration debugging captures third-party payloads. And special category data arrives here the way it arrives everywhere — nobody decided to collect it, someone just typed a health detail into a support field and the field got logged.

Two related points. First, logs are usually written by many services with no shared policy, so what ends up in them is an emergent property rather than a decision. Second, the volume makes them opaque: nobody reads all of it, so nobody knows what is in there. "We do not log personal data" is a claim almost no team can support, and it is worth checking before anyone writes it into a questionnaire response.

The Lawful Basis For Logging

Logging needs a basis like any other processing, and for most of it the answer is legitimate interests under Article 6(1)(f): keeping a service running, investigating faults, detecting abuse, and maintaining security.

That is a strong interest and the balancing test usually goes your way, because people reasonably expect a service to record technical events. What weakens it is scope. Logging what is necessary to operate and secure the service is proportionate. Logging everything by default because it might be useful later is the pattern that fails, and it fails on data minimisation under Article 5(1)(c) before it fails on the balancing test.

Some logging sits on a different footing. Audit logs you are required to keep by law rest on legal obligation. Logs that exist to deliver the product feature the customer bought — an activity feed, an audit trail you sell — sit under contract. It is worth knowing which of your log types sit where, because the basis determines the retention argument and, incidentally, whether portability applies.

Where you are a processor rather than a controller, the position shifts again: logs you generate about your customers' end users are processed on your customer's instructions, and your DPA should cover them. Many do not mention logs at all.

Retention: Set It Per Log Type

There is no prescribed period. Article 5(1)(e) requires you to keep personal data no longer than necessary, and "necessary" varies sharply across log types, which is why one global setting is usually wrong in both directions.

Debug and verbose application logs have a short useful life — days, sometimes hours. They are also the logs most likely to contain unexpected personal data, so keeping them long is the worst combination of high risk and low value.

Access and security logs justify longer. Incident investigation frequently needs to look back weeks or months, and an intrusion discovered in March may need logs from January. Months rather than days is defensible here, and you should be able to say why you picked the number. For a concrete anchor, the CNIL's published guidance on setting retention periods gives log data six months as an indicative figure — not a binding rule, and not applicable outside France, but a useful sanity check if your logging platform is currently keeping everything for two years because nobody changed the default.

Audit logs tied to a legal or contractual obligation last as long as the obligation, and no longer once it lapses.

The practical failure is a single retention setting inherited from whatever the logging platform defaulted to, applied to everything. Splitting retention by log type costs one configuration exercise and materially reduces how much personal data you are holding at any moment.

Governance: Records, Access, And Rights

Three obligations reach logs and are routinely missed.

Article 30 records. Logging is a processing activity and belongs in your records of processing, with its purpose, the categories of data involved, the retention period and any processors. It is one of the most commonly absent entries, because whoever compiled the record listed the customer-facing systems and stopped.

Access control. Production log access is frequently granted broadly — to everyone on call, to the whole engineering team, sometimes to anyone with a dashboard login. That makes logs the least-restricted store of personal data in many companies, and it is the gap most likely to be found in a security review rather than by a regulator. Restrict, and log the access to the logs.

Third-party log processors. If logs leave your infrastructure for a hosted platform, that provider processes personal data on your behalf. It needs an Article 28 contract, it belongs on your subprocessor list, and it should go through your normal subprocessor notification process. Log platforms are among the most commonly omitted entries.

When A Request Reaches Your Logs

Logs fall within the scope of an access request under Article 15, so you need to be able to find one person's log lines — which is easy if you index by user ID and hard if you do not. Erasure is harder still, because log stores are frequently append-only, and the practical answer mirrors backups: reduce the retention window, suppress on any restore, and be honest about the timeline. Our piece on deleting personal data from backups sets out that approach.

The cheapest structural fix is upstream. Logging a stable pseudonymous identifier rather than an email address reduces exposure, makes per-user search feasible, and shortens redaction work — while leaving the data firmly in scope, as our guide to anonymisation versus pseudonymisation explains.

Common Mistakes With Logging Under GDPR

Leaving logging out of the records of processing. It is a processing activity with a purpose, categories of data, a retention period and processors. Its absence is the tell that nobody assessed it.

One retention period for every log type. Debug logs and security audit logs have completely different justifications. A single inherited default keeps the risky ones far too long.

Logging full request bodies by default. Verbose capture pulls in credentials, tokens and whatever users typed. Scrub at the point of writing, not by deleting later.

Broad production log access. If most of engineering can read raw logs, you have a large, unrestricted personal data store with no meaningful access control.

Forgetting the log platform is a subprocessor. A hosted logging service receives your users' personal data. It needs a DPA and a place on the subprocessor list.

FAQ

Do server logs count as personal data?

In almost all cases, yes. Logs routinely contain IP addresses, user identifiers and personal data captured incidentally in error messages and request payloads — and vendors say as much in their own processing agreements. Rather than reasoning about it abstractly, read a day of your own logs and see what is in them.

How long can we keep logs under GDPR?

There is no set period, and one period for all logs is the wrong answer. Verbose and debug logs have a short useful life and the highest chance of containing unexpected personal data. Security and access logs justify months because investigations look backwards. Set each type separately and record the reasoning.

Do logs need to be in our records of processing?

Yes. Article 30 requires records of your processing activities, and logging is one — with its own purpose, data categories, retention period and processors. It is among the most commonly omitted entries, usually because the person compiling the record listed only customer-facing systems.

Do we have to include logs in a subject access request?

Yes, where they contain the person's personal data. The practical question is whether you can retrieve one individual's entries, which depends on whether you log a searchable identifier. Teams that log a stable user ID can answer in minutes; teams that rely on free-text matching often cannot answer at all.

Closing Thought

Logs occupy a strange position. They are written by engineers for engineers, retained by default, rarely reviewed, and almost never appear on the data map — yet they frequently hold more personal data, about more people, than the database everyone worries about.

The reason is structural rather than careless: logging is the one system where the data is a by-product rather than the point. Nobody chose to collect it, so nobody owns it, so nobody governs it. Which makes "who is responsible for what we log" a more useful question than any of the legal ones in this article.

ComplyDog keeps the records this depends on — records of processing activities where logging belongs as a named activity with its retention period, subprocessor tracking that should include your logging platform, and a portal on your own domain for handling the requests that reach into these systems. You can try it free for 14 days, no credit card required.

This article covers what "beyond use" actually requires, why your retention window is the real control, the restore problem that quietly undoes erasure, what to say to the person who asked, and when you can decline entirely.

Why This Is Hard, And What Regulators Accept

Article 17 gives people the right to erasure in defined circumstances, and it says nothing about backups. Neither do the recitals. That silence is the whole problem, because backups are built to be immutable and are frequently stored as opaque images that cannot be searched for a single record without a full restore.

The ICO's guidance on the right to erasure sets out the accepted position. Where an erasure request can be fulfilled immediately in live systems but the data will remain in the backup environment until it is overwritten, the key issue is to put the backup data beyond use, even if it cannot be immediately overwritten. Concretely, that means you must ensure you do not use the data within the backup for any other purpose — the backup is simply held on your systems until it is replaced in line with an established schedule.

The ICO also expects you to be absolutely clear with the individual about what will happen to their data, including in respect of backup systems.

The CNIL frames the same problem as a choice, and its wording is worth having in front of you: provide for erasure in backups, or provide an alternative solution that does not restore erased data relating to that person. That second limb is the suppression list described below — a regulator naming it as an acceptable substitute for deleting from the backup itself, and the part most teams skip.

Note what that bargain requires of you. "Beyond use" is not a label you apply. It is a set of commitments: no operational use of that backup, an established schedule that will overwrite it, and honest disclosure. An organisation with no retention schedule has nothing to point at, and the concession does not apply.

Your Retention Window Is The Real Control

If overwriting is how the data eventually goes, then how long you keep backups is how long erased data survives. A thirty-day cycle means a month. A seven-year archive means seven years, and an "erasure" that leaves the record intact for seven years is one you should be uncomfortable describing as erasure.

Article 5(1)(e) applies to backups like everything else — personal data kept no longer than necessary. The necessity here is recovery, and recovery necessity has a shape: you need enough history to restore from a recent failure and to catch corruption that went unnoticed for a while. It does not usually justify keeping every daily snapshot indefinitely.

So the useful exercise is to write down, per backup tier, what it is for and how far back that purpose reaches. Daily snapshots for operational recovery. A shorter set of weeklies. Anything longer needs a stated reason — a legal retention obligation, a contractual commitment — rather than inertia.

Article 32(1)(c) pulls the other way and should be respected: you must be able to restore availability and access to personal data in a timely manner after an incident. Nobody is asking you to stop taking backups, and a policy that deletes backups so aggressively that you cannot recover from ransomware has traded one compliance failure for a worse one.

Worth knowing what your own vendors do here, since their windows become yours. Our piece on Supabase records one published example of a post-termination retention period and a default backup cadence, which is the sort of clause that decides how long your data outlives your account.

The Restore Problem

This is the failure that turns a compliant process into a false statement, and it is almost never designed for.

You delete someone from production. Six weeks later a database incident forces a restore from a backup taken before the deletion. The restore succeeds, the incident closes, and the person you erased is now back in your live systems — searchable, emailable, and included in the next export. Nobody notices, because a successful restore looks like a success.

The fix is a suppression list: a durable record of erased identifiers, held outside the data being restored, that any restore procedure checks and re-applies before the system returns to service. It has to survive the restore itself, which means it cannot live only in the database being replaced.

Two details. The suppression record should be minimal — the point is data minimisation, so a hashed identifier and a date is better than a copy of everything you deleted. And re-deletion needs to be a documented step in the runbook, not something an engineer remembers at 3am. A restore procedure that does not mention erasure suppression will not perform it.

The same logic reaches every other copy of the data you keep, which is more places than people expect. Application logs hold the same records and need the same treatment, and non-production copies are the other common blind spot — dealt with in our guide to using production data in test environments.

What To Tell The Requester, And When You Can Say No

Transparency is doing real work in this arrangement, and vagueness costs you the concession.

A good response confirms deletion from live systems, states plainly that copies remain in backups, gives the date or period by which those backups will be overwritten, confirms the data will not be used for any purpose in the meantime, and confirms that a restore will not reintroduce the record. That is five sentences and it is defensible. "Your data has been deleted," when it has not been deleted from three backup generations, is a misstatement you have put in writing.

When You Can Decline

The right is not absolute. Article 17(3) sets out exemptions, and the ones that come up in practice are compliance with a legal obligation requiring retention, and the establishment, exercise or defence of legal claims. If a legal hold applies, say so and explain the basis rather than quietly keeping the data. Where the request is refused in whole or part, Article 12(4) requires you to tell the person why and inform them of their right to complain to a supervisory authority.

One boundary worth naming: this article is about backups. Setting retention periods across your live systems, classifying data and automating cleanup is a wider programme, and our SaaS data retention guide covers that.

Common Mistakes With Backups And Erasure

Telling someone their data is deleted when it is in three backup generations. The concession regulators offer depends on disclosure. Claiming complete deletion forfeits it and creates a written inaccuracy.

Having no suppression list. Without one, the next restore silently resurrects everyone you erased, and nothing in the process will flag it.

Backup retention that nobody chose. If snapshots accumulate until storage costs prompt a cleanup, your erasure timeline is set by your finance team. Set the window deliberately and document why.

Trying to surgically edit backups. Restoring, deleting a row and re-imaging risks integrity, risks other people's data, and is not what is being asked of you.

Forgetting the other copies. Logs, analytics warehouses, staging databases and exported reports all hold the same records, and an erasure process scoped to the production database misses most of them.

FAQ

Do we have to delete personal data from backups?

Eventually, yes, but not immediately and not surgically. Delete from live systems straight away, put the backup copies beyond use so they are not used for any other purpose, and let your established retention schedule overwrite them. Regulators accept that approach provided you have a real schedule and you tell the person what is happening.

How long can we keep backups under GDPR?

There is no fixed period. Article 5(1)(e) requires you to keep personal data no longer than necessary, and for backups the necessity is recovery. Set a window per backup tier that reflects how far back you would realistically restore from, document the reasoning, and treat anything longer as needing its own justification.

What exactly should we tell someone who asks for erasure?

That live systems are done, that backup copies remain, when those will be overwritten, that nothing will be used from them in the meantime, and that a restore will not bring the record back. Being specific about the date is what turns a vague reassurance into a defensible position.

What if we restore a backup after deleting someone?

Then the record returns unless you prevent it, which is why the suppression list matters. Keep erased identifiers outside the restored dataset and make re-deletion an explicit step in the restore runbook. A restore that silently reintroduces erased people undoes every request you have processed.

Closing Thought

The interesting thing about backups is that they are the one place where good engineering and data protection pull genuinely in opposite directions. Everywhere else the advice converges — minimise, encrypt, restrict access, and both disciplines nod along. Here, the property that makes a backup trustworthy is precisely the property that makes erasure hard, and no amount of policy writing dissolves that.

Which is why the honest answer is a process rather than a technical fix, and why the part that most often fails is not the deletion. It is the sentence you send afterwards.

ComplyDog handles the request side: a self-serve intake form for erasure and other data subject requests on a portal hosted on your own domain, with records of processing that document your retention periods — including the backup ones you will need to quote when somebody asks. You can try it free for 14 days, no credit card required.

This article covers why residency and transfers get confused, what actually replaces a residency rule, where genuine localisation requirements do come from, why "EU data residency" from a vendor is almost never total, and why choosing an EU region does not close the question.

Residency And Transfers Are Different Questions

The confusion comes from Chapter V, which restricts transferring personal data outside the EEA unless certain conditions are met. Teams read "restricted" as "prohibited" and conclude that the safe answer is to keep everything in Europe.

But Chapter V is a permission regime, not a prohibition. It says a transfer is lawful where there is an adequacy decision, or appropriate safeguards, or in narrow cases a derogation. Meeting one of those makes the transfer lawful. Nothing anywhere in the regulation says personal data must be stored in the EEA, and nothing conditions your compliance on the physical location of a disk.

The distinction has a practical consequence that runs the opposite way to most people's instinct: a company with everything in an EU data centre can still be badly non-compliant, and a company running on US infrastructure with a proper transfer mechanism, documented assessment and honest disclosure can be fine. Location is evidence about risk. It is not the rule.

The mechanisms themselves — adequacy decisions, the current Standard Contractual Clauses, Binding Corporate Rules, transfer impact assessments — are a substantial subject and our cross-border data transfer guide covers them. This article deliberately stays on the residency myth and hands the transfer machinery to that page.

One point of currency, because it moves: for transfers to the United States, the EU-US Data Privacy Framework adopted in July 2023 provides an adequacy route for organisations that certify to it, sitting alongside the Standard Contractual Clauses that most vendors keep in reserve. Any analysis that stops at the invalidation of Privacy Shield is several years out of date.

Where Real Localisation Requirements Come From

Genuine obligations to keep data in a particular place do exist. They just are not in GDPR.

Member state law can impose them for specific categories, most often health records, and public sector procurement frequently carries location conditions. Sector regulation does the same in parts of financial services and for classified or government-adjacent work. Other countries' laws impose localisation more often than the EU does, which is why a global product ends up with regional infrastructure for reasons that have nothing to do with GDPR.

And then there is the one that actually drives most SaaS roadmaps: customer contracts. An enterprise buyer's DPA says data will be stored and processed in the EEA. That is a commercial commitment, freely entered into, and breaching it is a contract problem rather than a regulatory one — but it is a real problem, and it is enforceable by a counterparty with a strong motive to enforce it.

This is worth being precise about internally, because the two get muddled in the same sentence. "We have to be in the EU for GDPR" is usually false. "We have to be in the EU because we signed something saying we would" is usually true, and it changes who you need to talk to.

"EU Data Residency" Is Almost Never Total

If you do buy regional hosting, the single most important thing to establish is what it excludes — because in every vendor arrangement worth reading, it excludes something.

The recurring pattern across vendors is that content sits in region while the surrounding layer does not. Account and authentication data, billing records, support tickets, telemetry and various categories of metadata frequently stay wherever the vendor's primary systems are. Our piece on Airtable's data residency sets out one published example in detail, including categories of descriptive metadata that never move region at all — and a descriptive base name can be revealing on its own.

Residency is also often a product rather than a default. Our piece on Cloudflare covers a localisation offering that is three separate controls you configure, not a single switch that keeps everything in Europe. Buying "the EU option" and assuming it is comprehensive is how teams end up making residency claims in questionnaires that their own vendor's documentation contradicts.

There is a further trap. Migration is frequently not retroactive: enabling a regional setting governs new data, while everything created beforehand stays where it was until somebody arranges a migration. If you switched last quarter, you may still be storing years of data in the region you thought you had left.

Access Is A Transfer, Even When Storage Is Not

Here is the point that undoes a residency-only strategy.

A transfer does not require data to be copied to another country. Making personal data available to someone in a third country counts. A support engineer in Austin opening a session against your Frankfurt database is a transfer. So is a developer on a US laptop querying production, an offshore contractor with a dashboard login, and a third-country parent company with administrative access to a European subsidiary's systems.

So residency alone does not remove your need for a transfer mechanism. It changes where the data rests, not who reaches it. A company that moved its infrastructure to the EU and left global support and engineering access unchanged has usually solved the easier half of the problem and told its customers it solved both.

The Questions Worth Asking Instead

Who can access production, from where? Does your vendor's support organisation operate from a third country? Do your backups replicate across regions? Is your monitoring or error-tracking pipeline sending data somewhere else entirely? Each of those is a transfer to document, whether or not your primary storage is European.

Common Mistakes With EU Data Residency

Believing GDPR mandates EU storage. It does not, and organising your architecture around a rule that does not exist costs money and solves nothing that a transfer mechanism would not have solved.

Assuming a vendor's residency option covers everything. Metadata, account data, support data and backups routinely sit outside the region. Never repeat a residency claim without stating what it excludes.

Forgetting that access from a third country is a transfer. Storage in Frankfurt with support in Texas is still an international transfer, and it still needs a mechanism.

Confusing a contractual promise with a legal requirement. If a customer DPA commits you to EEA storage, that is binding on you regardless of what GDPR says — and it is breached the moment a new subprocessor lands elsewhere.

Assuming a region switch is retroactive. Enabling residency usually governs new data only. Existing data stays put until someone actively migrates it.

FAQ

Does GDPR require personal data to be stored in the EU?

No. There is no residency or localisation requirement anywhere in the regulation. Chapter V sets conditions for transferring personal data outside the EEA — adequacy, appropriate safeguards such as the Standard Contractual Clauses, or a narrow derogation — and satisfying one of those makes the transfer lawful wherever the servers are.

Does choosing an EU region make us compliant?

No. It can reduce transfers, which reduces one category of risk, but it does not address lawful basis, retention, security, transparency or data subject rights. It also does not eliminate transfers if people outside the EEA can access the data, and it usually leaves several data categories outside the region regardless.

Is remote access from outside the EU a transfer?

Yes. Making personal data available to someone in a third country is a transfer even if nothing is copied or permanently stored there. Support access, engineering access to production and administrative access from a parent company all count, and all need a mechanism and a record.

Why do customers keep asking for EU data residency then?

Because it is a simple proxy for a complicated risk assessment, because their own procurement policy or DPA requires it, and sometimes because their regulator or sector rules do. It is a legitimate commercial requirement. It is just not a GDPR one, and answering it honestly is more useful than agreeing to something you cannot fully deliver.

Closing Thought

Data residency is popular because it is legible. "Our data is in Europe" fits on a slide, survives a procurement review, and feels like an answer. A transfer impact assessment does not fit on a slide.

The awkward part is that legibility is exactly what makes it a poor proxy. It reassures the buyer about the one question they know how to ask, while leaving the harder ones — who can reach the data, under what contract, with what oversight — entirely untouched. Vendors who answer the residency question well and the access question vaguely are usually not hiding anything. They just were not asked.

ComplyDog helps with the part buyers actually need to see: a subprocessor list that stays current as your stack and your regions change, DPA management, and a compliance portal on your own domain where prospects can read your position before they send the questionnaire. You can try it free for 14 days, no credit card required.

This article covers the lawful basis and how the balancing test applies to premises security, why a "CCTV in operation" sign is not notice, where cameras may and may not point, how long footage can be kept, and what happens when someone asks for a copy of themselves.

The Lawful Basis, And Why It Is Not Consent

Cameras that capture recognisable faces process personal data. There is no threshold below which a small office is exempt.

Consent fails here for the same reason it fails across the employment relationship: it must be freely given, and a person who has to walk past a camera to reach their desk or your reception cannot meaningfully decline. A visitor cannot either. The EDPB's position is the same — for video surveillance the likely bases are legitimate interests or a public-interest task, with consent workable only in rather exceptional cases. So the basis is almost always legitimate interests under Article 6(1)(f), and that carries the three-part test.

The legitimate interest is usually easy: securing premises, protecting property, safeguarding staff, investigating incidents. Necessity is harder and is where installations fail — the question is not whether cameras help, but whether a less intrusive measure would achieve the same end. Better locks, an alarm, a visitor log and controlled door access all address the same risk with far less processing. If they would work, blanket coverage is not necessary.

The balancing limb turns on what people reasonably expect. A camera on an external door and a stockroom is expected. A camera on the desks where people work all day is a different proposition, and one that starts to look like monitoring performance rather than securing a building. That distinction matters: watching people work is a separate subject with its own rules, covered in our guide to employee surveillance under GDPR. This article is about cameras on premises.

Write the assessment down. A legitimate interests assessment that exists only in someone's head is indistinguishable, after an incident, from never having done one.

Signage Is Not Notice

"CCTV in operation" is a sign. It is not compliance with Articles 13 and 14, which require you to tell people who the controller is, why you are processing, on what basis, how long you keep the footage, who else sees it, and what rights they have.

The EDPB's Guidelines 3/2019 on processing of personal data through video devices — adopted in final form on 29 January 2020 and still the reference document on this subject — set out the workable pattern, and it is layered. The most important information goes on the warning sign itself, which is the first layer; the remaining mandatory detail is provided by other means and made available somewhere easily accessible, which is the second. The guidelines add that the sign should also carry anything that would surprise the person — onward transmission to a third party being the usual example.

In practice that means a sign visible before someone enters the covered area, naming the controller, stating the purpose in a few words, and pointing to where the full information lives. The second layer carries everything Article 13 requires.

Two details that get missed. Staff need the information too, and burying it in a handbook nobody has read since onboarding is weak. And if you install cameras in an area already in use, people should be told before the cameras go live, not discover them afterwards.

A DPIA is likely. Article 35(3)(c) makes one mandatory for systematic monitoring of a publicly accessible area on a large scale, which a small office reception may not meet — but the WP29 criteria push the same way regardless, because systematic monitoring and employees as vulnerable data subjects are two high-risk indicators, and two generally point to a DPIA.

Where Cameras May And May Not Point

Placement is where proportionality becomes concrete.

Areas where people have a heightened expectation of privacy are effectively off-limits: toilets, changing areas, prayer or wellbeing rooms, and medical rooms. Break rooms and kitchens are difficult to justify because the purpose is almost never security. Cameras trained on individual workstations are hard to defend as premises security and easy to characterise as performance monitoring.

Overshoot is the other common failure. A camera covering your entrance frequently also covers the pavement, the neighbouring doorway or a car park you do not control. Capturing more than your own premises widens your processing without widening your justification, and it is usually fixable with angle, masking or a lower mounting point.

Two capabilities change the analysis entirely. Audio recording is substantially more intrusive than video, captures conversations that have nothing to do with security, and is rarely proportionate — most systems have it on by default and it should usually be off. Facial recognition used to identify individuals processes biometric data under Article 9, which means you need an Article 9(2) condition on top of your Article 6 basis, and the Working Party's view is that facial recognition in workplace video analytics is likely to be disproportionate.

Retention, And The Request For A Copy

GDPR sets no retention period for footage. Article 5(1)(e) requires you not to keep personal data longer than necessary for the purpose, and for premises security the honest necessity window is short — long enough to notice an incident and pull the relevant clip. Many organisations land somewhere between a few days and a month, and the number matters far less than being able to explain how you chose it and having the system actually enforce it.

The Request Nobody Plans For

Footage of an identifiable person is their personal data, so they can ask for a copy under Article 15. This is operationally the hardest thing in this article, for two reasons.

First, you have to find it, and CCTV is indexed by camera and timestamp rather than by person. If the requester cannot narrow the window, you can ask them to, but you cannot simply refuse.

Second, Article 15(4) says the right to obtain a copy must not adversely affect the rights and freedoms of others — and footage of one person in a shared space is footage of everyone else who walked through it. That means blurring or otherwise obscuring third parties before disclosure. Whether your system can do that, and who does it, is worth establishing before a request arrives rather than during the one-month clock.

Retention interacts with your wider deletion obligations too, and footage held in system backups follows the same logic as any other data — covered in our piece on deleting personal data from backups. Where CCTV sits alongside the broader question of what employee data you may collect, our HR data collection guide covers that territory.

Common Mistakes With Office CCTV

Relying on consent, or on a sign as the whole notice. Consent is not freely given in this setting, and "CCTV in operation" tells people almost nothing Articles 13 and 14 require.

Keeping footage indefinitely because the drive is large. Storage limitation applies. An undocumented retention period that defaults to whenever the disk fills is not a decision, and it is the first thing a regulator asks to see.

No plan for a subject access request. You need to locate footage by person and time, and redact everyone else in frame. Discovering you cannot do either after the clock starts is the common failure.

Leaving audio on by default. Most systems record it, most operators never chose to, and conversation capture is far harder to justify than the video it accompanies.

Treating the security contractor as a supplier rather than a processor. A firm that monitors, stores or accesses your footage processes personal data on your behalf and needs an Article 28 contract like any other processor.

FAQ

Do we need consent to install CCTV in the office?

No, and you should not rely on it. Consent must be freely given, and neither an employee nor a visitor can realistically refuse a camera at the entrance. The workable basis is legitimate interests, supported by a documented assessment showing the cameras are necessary and that a less intrusive measure would not do the job.

How long can we keep CCTV footage?

GDPR sets no fixed period. Article 5(1)(e) requires you to keep it no longer than necessary, which for premises security is usually days rather than months — long enough to spot an incident and retrieve the clip. Set a period, document why you chose it, and make sure the system enforces it automatically.

Can an employee ask for CCTV footage of themselves?

Yes. Footage of an identifiable person is their personal data and falls within Article 15. You can ask them to narrow the time and location, but you cannot refuse on the basis that searching is inconvenient. You must also obscure other people appearing in the same footage before you disclose it.

Do we need a DPIA for office CCTV?

Often yes. Article 35(3)(c) makes it mandatory for large-scale systematic monitoring of publicly accessible areas, and even below that threshold the recognised high-risk indicators — systematic monitoring, and employees as vulnerable data subjects — combine to point toward one. Doing it is cheaper than arguing about whether you needed to.

Closing Thought

Cameras get installed for a specific reason — a break-in, an insurance requirement, a nervous landlord — and then stay forever, pointed at whatever the installer found convenient, recording audio nobody asked for, keeping footage until the disk fills. The compliance problem is rarely the decision to have CCTV. It is that nobody ever revisits it.

Which suggests the useful question is not "are our cameras lawful" but "would we install these cameras, in these positions, with these settings, if we were deciding today." For most offices the honest answer is no, and that gap is exactly what a regulator would be looking at.

ComplyDog does not manage cameras. It handles the paperwork that surrounds this — your records of processing activities, where CCTV should appear as a named processing activity with its purpose and retention period, plus DPA management for the security firm and a portal for handling the access requests. You can try it free for 14 days, no credit card required.

This article covers the three conditions that have to be met before the right exists at all, the difference between provided, observed and inferred data, what "structured, commonly used and machine-readable" rules out, the direct-transmission right and its limits, and how to build one export that serves both portability and access without conflating them.

The Three Conditions

Article 20(1) gives a person the right to receive the personal data concerning them which they have provided to a controller, in a structured, commonly used and machine-readable format, and to transmit that data to another controller without hindrance. But it only applies where two further things are true, set out in the same paragraph: the processing is based on consent or on a contract, and it is carried out by automated means.

That basis condition is the one that surprises people. If you process on legitimate interests, there is no portability right. If you process to meet a legal obligation, there is no portability right. A bank running anti-money-laundering checks processes a great deal of personal data on a legal obligation basis and owes no portability duty on any of it, however clearly the data concerns the person asking.

For most B2B SaaS the practical answer is that account data, profile information and content the customer created sit under contract, so they are portable. Fraud signals, security logs and anything you retain for a legal obligation generally are not.

Two further limits sit in the same article. Article 20(3) says the right does not apply to processing necessary for a task in the public interest or in the exercise of official authority, and that it is without prejudice to the right to erasure. Article 20(4) says exercising portability must not adversely affect the rights and freedoms of others — which matters more than it sounds, and comes up below.

Provided, Observed, Inferred

"Provided by the data subject" is the phrase that decides the scope of your export, and it does not mean what a literal reading suggests.

The Article 29 Working Party's guidelines on the right to data portability read the phrase broadly and split the data into three categories.

Provided data is what the person actively and knowingly gave you: their name, their email address, everything they typed into a form, the content they uploaded.

Observed data is what you collected by watching them use the service — search history, traffic data, location data, activity logs, raw readings from a device. The Working Party is explicit that this is in scope. Teams that export only the profile form and call it done have under-delivered.

Inferred and derived data is what you created by analysing the first two: a credit score, a health assessment, an analytics profile, an evaluation report, a churn-risk rating. This is not in scope and you do not have to hand it over. Your model outputs about a customer stay yours.

Two boundary points worth knowing. Anonymous data is out of scope because it is not personal data at all. Pseudonymous data that can be clearly linked to the person — including where they supply the identifier themselves — is in scope.

What "Machine-Readable" Rules Out

The format requirement is three adjectives and each one does work: structured, commonly used, and machine-readable.

CSV, JSON and XML all qualify comfortably. A PDF does not, because it is not machine-readable in any useful sense — the point of the right is that the person can take the file elsewhere and have a second service ingest it. A screenshot certainly does not. A proprietary format that only your product can open fails the "commonly used" limb.

Beyond format, the export should be intelligible. A JSON dump of internal column names with no key is technically machine-readable and practically useless, and the transparency principle in Article 5(1)(a) applies to the response as much as to the notice. Include field descriptions.

Where an export actually lives varies by product and it is worth knowing yours before a request arrives — our piece on Notion records where one vendor's workspace export sits, which is the sort of detail that turns a month-long scramble into an afternoon.

There is no obligation to invent interoperability. Recital 68 says the right does not create an obligation for controllers to adopt or maintain processing systems that are technically compatible with one another. You have to produce a good file. You do not have to match a competitor's schema.

Direct Transmission, And The Third-Party Problem

Article 20(2) adds that where technically feasible, the person can require the data to be transmitted directly from one controller to another. "Where technically feasible" is a real qualifier, not a formality, and combined with Recital 68 it means you are not obliged to build integrations with every competitor who asks. If you have an API that can do it, the argument that it is infeasible gets weak.

Article 20(4) is the constraint people forget. An export frequently contains other people's personal data: a shared workspace shows collaborators, a messaging history shows the other participants, an address book is entirely third parties. You cannot refuse the whole request on that basis, but you also cannot disclose freely.

The workable approach is to scope the export to the requester's own data, include third-party data only where it is genuinely inseparable from theirs, and avoid exporting other users' contact details, content and identifiers as a convenience. Where third-party data does travel, the Working Party's position is that the receiving controller may only process it under the requester's sole control and for their own purposes.

Timelines, And Building It Once

The mechanics are the same as any data subject right. Article 12(3): one month from receipt, extendable by two further months for complex or numerous requests, with the person told about the extension and why within the first month. Article 12(5): free of charge, unless the request is manifestly unfounded or excessive.

Because the timing and identity-verification steps are shared with access requests, the sensible build is one export pipeline with two scopes. The access scope is wider — it covers everything you hold about the person regardless of lawful basis, plus the supplementary information Article 15 requires. The portability scope is narrower and cleaner: consent and contract processing only, provided and observed data only, in a structured file. The DSAR machinery around both — intake, identity checks, deadline tracking, redaction — is covered in our complete DSAR guide, and this article does not repeat it.

One thing that surfaces during the build: observed data usually lives in logs and event streams rather than in the application database, so knowing what your logging actually captures is a prerequisite for scoping a portability export correctly.

Common Mistakes With Data Portability Requests

Treating portability as access with a different file extension. The lawful-basis condition alone excludes a great deal of what an access request would cover. Running one query for both means either over-disclosing or missing the supplementary information Article 15 requires.

Exporting only actively submitted data. Observed data — activity logs, search and usage history, location — is in scope. An export containing just the signup form is incomplete.

Handing over inferred data by default. Scores, segments, risk ratings and analytics profiles are outside Article 20. Exporting them anyway gives away proprietary work nobody asked for.

Providing a PDF. It fails the machine-readable limb, and it defeats the purpose of a right designed to let people move between services.

Ignoring Article 20(4). Exports that sweep in collaborators, message counterparties or an entire address book disclose other people's personal data to satisfy one person's request.

FAQ

Is data portability the same as a subject access request?

No, and conflating them causes most portability errors. Access covers everything you hold about the person on any lawful basis, plus context about your processing. Portability covers only consent- and contract-based processing, only automated processing, and only data the person provided or you observed — but it must arrive in a structured, machine-readable file.

Does portability apply if we rely on legitimate interests?

No. Article 20 lists consent and contract only. Processing on legitimate interests, legal obligation, vital interests or public task carries no portability obligation. That said, the same data is usually still within scope of an access request, so refusing portability is rarely the end of the conversation.

What format do we have to provide?

Something structured, commonly used and machine-readable — CSV, JSON and XML are the safe answers. PDFs and screenshots do not qualify. There is no obligation to match another provider's schema, but there is a practical obligation to make the file intelligible, which usually means shipping a short key alongside it.

Do we have to send the data directly to a competitor?

Only where it is technically feasible. Article 20(2) creates the right, and Recital 68 confirms you need not build or maintain systems that are technically compatible with anyone else's. If you already have an API that could do it, feasibility becomes harder to dispute than if you would have to build one.

Closing Thought

Portability was written to break lock-in, and the uncomfortable implication is that a well-built export is a switching aid you are legally required to hand your customers. Most teams respond by building the minimum and hoping nobody asks.

The teams that do better tend to notice something else: the export you build for Article 20 is the same export that lets a customer leave gracefully, migrate between your own plans, or run their own analysis. A right you resent is often a feature you have not recognised yet.

ComplyDog handles the request side of this — a self-serve intake form for data subject requests, on a portal hosted on your own domain, with the records of processing that tell you which lawful basis applies to which data in the first place. That last part is what decides what belongs in a portability export. You can try it free for 14 days, no credit card required.

This article covers the three conditions that bring a decision inside Article 22, the three exceptions that permit it, the safeguards that attach when you rely on them, what "solely" means after the Court's first ruling on the provision, and the automated decisions ordinary SaaS products make without noticing.

The Three Conditions

Article 22(1) applies where all three of the following are true, and the Court of Justice confirmed this cumulative structure in its first ruling on the provision.

There is a decision. The concept is read broadly. It is not limited to a formal determination communicated to the individual, and it can include acts that affect a person in a variety of ways.

It is based solely on automated processing, including profiling. Profiling is defined in Article 4(4) as automated processing used to evaluate personal aspects of a person — analysing or predicting performance, economic situation, health, preferences, reliability, behaviour, location or movements.

It produces legal effects or similarly significantly affects the person. Legal effects are the narrower category: something that changes legal status or rights. "Similarly significantly affects" is the limb that catches most commercial systems, and it turns on the consequences for the individual rather than the sophistication of the method.

Recital 71 gives the archetypes: automatic refusal of an online credit application, and e-recruiting practices without human intervention.

The Court's decision in SCHUFA Holding (Case C-634/21, 7 December 2023) is the reference point for how widely this reaches. A credit reference agency generated a probability value about an individual's ability to repay, and supplied it to lenders. The agency argued that it made no decision — the bank did. The Court disagreed: where a third party draws strongly on that score to establish, implement or terminate a contractual relationship, generating the score is itself an automated individual decision under Article 22(1), and the Article 22 obligations attach to the agency and not only to the lender. The Court also confirmed that Article 22(1) operates as a prohibition in principle, which does not have to be invoked by the individual to bite.

The lesson for a SaaS company is that supplying scores rather than making decisions is not the shelter it looks like. If your customers act on your output more or less automatically, the output may be the decision.

The Three Exceptions, And What Comes With Them

Because Article 22(1) is a prohibition, you need one of the exceptions in Article 22(2) before you can do this at all.

(a) Necessary for entering into, or performance of, a contract between the individual and the controller. "Necessary" is the constraint. Convenient, cheaper and faster do not qualify; the question is whether the contract could be performed by a less intrusive route.

(b) Authorised by Union or Member State law which lays down suitable safeguards. This is the route for fraud prevention and tax evasion regimes and other statutory schemes, and it depends on a specific law existing.

(c) Explicit consent of the individual. Explicit is a higher standard than ordinary consent — an express statement, not an inferred agreement — and it must still be freely given, which means a genuine alternative has to exist.

The Safeguards That Come With Them

Where you rely on (a) or (c), Article 22(3) requires safeguards, and it sets a floor rather than a menu. At minimum, the individual must be able to obtain human intervention, to express their point of view, and to contest the decision. These are operational commitments rather than policy language: someone must actually be available, and they must be able to change the outcome.

Article 22(4) adds a further restriction. Decisions of this kind may not be based on special category data unless Article 9(2)(a) explicit consent or 9(2)(g) substantial public interest applies, with suitable safeguards in place.

Alongside the exception you need transparency. Articles 13(2)(f) and 14(2)(g) require you to tell people at collection that automated decision-making is happening, and Article 15(1)(h) lets them ask afterwards. In each case the requirement is the same: meaningful information about the logic involved, and the significance and envisaged consequences of the processing for them.

What "Solely" Means, And Why Token Review Fails

"Solely" is where most teams try to escape Article 22, and where most of them fail.

The escape route is familiar: put a person in the loop, and the decision is no longer solely automated. It works only when the human involvement is real. Regulatory guidance and the Court's approach both point the same way — a person who rubber-stamps an output, or who lacks the authority or the information to reach a different conclusion, does not take the decision out of Article 22. The Court's reasoning in SCHUFA went further in the same direction, treating a score as an automated decision where the eventual decision-maker draws strongly on it.

Three questions determine whether your human review is genuine. Does the reviewer have the authority to overturn the outcome? Do they have access to the underlying information, rather than only the system's conclusion? Do they in fact overturn outcomes sometimes — and can you show it?

That last one is the useful test, because it is measurable. A review step with an approval rate of 100% across ten thousand decisions is not review. It is a logging step with a person attached, and the override rate is the number a regulator will ask for.

The Automated Decisions SaaS Products Make Without Noticing

Article 22 is widely assumed to be about artificial intelligence. It is not. It is about consequences, and a deterministic rules engine can produce them just as effectively as a model.

Some patterns worth checking in an ordinary B2B product: automated account suspension triggered by fraud or abuse scoring; automated rejection or approval of applications, credit limits or payment terms; algorithmic pricing that materially changes what an individual is offered; automated content removal on a platform where the account carries someone's livelihood; automated screening in a hiring product, which Recital 71 names directly; and automated performance scoring inside workforce tools, which is where this meets the question of what employers may lawfully monitor.

Two structural points follow.

A Data Protection Impact Assessment is likely to be mandatory rather than advisable. Article 35(3)(a) names systematic and extensive evaluation of personal aspects based on automated processing, on which decisions are based producing legal or similarly significant effects, as a case requiring one.

And profiling on pseudonymised data does not take you outside Article 22. The provision is about decisions concerning a person, and pseudonymised data remains data about an identifiable person — a distinction set out in our guide to anonymisation versus pseudonymisation. If a decision reaches an individual, the fact that the pipeline used tokens rather than names does not change the analysis.

Article 22 is one part of a wider set of obligations around algorithmic systems — model governance, bias testing, training data provenance and the newer AI-specific regimes are separate subjects with their own requirements, and our AI compliance guide for SaaS covers that territory. This article is only about the decision.

Common Mistakes With Article 22

Assuming it only applies to AI. The test is whether a decision is solely automated and significantly affects someone. A if score > threshold then suspend rule written years ago meets it exactly as a model would.

Relying on human review that never changes anything. If the reviewer cannot overturn the outcome, cannot see the underlying data, or never does overturn it, the decision remains solely automated and your exception has quietly failed.

Treating explicit consent as the easy option. It must be explicit, specific and freely given, which requires a real alternative. Consent extracted as a condition of using the service is not freely given, and you are left with no exception at all.

Building no route to contest. Article 22(3) requires human intervention, the ability to express a view, and the ability to contest. A product with automated suspension and no appeal path is missing a mandatory safeguard, not a nice-to-have feature.

Disclosing nothing because you will not disclose the source code. Meaningful information about the logic means the factors used and their significance, in terms the person can understand. It has never meant publishing the algorithm, and refusing everything to protect trade secrets fails an obligation that never required them.

FAQ

Does Article 22 apply to rules-based systems, or only to machine learning?

It applies to any decision based solely on automated processing that produces legal or similarly significant effects. Nothing in the wording refers to a technique. A deterministic rules engine that suspends accounts is squarely within scope, and is more likely to be overlooked precisely because nobody thinks of it as an algorithm.

What counts as "similarly significantly affects"?

It turns on the consequences for the individual. Denial of a service they depend on, termination of an account carrying their income, materially different pricing, or exclusion from an opportunity all point toward it. Trivial personalisation such as which banner someone sees generally does not, though intensity and context can shift that.

Do we have to explain how our algorithm works?

You have to provide meaningful information about the logic involved and the significance and envisaged consequences — the factors that carried weight and how they affected the outcome, in language the person can act on. Disclosing source code or model weights has never been the requirement.

Is automated account suspension covered by Article 22?

Very likely, where the suspension is applied without a human deciding and the account matters to the person — a seller's storefront, a professional's client access, a business customer's operations. If so, you need an Article 22(2) exception, the Article 22(3) safeguards including a genuine appeal, and transparency at the point of collection.

Closing Thought

The most common way to breach Article 22 is not to build a controversial scoring system. It is to add a threshold to a rule, ship it, and never think of it as a decision about a person. Nobody writes a design document titled "automated determination affecting individuals"; they write a ticket about reducing fraud, and the effect on the person on the other end appears nowhere in the work.

Which suggests the practical question is not "are we compliant with Article 22" but "what does our software do to people without a human ever looking." Most teams have never made that list. It is usually shorter than feared and longer than expected.

ComplyDog does not audit your decision logic. It handles the compliance records that surround it — records of processing activities, which is where automated decision-making should be documented, subprocessor tracking, DPAs and data subject request handling, all on a portal hosted on your own domain. You can try it free for 14 days, no credit card required.

This article covers what each term means in the text, the standard Recital 26 sets for anonymity, the three risks a technique has to defeat, why hashing an email address does not anonymise it, and where pseudonymisation genuinely pays off despite keeping you in scope.

What The Regulation Actually Defines

Only one of these terms is defined in the GDPR. Article 4(5) defines pseudonymisation as processing personal data in such a way that it can no longer be attributed to a specific data subject without the use of additional information, where that additional information is kept separately and is subject to technical and organisational measures ensuring non-attribution.

Read the shape of that. It assumes the additional information continues to exist. Pseudonymisation is a way of holding data such that the link is broken in the dataset while the means to restore it are held apart. Separation, not destruction.

Anonymisation is not defined in the articles at all. It appears in Recital 26, which says the principles of data protection do not apply to anonymous information — information that does not relate to an identified or identifiable person, or personal data rendered anonymous in such a way that the data subject is not or no longer identifiable. Recital 26 also disposes of a common misconception directly: pseudonymised data which could be attributed to a person by the use of additional information should be considered information on an identifiable person.

So the two are not points on a scale. Pseudonymisation is a security and risk-reduction measure that happens inside the regulation. Anonymisation is an exit from it. Article 32(1)(a) names pseudonymisation alongside encryption as an example of an appropriate security measure, which is exactly where it belongs and exactly what it is — the same list our article on whether GDPR requires encryption works through.

"Reasonably Likely To Be Used" Is The Real Test

Recital 26 sets the standard for identifiability, and it is broader than most teams apply.

To determine whether a person is identifiable, account should be taken of all the means reasonably likely to be used to identify them, either by the controller or by another person. Whether means are reasonably likely to be used is judged against objective factors: the cost and time required, the technology available at the time of processing, and technological developments.

Two things in that sentence do a great deal of work.

"Or by another person" means your own capabilities are not the test. If you delete the mapping table but your analytics vendor, your data warehouse, or a public dataset would let someone else re-link the records, the data is not anonymous. The question is not "can we identify these people," it is "could anyone, using means reasonably likely to be used."

"Technological developments" means the assessment has a shelf life. A dataset that was genuinely anonymous under 2018 conditions may not be under current ones, particularly where the identifying route is a combination with data that did not exist publicly at the time.

The practical effect is that anonymisation is a high bar and an irreversible one. If you can get back, you did not anonymise. And because it is irreversible, it is the only route to keeping a dataset indefinitely — storage limitation under Article 5(1)(e) does not apply to data that is no longer personal.

The Three Risks A Technique Has To Defeat

European regulators assess anonymisation techniques against three distinct risks, set out in the Article 29 Working Party's Opinion 05/2014 on Anonymisation Techniques and still the working framework. A technique only anonymises if it addresses all three. Defeating two is common and insufficient.

Singling out is the possibility of isolating records corresponding to one individual, even without a name — and it is the one risk Recital 26 names in the regulation's own text. A dataset where one row can be picked out as belonging to one person has not anonymised that person — you know there is someone, you know what they did, and that is enough to keep it in scope.

Linkability is the possibility of connecting two records relating to the same individual, whether within your dataset or between yours and another. Any stable identifier creates linkability, whatever it is made of, because the whole point of a stable identifier is that it matches.

Inference is the possibility of deducing an attribute with significant probability from other values. A dataset with no direct identifiers can still support a confident inference about a specific person if the combination of quasi-identifiers is narrow enough.

This is why removing the name column is not anonymisation. Postcode plus date of birth plus job title will frequently identify exactly one person, and no direct identifier was involved. Aggregation helps only when the group sizes are large enough that no cell describes an individual — a count of one is a person.

Why Hashing An Email Address Is Not Anonymisation

This is the single most common mistake in this area, and it is worth stating plainly: hashing produces pseudonymised data, not anonymous data.

Two reasons, and either is fatal on its own.

Hashes are deterministic. The same input always produces the same output, which is exactly why hashed identifiers are useful for matching and joining — and matching is linkability. A stable hash is a stable identifier, functionally identical to a customer number for the purpose of this test.

And the input space is small enough to search. Email addresses are not random. Common formats, known domains and existing breach corpora make reversing a hash of an email address a matter of computation rather than cryptanalysis. Adding a salt held by you improves security substantially and changes nothing about scope, because you still hold the salt, which is precisely the "additional information kept separately" of Article 4(5).

The same logic applies to encryption. Encrypted personal data is pseudonymised while the key exists, not anonymous. And in-product data scrubbing follows the pattern too — an error monitoring tool that strips personal data before events leave your infrastructure is doing valuable and genuine risk reduction, but what remains is minimised data rather than anonymous data. Our article on Sentry and what ends up in your error logs works through where that scrubbing actually happens in one such tool, which is the thing that determines how much it is worth.

Where Pseudonymisation Pays, Even Though You Stay In Scope

None of this makes pseudonymisation a consolation prize. The regulation rewards it in several concrete places.

It is named in Article 25 as a means of implementing data protection by design, and in Article 32(1)(a) as an appropriate security measure. It is relevant to the compatibility assessment under Article 6(4) when you want to use data for a new purpose. It reduces the severity of a breach, which affects both your risk assessment and what you have to tell people. And Article 11 provides that where you can no longer identify a data subject, you need not acquire additional information purely to comply — though the individual can supply information enabling identification, at which point the rights apply again.

There is a straightforward operational case too. Pseudonymised production data is what lets analytics, debugging and testing happen with meaningfully lower exposure, without pretending you have left the regulation behind.

The distinction matters commercially in one more way worth naming. "We anonymise the data" appears constantly in privacy notices, DPAs and questionnaire responses, and it is very often untrue as written. It is a statement about legal scope, it is checkable, and a customer's legal team will check it. If the mapping table still exists anywhere, the honest word is pseudonymised, and using the honest word costs you nothing except a sentence of explanation. A recording, a masked session or a hashed identifier all sit on the same side of the line — as does the question of whether a session replay has been anonymised by masking, which it has not.

Common Mistakes With Anonymisation And Pseudonymisation

Calling hashed identifiers anonymous. A hash is a stable identifier and therefore supports linkage. Salting improves security and does not change the answer, because you hold the salt.

Removing direct identifiers and stopping there. Quasi-identifiers routinely single people out in combination. The test is whether one record can be isolated, not whether a name column is present.

Assessing identifiability only from your own position. Recital 26 asks what means are reasonably likely to be used by anyone, including your vendors and anyone holding a dataset that joins to yours.

Keeping the mapping table "just in case." Retaining the key is the definition of pseudonymisation. A dataset described as anonymised while a re-identification route sits in a separate system is a mislabelled dataset and, if it appears in a contract, a misstatement.

Treating aggregates as automatically safe. Small cells identify individuals. A count of one, or a breakdown fine enough that one group has a single member, has not anonymised anybody.

FAQ

Is a hashed email address personal data under GDPR?

Generally yes. Hashing produces a stable identifier that supports linkage between records, and the limited input space of email addresses makes reversal feasible with available resources. It is a useful pseudonymisation technique and a real risk reduction, but the data stays in scope with all rights attached.

Is encrypted data anonymous?

No, not while a key exists that could reasonably be obtained. Encryption is a security measure, and encrypted personal data is pseudonymised rather than anonymous. If the key were destroyed irretrievably and no other route to re-identification existed, the analysis could differ — but that is data destruction, not a data strategy.

Can we keep anonymised data forever?

Yes. Storage limitation under Article 5(1)(e) applies to personal data, and genuinely anonymous information is not personal data. That is the main commercial reason to do the work properly. It is also why the claim gets made far more often than it is true.

Does pseudonymisation reduce our GDPR obligations?

It reduces risk rather than obligations. Every requirement still applies — lawful basis, retention, access and erasure rights, records of processing. What pseudonymisation does is lower the severity of a breach, count in your favour under Articles 25 and 32, and support a compatibility assessment for further processing.

Closing Thought

The reason this distinction is worth the attention is that anonymisation is the only genuine exit the regulation offers, and almost nobody who claims to have used it has. Everything else — encryption, hashing, masking, tokenisation, dropping the name column — reduces risk while leaving you exactly where you started, in scope, with retention limits and erasure obligations intact.

That is not a failure of those techniques. It is a reason to be precise about which one you actually did, particularly in the documents where you told a customer which one it was.

ComplyDog keeps the records that depend on getting this right — your records of processing activities, which have to state what data you hold and how long you keep it, your subprocessor list, and your DPAs — in one portal hosted on your own domain. You can try it free for 14 days, no credit card required.

This article covers the two-question structure and why the order matters, what a session recording actually captures compared with what teams assume, why masking has to be built the opposite way round from how most people build it, the rights that attach to a recording once it exists, and the specific problem faced by B2B products recording logged-in users.

Two Questions, Not One

The first question is about the visitor's device. Placing or reading information on someone's terminal equipment requires their consent unless it is strictly necessary in order to provide a service the user has explicitly requested. Session replay is analytics and product research. It is useful, it is not strictly necessary, and so the consent requirement applies. Practically, that means the script does not run until the visitor has agreed, and a script that loads on page one and waits for a consent signal afterwards has already done the thing that required permission.

The second question is about the data. Once you have recordings, you are processing personal data and you need a lawful basis under Article 6, plus the transparency that Articles 13 and 14 demand — visitors should be able to find out that sessions are recorded, why, for how long, and who else sees them.

The order matters because teams often get the second right and the first wrong. A privacy notice that describes session recording accurately, on a site where the recorder fires before any consent interaction, is a well-documented breach. Getting the sequencing right is the cheapest fix available and the one most often skipped.

Legitimate interests is sometimes proposed as the basis for the second question. It can work for the processing limb where the analysis is genuinely proportionate and the recordings are well controlled. It does not help with the first limb at all, because the consent requirement for device storage comes from a different instrument and is not displaced by a balancing test.

What A Recording Actually Contains

The gap between what teams think session replay captures and what it captures is where most of the risk sits.

A session recording is not a heatmap or an event stream. It is a reconstruction of what was rendered on that person's screen. That includes everything the page displayed and, unless specifically prevented, everything they typed. In practice that means free-text fields, search queries, partially completed forms that were never submitted, error messages containing account identifiers, and any personal data your own application rendered onto the page.

Three consequences follow, none of them hypothetical.

Special category data arrives without anyone deciding to collect it. A support form where someone explains why they need an accommodation, a booking flow where someone types a medical detail — these are Article 9 categories, and Article 9 restricts processing regardless of your Article 6 basis. Nobody chose to collect them, which is precisely the problem.

The recording may contain other people's personal data. If your product displays a customer's contacts, patients or employees on screen, a recording of that screen contains their data too, and they have no relationship with you at all.

And a replay is far more identifying than the events it replaces. Analytics might tell you an anonymous session clicked three things. A replay shows the account, the name on the screen and the text being typed.

Masking Has To Be Built The Other Way Round

The standard approach is a block-list: identify the sensitive fields, apply suppression to those, ship it. It fails predictably, and it fails at the worst possible moment.

The failure mode is change. A developer adds a field. A new page reuses an old component. Someone renames a CSS class during a refactor. None of these look like privacy events, and each silently drops a field out of the suppression rules. The recorder does not error. It just starts capturing something it should not, and nobody finds out until an access request makes someone go and look.

An allow-list inverts the default: nothing is captured unless it has been explicitly permitted. New fields are suppressed automatically because suppression is the default state, and adding a field to the recorder becomes a deliberate act. This is Article 25's data protection by design and by default applied to a specific problem — the default must be the protective setting, and with a block-list it is not.

Two related points. Most recording tools suppress some input types by default and offer controls for the rest; the defaults are a starting position and not a configuration, and the tool's own documentation is where you find out what it actually does. Where a tool sits in the relationship is a vendor question rather than a legal one — our article on whether Hotjar is GDPR compliant works through where one vendor's contract sits, what it covers and what stays yours, and the piece on PostHog does the same for a product where session recording is one feature among several.

And masking does not anonymise the recording. A masked replay still shows a specific person's session in a specific account, which is singling out — the line between reducing identifiability and actually leaving the scope of the regulation is set out in our guide to anonymisation versus pseudonymisation, and masking sits well on the near side of it.

The Problem Nobody Plans For: Recording Logged-In Users

For a B2B SaaS company this is the sharpest issue, and it is contractual before it is regulatory.

When you record an anonymous visitor on your marketing site, you are the controller of that person's data and the analysis is yours to justify. When you record a logged-in session inside a customer's account, the data on screen is largely your customer's data, and for that data you are usually their processor. Article 28 says a processor acts only on documented instructions from the controller.

So: does your customer's DPA instruct you to make video reconstructions of their users' sessions and share them with a third-party analytics provider? Most do not. Many list permitted processing purposes that do not obviously extend to it, and some prohibit onward disclosure without authorisation. Adding a session recorder to an authenticated application can therefore put you outside your own contract with your customers, and the exposure is a breach-of-contract claim from a paying customer rather than a regulatory one.

It also adds a subprocessor. The recording vendor now receives your customers' personal data, which means the vendor belongs on your subprocessor list, needs to go through your normal notification process, and gives customers something to object to.

The Rights That Attach Once A Recording Exists

A recording is personal data about the person recorded, which puts it in scope for an access request under Article 15 and an erasure request under Article 17. That sounds unremarkable until you try to service one.

The operational question is whether you can find every recording featuring one individual, across whatever retention window you set, and delete them. Recordings are typically indexed by session rather than by person, and the identifying detail sits inside the video rather than in a queryable field. Many teams discover this at the moment someone asks, which is the worst time to find out: the response clock is already running.

Test it before you need it. Pick a user, try to retrieve everything, and time it.

Common Mistakes With Session Replay And GDPR

Loading the script before consent. The recorder either runs or it does not, and running it is the act that needed permission. A consent banner that appears while recording is already underway documents the breach rather than preventing it.

Masking with a block-list. Suppressing named fields means every field added afterwards is captured by default. Allow-list the fields you want and let everything else stay suppressed.

Assuming your customers' DPAs permit it. Recording authenticated sessions in a multi-tenant product processes your customers' data. If their agreement does not cover it and your subprocessor list does not name the vendor, the problem is contractual and it belongs to you.

Keeping recordings indefinitely. Storage limitation applies. Recordings are unusually rich personal data and there is rarely a purpose that survives past a few months, so set a retention period and enforce it in the tool rather than in a policy document.

Calling masked recordings anonymous. A masked session still shows one identifiable person's journey through one identifiable account. It is reduced-risk personal data, in scope, and subject to every right that attaches to it.

FAQ

Do we need consent before running session replay?

For the script itself, yes. Storing or accessing information on a visitor's device requires consent unless it is strictly necessary to provide the service requested, and session replay is not. That means the recorder should not fire until consent is given, which is a technical sequencing requirement rather than a banner-copy one.

Can we rely on legitimate interests instead?

Not for placing the script — the consent requirement for device storage comes from ePrivacy rules and is not displaced by a balancing test. Legitimate interests can serve as the Article 6 basis for processing the recordings once lawfully obtained, provided the analysis is proportionate, controlled and disclosed.

Does masking make session recordings anonymous?

No. Masking suppresses field content; it does not prevent the recording from being linked to an identifiable person, particularly in an authenticated session where the account itself identifies them. The data stays in scope, with access and erasure rights attached.

Can we record sessions inside customer accounts in our B2B product?

Only if your agreement with that customer supports it. In an authenticated multi-tenant product you are typically the processor for customer data, acting on documented instructions. Check whether those instructions cover session recording, and add the recording vendor to your subprocessor list before you switch anything on.

Closing Thought

Session replay is unusual among analytics tools in that its value and its risk come from the same property: it captures things you did not anticipate. That is why it finds the bug nobody could reproduce, and it is why it collects the health detail somebody typed into a support form. You cannot keep the first and design out the second, because they are the same capability. What you can do is decide, deliberately and in advance, how much of the screen you are willing to record — and most teams have never made that decision at all. It was made for them by a default.

ComplyDog handles the paperwork that a tool like this generates: a subprocessor list that updates as your stack changes, a cookie consent banner, data subject request handling, and a compliance portal on your own domain where customers can check what you use before they ask. You can try it free for 14 days, no credit card required.

This article covers why consent fails at work and what replaces it, how the proportionality test is actually applied, the monitoring practices that are usually defensible and the ones that usually are not, why Article 88 means there is no single European answer, and what has to be in place before you switch anything on.

Why Consent Fails In The Employment Relationship

The Article 29 Working Party's Opinion 2/2017 on data processing at work (WP249), adopted on 23 June 2017 and still the reference point for European regulators, is direct about this: for the majority of data processing at work, employees cannot give valid consent, because the dependency inherent in the employment relationship means consent is not freely given. An employee asked to agree to monitoring by the person who controls their income and their reference is not in a position to refuse.

That is not a technicality to be drafted around. Consent obtained under those conditions is invalid, which means the processing has no lawful basis at all, which means every subsequent argument about proportionality is moot.

So employers rely on one of the other bases. Legal obligation covers monitoring you are required to perform — certain regulated sectors, certain record-keeping duties. Performance of the employment contract covers processing genuinely necessary to pay and manage someone. Most workplace monitoring, though, sits under legitimate interests, and that is the basis this article is really about, because it is the one that comes with a test you can fail.

The Opinion works through nine scenarios, including monitoring of ICT usage inside and outside the workplace, time and attendance, video systems, vehicles used by employees, and disclosure of employee data to third parties. If you are doing any of those, someone has already written down what the concerns are.

How The Proportionality Test Is Actually Applied

Legitimate interests under Article 6(1)(f) is a three-part test, and each part does independent work.

First, is the interest legitimate? Protecting company assets, preventing fraud, meeting a regulatory duty, securing systems — these qualify without difficulty. "Understanding productivity" is vaguer and gets weaker scrutiny only until someone asks what decision the data informs.

Second, is the processing necessary for that interest? Necessity means there is no less intrusive way to achieve the same end. This is where most surveillance programmes fail, and they fail on a specific pattern: the employer identifies a real risk, then selects a monitoring method far broader than the risk requires. If the concern is exfiltration of customer records, logging access to the customer database addresses it. Recording every keystroke on every machine does not address it better; it addresses a great many other things nobody was worried about.

Third, is the interest overridden by the employee's rights and interests? Recital 47 introduces the concept that matters here — the reasonable expectations of the data subject. An employee expects their access to a production database to be logged. They do not expect their webcam to activate periodically, their personal messages on a company laptop to be read, or their location to be tracked at the weekend. The further you travel from reasonable expectation, the more the balance tips.

Two practical points follow. Covert monitoring sits at the far end of this scale and is generally lawful only in narrow circumstances — a specific, articulable suspicion, where notifying the individual would defeat the investigation, and where national law permits it. It is not a standing operating mode. And where monitoring feeds decisions about people rather than merely informing humans, a separate regime applies on top: automated performance scoring or automated disciplinary triggers engage Article 22 and the rules on automated decision-making, which has its own prohibition and its own safeguards.

What Is Usually Defensible

The line is not drawn around technologies. It is drawn around specificity, disclosure and proportion. But some patterns recur.

Generally defensible, with disclosure and a documented purpose: authentication and access logging; audit trails on systems holding personal or financial data; endpoint management on company-issued devices; monitoring aggregate network traffic for security purposes; recording who accessed which customer record and when; retention of email for defined business and legal purposes.

What these share is that each attaches to a named risk, captures only what that risk requires, and would not surprise the person being monitored.

One caveat on the logs themselves. A record of who accessed what is personal data about the person who accessed it, and stripping the username to a token reduces exposure without taking the log out of scope — the line between the two is set out in our guide to anonymisation versus pseudonymisation. Monitoring data is subject to the same retention limits and access rights as anything else you hold.

What Usually Is Not

Generally difficult: continuous screen capture; keystroke logging across all activity; always-on webcam or microphone; reading the content of personal communications; tracking location outside working hours; monitoring personal devices under a bring-your-own-device arrangement, where the employer's interest stops at the boundary of the corporate container and the employee's private life begins on the other side of it.

Two further constraints deserve naming. Broad-capture monitoring will collect special category data by accident — a keystroke log picks up a message about a health condition, a screen recording captures union correspondence — and Article 9 restricts that processing regardless of your Article 6 basis. And the Working Party took the view that data from wearables should be accessible to the employee rather than the employer, and that facial recognition in workplace video analytics is likely to be disproportionate.

One scoping note: cameras covering physical premises raise a distinct set of questions about signage, footage retention and who may view it, which sit outside this article. The broader question of what employee data you may collect across the employment lifecycle is covered in our HR data collection compliance guide. This article is about watching people work.

Article 88 Means There Is No Single European Answer

This is the part that catches distributed teams, and it is structural rather than incidental.

Article 88 permits member states to provide more specific rules for processing employees' personal data in the employment context, by law or by collective agreement. Several have. The result is that identical monitoring can be lawful in one member state and unlawful in another, and that the GDPR itself will not tell you which.

The most common form this takes is worker representation. In jurisdictions with statutory works councils, the introduction of technical systems capable of monitoring employees typically triggers a consultation or co-determination right, meaning you cannot lawfully deploy the tool until that process concludes — irrespective of how strong your legitimate interests assessment is. Several national supervisory authorities have also published their own workplace guidance, which is where the practical detail on specific technologies tends to live.

For a SaaS company with employees in three countries, the workable approach is to design to the strictest applicable standard rather than run three monitoring regimes, and to check the local position before deployment rather than after. The question to ask is not "is this GDPR compliant" but "is this lawful in each country where someone will be monitored, and does anyone have to be consulted first."

Common Mistakes With Employee Monitoring Under GDPR

Putting monitoring consent in the employment contract. Consent signed as a condition of employment is not freely given and does not become valid because it is countersigned. Worse, relying on it means you never identified a lawful basis that works.

Deploying first and disclosing later. Articles 13 and 14 require you to tell people what you are doing with their data. Monitoring introduced quietly and explained after discovery converts a defensible security measure into a transparency breach and a trust problem simultaneously.

Skipping the DPIA. The WP29 DPIA guidelines (WP248 rev.01) set out nine indicators of likely high-risk processing and treat a combination of any two as generally pointing to a DPIA. Employee monitoring hits two by itself: systematic monitoring, and vulnerable data subjects — employees qualify precisely because the power imbalance means they cannot freely consent or object. Its absence is one of the first things a regulator asks about.

Treating a personal device as company territory. Under a bring-your-own-device arrangement your interest extends to corporate data and the container holding it, not to the device. Monitoring that cannot distinguish between the two is monitoring an employee's private life.

Collecting continuously because storage is cheap. Data minimisation applies to monitoring exactly as it applies to everything else. Capture aimed at a defined purpose is defensible; capture retained indefinitely in case a purpose emerges is the definition of what the principle prohibits.

FAQ

Can we read employees' emails on company accounts?

Sometimes, narrowly. A blanket right to read correspondence is very hard to justify. What is defensible is a defined process — access limited to specific circumstances such as a documented investigation or genuine business continuity, disclosed in advance in a policy, restricted to named roles, logged, and excluding anything marked or evidently personal. The account being company-owned does not by itself settle it.

Is keystroke logging ever lawful under GDPR?

Rarely, and never as a default. Continuous keystroke capture across all activity fails the necessity limb almost automatically, because a narrower measure will address the underlying risk. It also collects special category data incidentally, engaging Article 9. In a specific, time-limited investigation with national law permitting it, the analysis can come out differently.

Do we need works council approval to monitor employees?

In several member states, yes — the introduction of systems capable of monitoring staff commonly triggers consultation or co-determination rights, and deployment before that process concludes is unlawful regardless of your legitimate interests assessment. Article 88 allows these national rules, so check each country where a monitored employee sits.

Can we track company vehicles used by employees?

Usually yes for a defined operational purpose such as fleet management, safety or asset protection, with clear notice. The difficulty is private use. Where a vehicle may be used personally, continuous tracking outside working hours is generally disproportionate, and a common resolution is a privacy mode that suspends location capture outside those hours.

Closing Thought

Most monitoring programmes are not built from a risk assessment. They are built from a product demo, which arrives with capabilities already bundled, and the legal analysis is then reverse-engineered to fit whatever the tool happens to do. That order is what produces the failures — not malice, just a default configuration nobody chose deliberately and a legitimate interests assessment written to justify a purchase already made.

The uncomfortable part is that monitoring is also visible to the people being monitored, and they talk. A programme that survives regulatory scrutiny but tells your team you do not trust them has still cost you something the assessment did not measure.

ComplyDog does not monitor anyone. It handles the documentation side of the obligations that surround this — records of processing, subprocessor tracking, DPAs and data subject requests, hosted as a portal on your own domain, including requests from employees exercising their rights over monitoring data. You can try it free for 14 days, no credit card required.

This article covers what Article 32(1)(d) requires and what each of its three verbs is doing, why frequency is not specified and how to decide yours, the difference between a scan and a test when someone asks you which you did, why the market requirement is usually stricter than the legal one, and the specific failure that turns a penetration test into evidence against you.

What Article 32(1)(d) Requires

Three verbs, and they are not synonyms. You must test, assess and evaluate the effectiveness of your measures.

Testing is the activity: you probe the system and find out what happens. Assessing is the interpretation: you decide what the findings mean for the personal data you hold, which is not the same as reading a severity rating off a report. Evaluating effectiveness is the question the other two exist to answer — are the controls you put in place actually doing the job you assumed they were doing?

The subject of the sentence matters too. It is not "a process for testing your systems," it is a process for evaluating the effectiveness of your technical and organisational measures. Organisational measures are in scope. Whether your access review actually happens each quarter, whether leavers actually lose their accounts, whether your incident procedure works when someone follows it at two in the morning — these are testable, they are covered by 32(1)(d), and no penetration test will tell you about them.

And it says "a process." Not an event. A single test performed once, with no defined trigger for the next one and no route from a finding to a fix, is not a process, however good the report looks.

Nobody Specifies A Frequency, Including The Regulation

"Regularly" is the only guidance the text offers, and it is deliberate. The ICO's position on the same words is that what the tests look like, and how often you run them, will depend on your own circumstances — a regulator declining to set a number rather than a regulator being vague. The same risk-based logic that governs the whole of Article 32 governs its testing limb: appropriate to the nature, scope, context and purposes of the processing, and to the risk. It is the identical structure that makes encryption an example rather than a requirement two sub-paragraphs earlier.

That gives you two triggers rather than one. Calendar-driven testing is the obvious one, and annual is a common landing point because it aligns with audit cycles and buyer expectations rather than because a regulator picked it. Change-driven testing is the one teams forget: a new authentication flow, a migration to a new hosting provider, a significant change to how personal data moves through the system. A test performed in January says very little about the architecture you shipped in June.

If your processing is high-risk enough to require a Data Protection Impact Assessment under Article 35, the expectations rise with it. The DPIA documents the measures you rely on to bring risk down to an acceptable level, and a measure you have never tested is a measure you are asserting rather than demonstrating.

A Scan Is Not A Test, And The Difference Shows

Three things get called "testing" and they are not interchangeable.

Automated vulnerability scanning runs continuously or on a schedule, compares your stack against known issues, and produces volume. It is cheap, repeatable and genuinely useful, and for a low-risk product with a small attack surface a well-run scanning programme with tracked remediation can be a defensible answer to 32(1)(d) on its own.

Penetration testing is a human being attempting to reach something they should not, within an agreed scope and window. It finds the class of problem scanners cannot: chained logic flaws, broken authorisation between tenants, the endpoint that works exactly as designed and should not exist. For multi-tenant SaaS, tenant isolation is the finding that matters most and the one only a person will surface.

Red teaming is a goal-directed exercise against your detection and response, usually unannounced. It tests whether you would notice, which is a different question again.

The reason to be precise about which you did is that someone will eventually ask, in writing. Answering "yes, we perform penetration testing" when you run a monthly scanner is a misstatement in a contractual document, and a reviewer who asks for the report will find out. If you scan, say you scan, and say what else you do alongside it.

The Market Asks For More Than The Law Does

This is the part that reorders most teams' priorities. The GDPR asks for a process. Your customers ask for an artefact.

Enterprise buyers routinely require a penetration test report as a condition of purchase, and they are entitled to: Article 28(3)(h) gives controllers audit rights over their processors, and most DPAs turn that into a contractual right to evidence. Security frameworks push the same way — an ISO 27001 programme will drive you toward regular technical testing as part of demonstrating that Annex A controls work, and our ISO 27001 readiness guide covers what that involves. A pen test summary also sits in the standard document pack that arrives alongside a vendor security questionnaire, next to the SOC 2 report and the DPA, which is covered in what buyers request alongside a security questionnaire.

So the honest sequencing for a small SaaS is this: you will almost certainly end up commissioning a penetration test, and the reason will be a procurement team rather than a regulator. That is fine. Just do not confuse the two obligations, because they have different scopes. The buyer wants a report about your product. Article 32(1)(d) wants evidence that the measures protecting personal data — including the organisational ones no external tester will look at — are working.

What To Share, And What To Keep

An executive summary is the normal unit of disclosure, covering the date, scope, tester, severity counts and remediation status. Full reports contain reproduction steps for live weaknesses, and circulating them widens your exposure rather than narrowing it. Buyers who know the field expect the summary and do not push for more; one who insists on the full report is usually one who has not reviewed many vendors.

Common Mistakes With GDPR Security Testing

Believing an annual penetration test is the requirement. It is a common answer to the requirement, not the requirement itself. Teams that adopt it as a rule tend to test on the calendar and skip the architectural change that actually warranted a look.

Testing and not remediating. Article 32(1)(d) asks you to evaluate effectiveness. A report listing unresolved critical findings from eighteen months ago demonstrates that you tested, assessed, and then did nothing — which is worse evidence than never having tested, because it establishes that you knew.

Scoping around the risk. Excluding the authentication service, the admin panel or the tenant-isolation boundary produces a clean report about the parts nobody was worried about. Scope decisions belong in the record alongside the findings.

Calling a vulnerability scan a penetration test. It is an inaccurate statement in a document a customer relies on, and it is trivially exposed the moment someone asks who performed it and over what period.

Testing only the technology. Access reviews, offboarding, backup restoration and incident response are organisational measures inside the scope of 32(1)(d), and they are usually where the untested assumptions are.

FAQ

How often does GDPR require penetration testing?

It sets no frequency, because it does not require penetration testing. Article 32(1)(d) requires regular testing of the effectiveness of your measures, with "regular" determined by your risk. Most teams settle on annual technical testing plus a test after significant change, and document why that cadence suits their processing.

Does the test have to be performed by an external company?

Nothing in the GDPR says so. Independence strengthens the evidence and is often what buyers and certification schemes want, but an internal team with the right skills and genuine independence from the system under test can produce valid results. The constraint is usually commercial rather than legal.

Do we need a penetration test to be GDPR compliant?

No. You need a defensible process for evaluating whether your security measures work, and a record of having run it. For a small, low-risk product, continuous scanning with tracked remediation plus tested organisational controls can meet that. Whether it satisfies your customers is a separate question, and often the binding one.

Can we share the full report with a customer?

You can, but the convention is not to. An executive summary giving date, scope, tester, severity counts and remediation status is standard and widely accepted, and it is what most procurement teams mean when they ask for your penetration test.

Closing Thought

The interesting thing about Article 32(1)(d) is that it asks a question almost nobody answers: not "did you test," but "did the test tell you whether your controls work." Those come apart more often than they should. A penetration test scoped to the marketing site, or a scan whose findings nobody triages, satisfies the letter of an activity while leaving the actual question untouched — and a regulator reading your file after an incident will be looking at the gap between the two.

ComplyDog will not test your systems. What it will do is hold the evidence trail that surrounds the testing — your records of processing, your subprocessor list, DPAs and a security page buyers can read for themselves — on a portal hosted on your own domain, so the recurring "can you send us your documentation" thread becomes a link. You can try it free for 14 days, no credit card required.

This article covers the exact wording of Article 32 and why the qualifier matters more than the list, the four things Article 32 does require, the single place in the GDPR where encryption is named as something that earns you a concrete benefit, why encrypted data remains personal data, and what to write down so that "appropriate" is a position you can defend rather than a word you borrowed.

What Article 32 Actually Says

Article 32(1) opens with a set of factors: the state of the art, the costs of implementation, and the nature, scope, context and purposes of the processing, together with the risk of varying likelihood and severity to people's rights and freedoms. Weighing those, the controller and the processor must implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk.

Then comes the list, introduced by "including inter alia as appropriate":

• (a) the pseudonymisation and encryption of personal data
• (b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services
• (c) the ability to restore availability and access to personal data in a timely manner after a physical or technical incident
• (d) a process for regularly testing, assessing and evaluating the effectiveness of those measures

Read that list carefully and notice the asymmetry. Items (b), (c) and (d) describe outcomes and processes you plainly need in some form. Item (a) names two specific techniques. It is the only one that reads like a product requirement, which is exactly why it gets quoted out of context and turned into a rule that does not exist.

Article 32(2) then says what to weigh when assessing the appropriate level: in particular the risks presented by the processing, and specifically the risks of accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of or access to personal data. That is the sentence that should drive your decision. Encryption is one answer to one of those risks.

Why "Appropriate" Is The Operative Word

"Appropriate" is doing all the work in Article 32, and it is a relative standard, not a floor. Appropriate to what risk, for whose data, at what cost, given what is technically available today.

A team storing marketing contact details faces a different question from a team storing therapy session notes, and the regulation is deliberately built to produce different answers. Recital 83 makes the mechanism explicit: the controller or processor should evaluate the risks inherent in the processing and implement measures to mitigate those risks, such as encryption. The evaluation comes first. The measure follows from it.

This is also why chasing a named standard is a category error. GDPR specifies no algorithm, no key length, no cipher suite and no distinction between disk-level and field-level encryption. It will not tell you that AES-256 is enough, because "enough" depends on what you are protecting and from whom.

The consequence is uncomfortable: a rule you can fail is also a rule you can pass. Appropriateness can only be assessed after the fact, by a regulator who already knows what went wrong, which is why the reasoning you recorded beforehand is the whole of your defence.

The One Place Encryption Earns You Something Concrete

There is a single provision where encryption is named and where naming it produces a real, mechanical benefit, and most teams do not know it is there.

Article 34(1) says that when a personal data breach is likely to result in a high risk to people's rights and freedoms, you must communicate it to the affected individuals. Article 34(3) sets out three conditions that remove that obligation, and the first is about encryption: where you have implemented appropriate protection measures, those measures were applied to the data actually affected, and they render the data unintelligible to anyone not authorised to access it — "such as encryption."

That is the payoff. Not a lighter regulatory burden in the abstract, but the difference between emailing forty thousand customers to tell them their records were taken and not having to.

Two conditions on it, both easy to miss. First, the exemption is from telling the individuals, not from telling the regulator: Article 33 still obliges you to notify the supervisory authority, generally within 72 hours of becoming aware, unless the breach is unlikely to result in a risk. Second, the measures must have been applied to the affected data and must actually have rendered it unintelligible to the attacker. Data encrypted at rest, exfiltrated by an intruder who already had a live application session and a valid key, is not unintelligible to that person. The exemption turns on the facts of the incident, not on the entry in your security policy.

Encrypted Personal Data Is Still Personal Data

Encrypting a dataset does not move it outside the scope of the regulation. If you hold the key, or anyone else could reasonably obtain it, the data remains attributable to identifiable people and every obligation continues to apply: lawful basis, retention limits, access and erasure rights, records of processing, transfer rules.

This trips up more teams than the mandate question does, usually in the form of "the data is encrypted, so it is anonymous." It is not. At best it is pseudonymised, which is a security measure with real value and no effect on scope. The distinction has concrete consequences for what you may keep, for how long, and for what you may do with it, and it is worth getting right — our guide to anonymisation versus pseudonymisation sets out where the line sits and how far you have to go to cross it.

Article 32(1)(a) reinforces the point by naming pseudonymisation and encryption in the same breath, as two security measures of the same kind. Neither is described as a route out of the regulation, because neither is one.

What To Write Down, And What Buyers Will Ask For

Because "appropriate" is a judgment, the deliverable is the judgment itself. Article 5(2) makes you responsible for demonstrating compliance, and Article 24 requires measures you can show. In practice that means a short record covering four things: what personal data you hold and how sensitive it is, which of the Article 32(2) risks apply to it, which measures you chose and which you considered and rejected, and when you will revisit the decision.

Two paragraphs written before an incident are worth more than twenty written after one. The reasoning does not have to be elaborate. It has to exist, be dated, and match what your systems actually do.

A commercial reality runs on a separate track. Enterprise buyers do not ask whether GDPR requires encryption; they ask whether you encrypt at rest, with what, and whether you can prove it. The evidence they want is usually a configuration export rather than a policy statement — what buyers ask for in a security review covers the difference. Passing a vendor review and meeting Article 32 are related problems, and the first is often stricter.

Once you have decided that encryption is appropriate, the implementation questions begin: key management, what to encrypt at which layer, how to handle backups and rotation. Those are engineering decisions rather than legal ones, and our guide to enterprise data encryption covers them properly.

Common Mistakes With GDPR Encryption Requirements

Reading Article 32(1)(a) as a mandate. The phrase "as appropriate" governs the entire list. Quoting the sub-paragraph without it produces a requirement the regulation does not contain, and teams then spend budget defending against an obligation nobody imposed.

Treating encryption as a route out of scope. Encrypted personal data is personal data. Retention limits, erasure rights and transfer rules all still apply, and a dataset you believed was exempt is one nobody has been deleting.

Assuming disk encryption covers the breach that will actually happen. Full-disk encryption protects against a stolen server or a decommissioned drive. It does nothing about a compromised application account querying a live database through a legitimate connection, which is the more common failure.

Never recording the decision. With no documented risk assessment, "appropriate" becomes a claim you assert after an incident rather than a position you took before one. The absence of the record is itself an accountability failure under Article 5(2).

Storing the keys inside the blast radius. Keys held in the same environment as the data they protect will be taken in the same breach, and with them goes the Article 34(3)(a) exemption you were counting on.

FAQ

Does GDPR require encryption at rest?

No. No provision of the GDPR requires encryption at rest, in transit, or anywhere else. Article 32 requires measures appropriate to the risk and offers encryption as one example. For most systems holding personal data, encryption at rest is a reasonable conclusion from that assessment — but it is your conclusion, reached and recorded, not a rule handed to you.

If our data was encrypted, do we still have to report a breach?

To the supervisory authority, yes. Article 33 applies regardless of encryption, unless the breach is unlikely to result in a risk. What encryption can remove is the separate Article 34 duty to tell the affected individuals, provided the measures were applied to the affected data and genuinely rendered it unintelligible to whoever obtained it.

What encryption standard does GDPR require?

None. The regulation names no algorithm, key length or protocol, and it will not. It refers instead to the state of the art, which shifts over time and is meant to. Look to recognised sources such as your national supervisory authority's technical guidance or ISO 27001 for concrete parameters.

Is encrypted personal data still personal data?

Yes, wherever the key exists and could reasonably be obtained. Encryption is a security measure, not an identifiability test. Data does not leave the scope of the regulation until re-identification is no longer reasonably possible by anyone, which is a much higher bar than encrypting a column.

Closing Thought

The absence of a mandate is not the good news it first appears to be. A rule that said "encrypt personal data at rest using AES-256" would be a rule you could satisfy and stop thinking about. Article 32 instead hands you a standard that can only be evaluated in hindsight, by someone who already knows how the breach happened, and asks you to have decided well in advance. That is a harder obligation, not an easier one, and teams that read "not required" as "not our problem" have generally misread it.

ComplyDog will not encrypt your database, and no compliance tool will. What it does is hold the paperwork that makes an Article 32 decision defensible — your records of processing, your subprocessor list, your DPAs and a security page your buyers can read — in one portal on your own domain. That is the part of this that goes stale quietly, and the part regulators and enterprise buyers both ask to see. You can try it free for 14 days, no credit card required.

The problem an error tracker creates is different from the others in this cluster. An error report is a snapshot of your program at the moment it broke, and the moment it broke is exactly when it was holding a real person's real data.

This article covers how the addendum attaches, what actually arrives in an error report, the three places you can scrub it and why only one of them keeps data off Sentry's infrastructure, and the subprocessor mechanics.

The DPA Is Opt-In, And Versioned

Sentry's addendum works differently from most in this cluster, and the difference matters.

It is entered into between Functional Software, Inc., doing business as Sentry, and the party that electronically accepts, agrees or opts in to it — effective as of the date you electronically agree. That is not automatic incorporation into the terms. If nobody at your company has accepted it, you may not have an Article 28 contract in place, and "we pay for the product" does not establish one. Check.

Sentry also publishes its addendum with a version number and date, keeps every earlier version online at its own URL, and links published instructions for entering into it. The version live when we checked, on 7 August 2026, was 5.1.0 dated 29 May 2024, with five earlier versions listed. Record which one you accepted, because the document you agreed to is the one that governs and Sentry has made it possible to prove exactly which that was.

On roles, the addendum applies only where Sentry processes personal data as a processor, with the customer as controller or as a processor acting for a third-party controller. Under US state law Sentry acts solely as a service provider and undertakes not to retain, use or disclose personal data other than as described in the addendum, and not to sell or share it.

One more clause belongs here rather than buried in a schedule. The addendum expressly prohibits you from submitting sensitive personal information or special categories of data, states that Sentry does not request, require or wish to receive it, and provides that Sentry's obligations under the addendum will not apply with respect to such data. Hold that thought for the next section, because it is the reason scrubbing is not optional.

What Actually Arrives In An Error Report

Nobody decides to send personal data to an error tracker. It arrives attached to the exception.

A stack trace can carry local variable values, which on a failed checkout means the address and the order. A captured request can carry the body, which on a failed signup means the form the user just filled in. Headers carry cookies and authorisation tokens. Breadcrumbs carry the sequence of actions the user took to get there. User context carries whatever identifier your SDK was configured to attach, which is frequently an email address because that made triage easier.

The failure mode is specific to this category. Analytics tools capture what you told them to. An error tracker captures the state of the program at the point of failure, and failures happen in the code paths handling the most sensitive input, because that is where validation is hardest and edge cases live. Your error volume is not a random sample of your traffic. It is biased toward exactly the requests you would least like to store.

That is a processing activity, it is yours, and it belongs in your record of processing activities with a retention period beside it.

Now combine that with the prohibition above. A health application's exception can carry a diagnosis in a local variable. A recruitment tool's failed request can carry a declared disability. Nobody chose to send either, but the addendum prohibits submitting that data and disclaims Sentry's obligations over it if you do. So the exposure is not merely that special category data reached a processor — it is that it reached one whose contract expressly does not cover it.

Three Places To Scrub, And Only One Keeps Data Out

Sentry's documentation is unusually clear about this, and the distinction is the most useful thing in this article.

Sentry describes scrubbing PII in two places by default: in the SDK before the event is sent, and on arrival at Sentry's infrastructure. Relay, its optional service, adds a third — scrubbing centrally within your own infrastructure before anything is forwarded to Sentry.

Those three are not interchangeable, and the difference is where the data has been by the time it is removed.

Server-side scrubbing is configured centrally in Sentry and applied when an event arrives. It is the easiest to manage and the easiest to keep consistent. It also means the unscrubbed event crossed the network and reached Sentry before being cleaned.

Relay sits in your infrastructure, uses the privacy settings configured in Sentry, and scrubs before forwarding. Sentry's documentation frames this as the option for teams that cannot send PII outside their own infrastructure but still want central configuration.

SDK-level scrubbing, using the beforeSend and beforeSendTransaction hooks, prevents the data being collected on the device at all. Sentry notes the trade-off plainly: you may have to replicate the same logic across your applications, and it may affect performance.

If you have told a customer that personal data never leaves your infrastructure, only the second and third options support that claim. Central convenience and strict minimisation pull in opposite directions here, and choosing between them is a decision to make deliberately rather than by accepting a default.

The EU Region And The Transfer Position

Sentry states that with EU region availability you can choose to have your Sentry data hosted in the EU rather than the US, to meet data residency requirements. Treat the region as a setup-time decision and confirm the mechanics for your organisation before you create it, rather than after you have a year of events in the wrong place.

On transfers, Sentry self-certifies to the EU-US Data Privacy Framework along with the UK Extension and the Swiss-US Framework, and points customers to the public Data Privacy Framework participant list to confirm it — advice worth taking, since certification is a status that can lapse. Its addendum also incorporates the Standard Contractual Clauses for transfers of personal data out of Europe, with the UK Addendum amending them where the UK GDPR applies, so there is a mechanism underneath the Framework rather than only alongside it.

Subprocessor Notice, And The Address It Goes To

Sentry maintains its subprocessor list at sentry.io/legal/subprocessors/ and commits to imposing equivalent data protection terms on each subprocessor while remaining responsible for their acts and omissions.

The notice mechanism is better than most in this cluster and does not depend on you opting in. The current addendum commits Sentry to thirty days' prior written notice of subprocessor changes, by email or another means specified on the subprocessor page, with an objection window during that period. What it does depend on is your Notification Email Address — the address you designated at signup — and the addendum states you are solely responsible for ensuring it is current and valid at all times. A notice sent to a departed employee's mailbox has been validly given.

The objection right is real but the remedy is blunt: if Sentry does not remedy your objection or offer a reasonable workaround within a reasonable time, your sole remedy is to terminate the Agreement for convenience. Our guide to subprocessor management covers running that review.

Common Mistakes With Sentry And GDPR

Assuming the DPA is automatic. Sentry's addendum takes effect when someone electronically accepts it. Paying for the product does not accept it on your behalf.

Relying on server-side scrubbing while claiming data never leaves. Server-side scrubbing happens on arrival at Sentry. If the claim is that PII stays inside your infrastructure, you need Relay or SDK-level hooks.

Attaching an email address as the user identifier. It makes triage easier and turns every event into a record about a named person. A hashed or internal ID usually does the same job.

Never setting a retention period. Error events accumulate, and the ones with the richest context are the ones with the most personal data in them. Retention is your decision, not a default to inherit.

Leaving a stale Notification Email Address. Sentry gives thirty days' notice of subprocessor changes to the address you designated, and the addendum makes keeping it current and valid solely your responsibility.

FAQ

Do I need to accept a DPA with Sentry?

Yes, and that is the point to check. Sentry's addendum is entered into by the party that electronically accepts or opts in to it, effective from the date of acceptance, rather than being incorporated automatically. Confirm someone has done so, and record which numbered version they accepted.

Does Sentry offer EU data residency?

Sentry states that with EU region availability you can choose to have your data hosted in the EU instead of the US to meet residency requirements. Confirm the setup mechanics for your organisation before creating it, since region decisions of this kind are typically made at organisation creation.

How do I stop personal data reaching Sentry?

Sentry scrubs in the SDK before sending and on arrival at its infrastructure, and its Relay service adds central scrubbing inside your own infrastructure before forwarding. Only the SDK hooks and Relay prevent unscrubbed data leaving your environment; server-side scrubbing applies after the event has arrived.

Is Sentry a controller or a processor?

A processor. Its addendum applies where Sentry processes personal data as a processor, with the customer acting as controller or as a processor for a third-party controller, and under US state privacy law Sentry acts solely as a service provider and undertakes not to sell or share personal data.

Closing Thought

Error monitoring is the one category where the tool works better the more of your users it captures, and where nobody involved thinks of themselves as collecting anything. An engineer adding richer context to an event is trying to fix a bug faster. They are also expanding the categories of personal data your company holds, in a system that was probably never mentioned in a privacy notice.

The fix is unglamorous and it is a decision rather than a setting: agree what an error report is allowed to contain, implement it where it belongs given what you have promised, and put a retention period on the result. ComplyDog gives you a compliance portal on your own domain covering your DPA, your subprocessor list, your data subject request intake and your security page. It will not write your scrubbing rules. It will mean that when a customer asks what your engineers can see about their users, somebody has already answered the question in writing.

None of that answers the question that decides your exposure, which is where Segment sends the data next.

This article covers how the addendum attaches, the three transfer mechanisms on offer, what the EU region does and what it needs from you, and why every destination in your workspace is a compliance obligation of its own.

The DPA Is In The Terms, With One Caveat

Segment's documentation states that its online data processing addendum is already part of and incorporated into the Terms of Service. For most customers that means it is already in place and there is nothing to execute.

The caveat is specific and worth checking. Segment's guidance notes that if you have a separate written agreement that does not include a data processing addendum — or if you want to replace an older addendum attached to that agreement with Segment's latest — you should contact your account team or customer support. It also describes existing customers entering into the updated addendum through an opt-in process.

So the answer to "do we have a current DPA with Segment" depends on how you contracted. Self-serve on the standard terms: almost certainly yes. Negotiated paper signed some years ago: check, because you may be sitting on an older version or none at all. Our guide to data processing agreements covers what a current one needs to contain. We checked these pages on 7 August 2026.

Roles are the standard allocation with one wrinkle: Twilio's documentation notes that it processes customer content as a controller in limited circumstances set out in its addendum, for defined legitimate business purposes such as combating spam, fraud and other illegal activity.

Three Transfer Mechanisms, Which Is Unusual

Most vendors offer one route and perhaps a fallback. Twilio's privacy materials describe certification under the EU-US and Swiss-US Data Privacy Frameworks, plus Binding Corporate Rules and Standard Contractual Clauses for transfers outside the EU.

Binding Corporate Rules are the item worth noticing. They require approval by a European supervisory authority, take years to obtain, and very few processors have them — Twilio publishes a Processor Policy under its Binding Corporate Rules. If your transfer impact assessment has been difficult because your other vendors offer only Clauses, this is a materially different position and worth recording as such.

Twilio's own regional documentation describes the Framework as its primary mechanism for EU–US personal data transfers, and notes it will rely on it for Swiss–US transfers once a corresponding adequacy decision is in place. Its documentation also acknowledges, refreshingly, that interpretations of data residency are multi-faceted and that some customers will still want data to reside in the EU regardless.

Regional Segment, And The Configuration Behind The Click

Regional Segment lets you ingest, process and store customer data on EU-hosted infrastructure. Segment's marketing describes collecting EU customer data in the EU at the click of a button with no advanced configuration required.

The documentation is more precise, and the difference matters. Regional Data Ingestion sends data to Segment through regionally hosted API ingest points, for both device-mode and cloud-mode sources. The regional infrastructure can fail over across locations within a region but never across regions — a good, specific commitment. And some Segment SDKs require specific endpoint configuration to send data to the correct regional infrastructure, though Analytics.js picks up the correct ingestion endpoint automatically from source settings.

So the honest version is: mostly a click, plus an audit of every SDK and integration you have deployed. A mobile SDK or a custom server-side integration still pointing at the default endpoint is sending EU data somewhere you have told a customer it does not go. Check each source, not the toggle.

Every Destination Is A Processor You Must Account For

Here is the part that makes Segment different from every other vendor in this cluster.

Segment is a customer data platform, which is a polite way of saying it is a fan-out. Data arrives from your sources and is dispatched to destinations — your warehouse, your analytics tool, your email platform, your ad networks, your support desk. A workspace that has been running for two years typically has more destinations enabled than anyone can name from memory.

Three consequences follow, and none of them are Segment's to solve.

Each destination is a separate processor, and each needs its own contract, its own entry in your record and its own place on the subprocessor list you publish to your customers. Segment's addendum covers Segment. It does nothing for the tool at the other end of the pipe.

Each destination is also a transfer. A destination hosted outside the EEA moves personal data there on every event, regardless of what region you ingest into. Ingesting in Frankfurt and forwarding to a US ad platform is not EU residency in any sense a customer would recognise.

And enabling a destination is a two-minute job performed by whoever needed it, which is precisely the pattern our guide to subprocessor management exists to catch. Auditing your destination list is the highest-value hour in this article.

Deletion And Suppression Across A Fan-Out

Segment ships real controls here and they are better than most, which makes the boundary important to state precisely.

Segment offers one-click suppression to block collection for a specific user, and a process for managing deletion across Segment and supported destinations. Read the qualifier: supported destinations. Any destination that does not support the deletion flow is one you must handle yourself, and a deletion request satisfied in Segment while data persists in three downstream tools is not a satisfied request.

Before you rely on this in a data subject request process, list your destinations, mark which support automated deletion, and write down the manual steps for the rest. That document is the difference between a working erasure path and a plausible one.

Common Mistakes With Segment And GDPR

Documenting the platform, not the pipeline. "We use Segment" is not a processing record. Each source and destination moves specified categories of data to a named system, and that is the thing to describe.

Assuming the EU region covers the destinations. Regional ingestion governs where Segment ingests, processes and stores. A destination outside the EEA is still a transfer on every event.

Skipping the SDK audit. Some SDKs need explicit endpoint configuration for regional ingestion. An unchecked mobile SDK quietly undoes the residency claim you made.

Trusting deletion end-to-end. Deletion propagates to supported destinations. Unsupported ones are manual, and you need to know which is which before a request arrives.

Not checking which DPA you are on. If you have negotiated paper rather than the standard terms, your addendum may be an older version or absent. Segment's guidance says to contact your account team.

FAQ

Do I need to sign a DPA with Segment?

Usually not. Segment's documentation states that its online data processing addendum is already part of and incorporated into the Terms of Service. If you have a separate written agreement that does not include one, or you want to move to the latest version, Segment directs you to your account team or customer support.

Does Segment offer EU data residency?

Regional Segment lets you ingest, process and store customer data on EU-hosted infrastructure, with regionally hosted API ingest points for device-mode and cloud-mode sources, and failover within a region but never across regions. Some SDKs require explicit endpoint configuration, so audit your sources rather than relying on the toggle alone.

What transfer mechanisms does Twilio Segment use?

Twilio's privacy materials describe certification under the EU-US and Swiss-US Data Privacy Frameworks, and additionally offer Binding Corporate Rules and Standard Contractual Clauses. Binding Corporate Rules require supervisory authority approval and few processors hold them, so it is worth recording specifically.

Does Segment's DPA cover the destinations my data goes to?

No. It covers Segment's processing. Every destination you enable is a separate processor requiring its own contract, its own entry in your record of processing activities, and its own consideration as an international transfer where it sits outside the EEA.

Closing Thought

A customer data platform is bought to solve a plumbing problem and it does, comprehensively. The unintended effect is that it makes adding a new recipient of personal data easier than adding a new field to a form — a toggle, no deployment, no review, and data starts flowing to a company nobody has assessed.

That is not an argument against the category. It is an argument for treating the destinations list as a live document rather than a settings page, because it is the most accurate description of your data flows that exists anywhere in your business. ComplyDog gives you a compliance portal on your own domain covering your DPA, your subprocessor list, your data subject request intake and your security page. It will not enumerate your destinations. It will mean that once you have, the answer is published rather than rediscovered.

This article covers who the addendum actually applies to, the subprocessor clause worth quoting and the five-day window attached to it, where Vercel acts as controller rather than processor, and why a hosting platform belongs in your processing record even though nobody logs into it to look at data.

Where The DPA Is, And What It Attaches To

Vercel's addendum is published at vercel.com/legal/dpa. The version live when we checked, on 7 August 2026, was last updated 17 March 2026 with an effective date of 31 March 2026. The contracting entity is Vercel Inc., a Delaware corporation.

Read the first paragraph before anything else. The addendum forms part of Vercel's Enterprise Terms and Conditions or another executed agreement for Services on an Enterprise plan, and it states that it applies to Vercel's processing of personal data as a processor for customers on Enterprise and Pro plans. It becomes binding on entering the Agreement or on execution of the addendum itself.

The consequence is blunt and worth checking before you answer a questionnaire: a team running production on a free tier does not have this contract. "We use Vercel and they have a DPA" is true about Vercel and possibly not true about you. If you are unsure what the contract needs to contain once you have one, our guide to data processing agreements covers the required elements.

Vercel's compliance documentation sets out the processor commitments in plain terms: appropriate technical and organisational measures, notification of breaches without undue delay, similar data protection obligations imposed on subprocessors, assistance with data subject rights, and reliance on the EU Standard Contractual Clauses and the UK Addendum for transfers outside the EEA.

The Subprocessor Clause Is Stronger Than Most

This is the clause worth putting in front of a security reviewer, because it goes further than the standard flow-down.

Vercel's addendum commits it, when engaging a subprocessor, to require that subprocessor to protect customer data to the standard required by applicable law — including the Article 28(3) obligations and sufficient guarantees of appropriate technical and organisational measures. So far, standard.

Then it adds a geographic condition: Vercel will require any appointed subprocessor to agree in writing either to process data only in a country the European Union has declared to have an adequate level of protection, or to do so on terms equivalent to the Standard Contractual Clauses.

Most subprocessor clauses say the subprocessor must be bound to equivalent data protection terms and stop. This one addresses where the subprocessor operates as well as how it behaves, which is the question that actually matters for onward transfers. It is a good example of why reading the clause beats reading the summary — our guide to subprocessor management covers what else to look for in one.

The flow-down conditions go further still. Vercel's security schedule requires subprocessors to notify Vercel of security incidents, delete data on instruction, not engage further subprocessors without authorisation, and not change the location where data is processed. That last one closes the gap most subprocessor clauses leave open.

Now the part that costs you something. The subprocessor list, with functions and locations, is published at security.vercel.com. To receive notice of a new subprocessor you must email Vercel's privacy address to subscribe. Once notified, you have five calendar days to object in writing on reasonable data protection grounds. If the parties cannot agree a resolution, your sole and exclusive remedy is to terminate the Agreement for convenience — with no refunds, and remaining liable for any committed fees.

Five days is the shortest objection window in this cluster, and a remedy that costs you your prepaid fees is not really a remedy. Subscribe, route the notifications somewhere owned, and treat an objection as a commercial decision rather than a compliance one.

Transfers: Standard Contractual Clauses And The UK Addendum

Vercel's compliance documentation names the EU Standard Contractual Clauses and the UK Addendum as the mechanisms it relies on for transfers of personal data outside the EEA.

That is a different structure from several vendors in this cluster, which lead with the EU-US Data Privacy Framework and hold the Clauses in reserve. Neither approach is better in the abstract. What matters is that you write down the one your vendor actually uses, because a transfer impact assessment describing a mechanism your processor does not rely on is worse than no assessment.

If the Framework matters to your assessment either way, check the public Data Privacy Framework participant list rather than inferring participation from a marketing page, and record what you found and when.

Vercel Processes Whatever Your Application Processes

Here is the part that gets missed, and it is not a Vercel problem.

A hosting platform is not a tool people log into to look at customer records. It is the place your application runs. Every request your users make arrives there. Server-side rendering, API routes and serverless functions execute against real user input. Request logs carry IP addresses. Build and runtime logs carry whatever your code prints, which on a bad day includes a request body somebody added a debug line for and never removed.

None of that is a feature anyone enabled. It follows from deploying an application that handles personal data, and it means Vercel belongs in your Article 30 record as a processor with a purpose and a location beside it, in the same way your database does. Teams reliably list the CRM and forget the platform the whole product runs on. Keeping your record of processing activities honest means including the infrastructure.

The related discipline is log hygiene. Whatever your logging retention is, it applies to personal data captured incidentally as much as to data you meant to store, and "we did not intend to log that" is not a retention policy.

Where Vercel Is The Controller, Not Your Processor

The addendum splits Vercel's role, and the second half is easy to miss.

For Customer Data — the personal data inside your content, which the addendum describes as including things like IP addresses and system configuration information — you are the controller and Vercel is the processor. Standard.

But the addendum defines two other categories. Service-Generated Data means usage data and metadata generated through use of the Services, including through support. Contact Data means account information, payment information and event attendee information. For both, Vercel is the controller, processing them under its own privacy notice rather than your instructions — and it states it may use them to operate, improve and support the Services, to send marketing and service-related messages, and for other lawful business practices such as analytics, benchmarking and reporting.

That is not unusual and it is not hidden, but it changes what you can say. Requests about your account data are answered by Vercel as a controller, not routed through your DPA. And Vercel's own SCC schedule reflects this by applying Module One, controller to controller, to that category, alongside Modules Two and Three for Customer Data.

One further restriction sits in the same schedules: customers are prohibited from including sensitive data or special categories of data in Customer Data. If your application handles health, biometric or similar categories, that prohibition is a term you have agreed to, not just a risk to manage.

Common Mistakes With Vercel And GDPR

Leaving the hosting platform out of the processor inventory. The place your application runs processes everything your application processes. It belongs in the record next to the database.

Debug logging that outlives the debugging. A line added to print a request body during an incident becomes a standing collection of personal data in your logs. Retention applies to it regardless of intent.

Assuming the DPA covers your plan. It applies to Enterprise and Pro. A free-tier deployment handling personal data is running without the Article 28 contract you may be citing to customers.

Missing the five-day objection window. Notice requires you to subscribe by email, the window is five calendar days, and the only remedy is termination with no refunds. Unowned notifications make that decision by default.

Forgetting the controller half. Service-Generated Data and Contact Data are Vercel's to control under its own privacy notice. Those requests do not route through your DPA.

FAQ

Where is Vercel's DPA, and does it apply to me?

At vercel.com/legal/dpa, with Vercel Inc. as the contracting entity. Critically, it states that it applies to Vercel's processing as a processor for customers on Enterprise and Pro plans. If you are on a free tier, check your position before telling a customer you have a data processing agreement in place.

What transfer mechanism does Vercel use?

Its compliance documentation names the EU Standard Contractual Clauses and the UK Addendum as the mechanisms relied on for transfers of personal data outside the EEA. Record that in your transfer assessment rather than assuming a different route, and verify anything else on the public register.

Does Vercel place conditions on its subprocessors?

Yes, and they go beyond the usual. Its addendum requires appointed subprocessors to meet the Article 28(3) standard and, additionally, to agree in writing either to process data only in a country the EU has declared adequate, or to do so on terms equivalent to the Standard Contractual Clauses.

How much notice does Vercel give before adding a subprocessor?

You must email Vercel's privacy address to subscribe to notices. Once notified, you have five calendar days to object in writing on reasonable data protection grounds. If no resolution is agreed, the sole remedy is terminating the Agreement for convenience with no refunds, and you remain liable for committed fees.

Closing Thought

Developers and privacy teams describe the same system in languages that barely overlap. One says "we deploy to Vercel," meaning a build pipeline and a URL. The other hears nothing at all, because no name in that sentence sounds like a place where personal data lives.

It is the most reliable gap in a small SaaS privacy programme, and it closes with a conversation rather than a control: walk the request path with whoever owns it and write down every service it touches. ComplyDog gives you a compliance portal on your own domain covering your DPA, your subprocessor list — infrastructure included — your data subject request intake and your security page. It will not read your logs. It will mean the list exists somewhere other than in one engineer's head.

This article covers where the addendum is, what the EU option does and does not move, what happens to data already sitting in the US, and the checks worth running before you describe any of this to a customer.

Where The DPA Is, And How It Attaches

Airtable's addendum is published at airtable.com/company/dpa and its subprocessor list at airtable.com/company/subprocessors.

The mechanism is deemed signature rather than execution. The addendum provides that by entering into it, the parties are deemed to be signing the UK Standard Contractual Clauses and their applicable tables and appendix information — the same pattern used across this cluster, and the same evidence problem. There is no countersigned artefact, so record which version you accepted and when.

On transfers, Airtable states it has incorporated both the EU Standard Contractual Clauses and the UK Standard Contractual Clauses into the addendum. On subprocessors, the addendum commits Airtable to imposing contractual obligations on each subprocessor substantially the same as those imposed on Airtable, before that subprocessor processes any customer personal data. If you need a refresher on what a processing contract has to contain before you assess this one, start with our guide to data processing agreements. We checked these pages on 7 August 2026.

European Data Residency Is Real, And It Is Partial

Airtable's EU data centre is hosted on AWS in Frankfurt, Germany. Backups sit in different availability zones within Frankfurt and in a separate AWS data centre in Ireland — so the backup story is EU too, which is more than many vendors document at all.

What moves to the EU is base content: all record-level data, attachments, and base history. For most teams that is the substance of what they worry about, and it is a genuine answer to a residency question.

Two operational details that make the option easier than expected. Customers do not need to be based in Europe to enable European Data Residency. And Airtable states that some functionality may be disabled for customers with residency enabled, pointing to its support documentation for the specifics — so check the feature list against how your team actually uses the product before you switch anything on.

What Stays In The United States, Named

This is the part to read twice, because Airtable is unusually specific and most summaries skip it.

Information collected by Airtable — user and authentication data, metadata, and support data — is stored in the US. Airtable's stated reason is that this is how it runs a global offering, and it points to the Standard Contractual Clauses in its addendum as the transfer mechanism covering it.

Beyond that, Airtable names particular base metadata held out of region: base and interface names, base descriptions along with colour and icon information, and base access request data.

Base names are the item to think about. A base called "Redundancy consultation — Q3" or "Candidates rejected after background check" is metadata that is itself revealing, and it sits in the US regardless of the residency setting. That is not a criticism of Airtable, which has documented it plainly. It is an argument for a naming convention, and it is the kind of specific that belongs in your record rather than a general note that residency is enabled.

Audit logs have their own rule. Enabling residency stores all new audit log data in the EU, while previously existing audit log data remains in the US and is purged after 180 days.

Switching Is Not Retroactive

If you already have data in the US and you turn residency on, nothing moves by itself. Airtable states that data already stored in the United States will not be automatically migrated, and that customers wanting to migrate should contact their Airtable representative, who will work with them to do it without data loss.

That has a practical consequence worth planning for. A team that enables residency after two years of use has some data in Frankfurt and some in Virginia, and the answer to "where is our Airtable data" is "both, until we run a migration." Warranting EU residency to a customer while a migration is outstanding is a claim your infrastructure does not yet support.

Subprocessors, Certifications And What To Verify

Airtable's subprocessor list is published, and its residency FAQ points there specifically for which subprocessors process data in the EU — a sensible place to start when a customer asks about the chain rather than the vendor. Our guide to subprocessor management covers how to review that list on a cadence rather than in a panic.

On assurances, Airtable states it completes annual SOC 2 Type 2, ISO 27001 and ISO 27701 audits, and that data is encrypted at rest and in transit. ISO 27701 is the privacy management standard and is less common than ISO 27001, so it is worth naming specifically when a buyer asks what independent assurance exists.

One thing to confirm directly rather than infer: which plans include European Data Residency. Airtable's own FAQ discusses enabling it in an enterprise context, and third-party summaries disagree with each other about the tier. Ask, name your plan when you ask, and get the answer in writing before it appears in a customer-facing document.

Common Mistakes With Airtable And GDPR

Describing residency as "our data is in the EU." Base content is. User and authentication data, metadata, support data and named base metadata are not. Say which, or say less.

Forgetting base and interface names travel. They are held outside the EU region by design. A descriptive base name is metadata that reveals its own subject, and a naming convention costs nothing.

Assuming enabling residency migrates existing data. It does not. Migration is a separate exercise arranged with Airtable, and until it runs your data is split across regions.

Ignoring the disabled-functionality note. Airtable states some features may be unavailable with residency enabled. Discovering which ones after switching is an avoidable conversation.

Treating a base as a spreadsheet. Bases hold customer records, candidate details and vendor contacts. That is a processing activity with a purpose, a basis and a retention period, and it belongs in your record of processing activities.

FAQ

Does Airtable offer EU data residency?

Yes, with a documented scope. Airtable's EU data centre is on AWS in Frankfurt, with backups in Frankfurt availability zones and a separate AWS data centre in Ireland. Base content — record-level data, attachments and base history — is stored in the EU. Other categories, described below, are not.

What Airtable data stays in the United States?

Airtable names them: user and authentication data, metadata, and support data. It also names base metadata held out of region — base and interface names, base descriptions with colour and icon information, and base access request data. Standard Contractual Clauses in Airtable's addendum are the stated transfer mechanism.

Will my existing data move to the EU automatically?

No. Airtable states that data already stored in the United States is not automatically migrated and that customers wanting to migrate should contact their Airtable representative, who will work with them to avoid data loss. Until then, expect data in both regions.

What certifications does Airtable hold?

Airtable states it completes annual SOC 2 Type 2, ISO 27001 and ISO 27701 audits, and encrypts data at rest and in transit. ISO 27701 covers privacy information management specifically, which is worth naming when a buyer asks about independent assurance rather than security alone.

Closing Thought

Data residency is sold as a switch and delivered as a boundary, and the interesting question is always where the boundary falls. Airtable deserves credit for drawing its clearly: here is what moves, here is what does not, here is the list of metadata that stays behind. Most vendors leave you to infer it.

The awkwardness is that a boundary you have not read is worse than no boundary, because it produces confident answers that turn out to be wrong under questioning. Your customers will ask you the same thing you should be asking Airtable — where does this live, and what did you leave out of that sentence. ComplyDog hosts a compliance portal on your own domain carrying your DPA, your subprocessor list, your data subject request intake and your security page. It will not run your migration. It will mean the careful version of the answer is written down once, instead of improvised each time.

This article covers how the DPA attaches, how the transfer position is built, what the subprocessor list gives you that most do not, and the two places where scheduling tools quietly collect more personal data than anyone recorded.

The DPA Is In The Terms, With Nothing To Sign

Calendly's help centre states the position directly: it has incorporated a data processing addendum into its Terms of Use, there is nothing additional for you to sign or execute, and by accepting the Terms the DPA is already in place. The addendum itself is published at calendly.com/legal/data-processing-addendum, describes itself as incorporated into the Customer Terms between you and Calendly LLC, and carried an effective date of 1 June 2026 when we checked.

That is Article 28-sufficient and it removes a common source of delay. It also creates the familiar evidence problem: your contract is a document that can be revised, and what binds you is the version live when you agreed. Calendly's own materials note the addendum has been updated over time, including to add the UK Addendum. Record the date you accepted the Terms and keep a copy of the addendum as it then stood, in your processor file alongside everything else. Our guide to data processing agreements covers what the document needs to contain.

Two obligations in the addendum are worth quoting back at a reviewer, because they are the ones buyers actually ask about: Calendly commits to assisting you with your obligations under Articles 32 to 36, and to maintaining a record of the categories of processing carried out on your behalf under Article 30(2). We checked these pages on 7 August 2026.

Transfers: Framework First, Clauses Behind It

Calendly is a US company and its transfer position is built in two layers.

The addendum provides that transfers of customer personal data out of the EU, Switzerland or the UK to the United States are governed by the applicable Data Privacy Framework, and that Calendly is self-certified under them. If a Framework is invalidated or otherwise ceases to work as a transfer mechanism, the addendum provides that such transfers are instead governed by the Standard Contractual Clauses — Module 2, controller to processor — together with the UK Addendum where UK data is involved.

Two details are worth recording alongside that. The addendum names the Irish Data Protection Commission as the competent supervisory authority for the Clauses and picks Irish law and Irish courts, which is the answer to a question buyers occasionally ask and almost nobody has ready. And Calendly's privacy notice states that it has designated representatives in the European Economic Area and in the United Kingdom — the Article 27 mechanism giving European individuals and supervisory authorities a contactable point in their own jurisdiction, with contact details published in the notice.

One more thing that is genuinely useful and easy to miss. Calendly's help documentation points customers to request a transfer impact assessment FAQ covering US law. If you need to write a transfer impact assessment and have been putting it off because you do not know what to say about the importer, ask for that document.

A Subprocessor List That Answers The Right Questions

Calendly publishes its subprocessor list in its help centre, and the format is better than most.

Each entry carries not only the subprocessor and its processing activity, but a data protection officer contact and data centre locations. Most published lists give you a name and a purpose and leave you to find out where the processing happens; this one answers the residency question inline. Calendly also offers a subscription so you are notified when the list changes, and states that its subprocessors have signed DPAs.

Sign up for the notifications, and note why this one is not optional. The addendum gives thirty days' notice of a new subprocessor — but only to customers who have subscribed, and it states that a customer who does not subscribe waives any right it may have to receive prior notice of subprocessor changes. That is unusually blunt, and it means the two minutes it takes to subscribe is the difference between a contractual right and no right at all.

If you do subscribe, you have thirty days from notification to object by email on reasonable data protection grounds, silence counts as consent, and if the objection cannot be resolved you may terminate the affected portion of the Services without penalty. Our guide to subprocessor management covers how to review those notices without it becoming a standing meeting.

Invitee Data Is Yours, And There Is More Of It Than You Think

Here is where the compliance work actually sits.

You are the controller for everyone who books with you. That is not controversial and Calendly's documentation reflects it. What gets missed is how much personal data a booking page accumulates without anyone deciding to collect it.

A default booking collects a name and an email address, which is unremarkable. Then someone adds a custom question. "What would you like to discuss?" is a free text field into which people type things — a health condition before a consultation, an accessibility requirement, a dispute with an employer, a financial situation.

And here the contract bites, in a way most write-ups miss. Calendly's addendum records that, per the Customer Terms, you are not permitted to submit personal data to the Services that counts as sensitive personal information or special categories of data. So the problem with a free text field inviting health disclosures is not that you need an Article 9 condition. It is that you are not supposed to be putting that data there at all, and doing so puts you outside the terms you agreed to as well as outside your own lawful basis.

That reframes the fix. The answer is not "find a justification," it is "do not ask the question, or ask it somewhere built for the answer." Three things follow, and none of them are vendor problems. Every custom question is a collection decision that needs a purpose. Free text fields are where prohibited categories arrive, so the field itself is the control. And the bookings accumulate: a page that has run for two years holds everyone who ever met you, with whatever they typed, until somebody decides otherwise.

Worth knowing while you audit the fields: the categories the addendum contemplates now extend beyond names and emails to personal data in connected calendar event details, and to audio and visual meeting recording data and anything shown on screen during a meeting. If recording features are in use, the scope of what you are controller for is wider than a booking form.

The Calendar Connection Nobody Documents

The second gap is subtler and almost never appears in a processing record.

A scheduling tool works by reading your calendar to find out when you are free. That calendar contains other people's meetings — colleagues, clients, candidates, the people you had lunch with — and none of those people ever visited your booking page or agreed to anything. The connection is the core function, not an add-on, and it is the reason the product is useful.

It is not a theoretical concern, either. Calendly's own addendum lists personal data contained in connected calendar event details among the categories of personal data transferred, so the contract already contemplates the calendar's contents being in scope.

This is worth a sentence in your record and a moment's thought about scope. Which accounts are connected. Whether the connection is read-only or writes events back. Whether anyone has connected a personal calendar to a work account. These are not exotic questions, but they are the ones that come up when a regulator or a customer asks what a scheduling tool can see, and "it checks my availability" is not a description of a data flow.

Common Mistakes With Calendly And GDPR

Inviting sensitive answers in a free text field. The addendum records that customers are not permitted to submit special category data to the Services at all. "What would you like to discuss?" is where that rule gets broken, and the fix is the question, not a justification.

Leaving bookings forever. Nothing ages out on its own. Set a retention period for invitee records and enforce it, including anywhere you exported them.

Ignoring the calendar connection. The tool reads a calendar containing people who never used it. Document what is connected and with what scope.

Not subscribing to subprocessor updates. The addendum states that a customer who does not subscribe waives the right to prior notice of changes. Two minutes of setup buys you a contractual right you otherwise do not have.

Embedding without reading Exhibit D. If you embed Calendly on your site, its addendum treats you and Calendly as separate and independent controllers of the cookie data collected there — a different relationship from the processor terms covering bookings, with different obligations on each side.

FAQ

Do I need to sign a DPA with Calendly?

No. Calendly states that it has incorporated a data processing addendum into its Terms of Use, that there is nothing additional for you to sign or execute, and that accepting the Terms puts the DPA in place. Record the date you accepted and keep a copy of the addendum as it then stood.

Does Calendly rely on the Data Privacy Framework or SCCs?

Both, in order. Its addendum provides that transfers out of the EU, Switzerland or the UK to the United States are governed by the applicable Data Privacy Framework, under which Calendly self-certifies, and that if a Framework is invalidated the Standard Contractual Clauses apply instead — Module 2 for controller to processor, with the UK Addendum where relevant.

Who is the controller for my invitees' data?

You are. Calendly acts as processor for the booking data you collect, which means the lawful basis, the retention period, the wording of your custom questions and the handling of any erasure request are all yours. Calendly's subprocessors are published with their processing activities and data centre locations.

Can I use Calendly for appointments involving health or other sensitive topics?

Not for collecting the sensitive detail itself. Calendly's addendum records that, per the Customer Terms, customers are not permitted to submit personal data to the Services that constitutes sensitive personal information or special categories of data. So a booking question inviting someone to describe a health condition is a contractual problem as well as a lawful basis problem. Scheduling the appointment is fine; capturing the diagnosis in a free text field is not.

Closing Thought

Scheduling tools are trusted in a way their data footprint does not really justify. Booking a call feels like an administrative act rather than a disclosure, so nobody treats the confirmation page as a privacy notice and nobody wonders where the answer to "what would you like to discuss?" ends up. It ends up in a list, indefinitely, alongside everyone else's.

The fix is not a different scheduling tool. It is deciding what your booking page asks for, how long you keep the answers, and being able to say so when someone asks. ComplyDog gives you a compliance portal on your own domain covering your DPA, your subprocessor list, your data subject request intake and your security page. It will not audit your booking questions. It will mean that when an invitee asks what you did with what they told you, there is somewhere to send them.

This article covers which version of the DPA governs you, what role Cloudflare occupies, how the transfer position is built, what the Data Localization Suite actually controls, and where the subprocessor mechanics sit.

Where The DPA Is, And Which Version Governs

Cloudflare's addendum is published at cloudflare.com/dpa, which resolves to cloudflare.com/cloudflare-customer-dpa/. The version live when we checked, on 7 August 2026, was Version 6.4, effective 3 April 2026. Version 6.3, effective 20 June 2025, is listed on the same page under previous versions — which is a neat illustration of the point below.

Two things about how it attaches are worth reading carefully. First, it forms part of your Main Agreement, whether that is an Enterprise Subscription Agreement, a Self-Serve Subscription Agreement, or another written or electronic agreement — so the same document governs a free-tier site and an enterprise deployment, with the surrounding agreement differing. Second, and more usefully, the DPA states that it replaces and supersedes any previously applicable data processing terms from the date the customer signed or otherwise agreed to it.

That supersession clause is the reason to record your DPA effective date rather than just noting that a DPA exists. Cloudflare's addendum has run through many published versions, and older ones remain findable. When a reviewer asks which terms govern, the answer is a version number and a date, not a URL.

What Cloudflare Is In Your Chain

Cloudflare's addendum sets the position that the customer is the controller or processor and Cloudflare is the processor or sub-processor as applicable, and that Cloudflare processes personal data on that basis.

What makes this different from every other vendor in this cluster is the data involved. Cloudflare sits in the request path, and its own annex spells out what that means. The data subjects are your end users — anyone accessing your domains, networks, websites, APIs and applications — plus your administrators. The categories include personal data in Customer Logs, "such as IP addresses," personal data in Customer Content, and IP addresses and email addresses in administrative audit logs.

The annex is equally direct about special categories: your end users and partners may upload content to your properties that includes them, and the extent of that is determined and controlled by you in your sole discretion. In other words, Cloudflare has written down that it does not know what is passing through, and that this is your problem to scope.

The practical consequence is that Cloudflare belongs in your Article 30 record whether or not anyone at your company thinks of it as a data tool. Every visitor's IP address is personal data, and it is being processed by a named processor on your instruction. Keeping your record of processing activities accurate means listing the infrastructure, not just the applications.

Transfers: The Data Privacy Framework, And What Sits Behind It

Cloudflare's addendum handles transfers with a definition rather than a clause, which is elegant and easy to miss. In defining what counts as a Restricted Transfer, it states that a transfer of personal data to the United States made pursuant to the Data Privacy Framework is not a Restricted Transfer at all.

Where a transfer is restricted, the addendum applies the EU Standard Contractual Clauses, with UK-protected data covered by those same clauses as amended by the UK Addendum, and conflicts between the two resolved under the Addendum's own provisions. Cloudflare's GDPR materials also point to supplementary measures and safeguards written into the addendum as contractual commitments, with its security measures set out in an annex.

Better still, the addendum makes the switchover automatic and tells you when it happens: Cloudflare undertakes to notify you if its Data Privacy Framework certification lapses or is invalidated, at which point transfers are immediately deemed Restricted Transfers and the Standard Contractual Clause provisions apply. That is a meaningfully stronger commitment than a fallback clause alone, because it does not depend on you noticing.

There is also a third mechanism most vendors do not have. Cloudflare states it is certified to the Global Cross-Border Privacy Rules System and the Global Privacy Recognition for Processors System, warrants that it will keep that certification current, and commits to telling you if it lapses. That covers transfers between participating jurisdictions outside the EU/UK frame — worth knowing if your users are not only European.

The pattern is the one worth looking for in any US vendor: a primary route, pre-agreed clauses underneath, and a duty to tell you when the top layer fails.

The Data Localization Suite, And What It Controls

This is where Cloudflare offers something genuinely unusual, and where the detail matters more than the headline.

The Data Localization Suite is a set of tools for choosing where Cloudflare inspects and stores data while still using its global network. Its documentation describes three distinct controls, and they cover different things: Geo Key Manager governs where your private encryption keys are stored, the Customer Metadata Boundary keeps traffic metadata — the logs and analytics that could identify your end users — within a region you select, and regional services govern where HTTPS traffic is decrypted and processed.

Read that as three separate questions rather than one residency switch. "Our data stays in the EU" is not a claim the Suite supports on its own; what it supports are specific answers about keys, about metadata, and about where decryption happens. If a customer asks you to warrant EU-only processing, the honest response is to say which of those three you have configured.

The Suite is a product with its own availability and commercial terms rather than a default setting, so confirm what is included on your plan before describing it to anyone else. This is the same discipline our guide to subprocessor management applies to vendor claims generally: evidence the configuration, do not assume the capability.

Subprocessors And The Authorisation You Already Gave

Cloudflare maintains its subprocessor list at cloudflare.com/gdpr/subprocessors/.

The authorisation model is broad and you agreed to it. The addendum records a general written authorisation from the customer for Cloudflare to appoint other members of the Cloudflare Group as subprocessors, and for Cloudflare and its group to appoint third-party data centre operators and business, engineering and customer support providers. In exchange, Cloudflare commits that any subprocessor is engaged only under a written contract imposing terms no less protective than its own, and that it remains liable to you for that subprocessor's breaches.

The timings are specific and asymmetric. Cloudflare commits to adding new and replacement subprocessors to the published list at least thirty days before they begin processing. Your window to object on reasonable data protection grounds is ten days from the notification. If you object and Cloudflare can reasonably provide the service without that subprocessor and chooses to, you have no further rights under the clause. If Cloudflare requires it and cannot satisfy your objection, you may terminate the applicable Order Form — but only for the services that would use the new subprocessor. And if you do not object in time, you are deemed to have consented and to have waived the right to object.

Thirty days of notice against ten days to act is the shape to plan around. Nobody reads a subprocessor page weekly, which is how a deemed consent happens by default rather than by decision.

Common Mistakes With Cloudflare And GDPR

Leaving it out of the processor inventory. Teams list their CRM and forget the layer every request passes through. Visitor IP addresses are personal data and Cloudflare processes them.

Recording "we have a DPA" without a version. The addendum supersedes prior terms from the date you agreed to it. Record the version number and effective date, because that is the question a reviewer actually asks.

Describing the Data Localization Suite as EU residency. It controls key storage, metadata location and decryption location as three separate settings, and it is a product rather than a default. Confirm what your plan includes and what is actually enabled, then warrant only that — a contractual promise outrunning the technical reality is how this goes wrong.

Reading a superseded version. Cloudflare publishes its previous versions on the same page, and older addenda are indexed and easy to find. The governing document is the version you agreed to.

Not budgeting for assistance costs. The addendum provides that you cover Cloudflare's costs for assisting with data subject requests, impact assessments and transfer assessments. Reasonable, and a surprise if you have promised a customer free-flowing support.

FAQ

Where is Cloudflare's DPA?

At cloudflare.com/dpa, which resolves to the customer DPA page. It forms part of your Main Agreement, whether that is an enterprise or self-serve subscription. The version live when we checked on 7 August 2026 was Version 6.4, effective 3 April 2026, and the addendum states that it supersedes previously applicable data processing terms from the date you agreed to it.

Is Cloudflare a controller or a processor?

Its addendum states that the customer is the controller or processor and Cloudflare is the processor or sub-processor as applicable, processing personal data on that basis. Because Cloudflare sits in the request path, the personal data involved includes the connection data and IP addresses of everyone visiting your properties.

Does Cloudflare rely on the Data Privacy Framework or SCCs?

Both, in a defined order. Its addendum provides that a transfer to the United States made under the Data Privacy Framework is not a Restricted Transfer, and applies the EU Standard Contractual Clauses to restricted transfers, with the UK Addendum amending them for UK-protected data.

Does the Data Localization Suite keep my data in the EU?

It gives you controls over three separate things: where private encryption keys are stored, where traffic metadata and logs are kept, and where HTTPS traffic is decrypted and processed. Which of those apply depends on what you have configured and what your plan includes, so describe the specific settings rather than making a general residency claim.

Closing Thought

Infrastructure is where privacy records go quiet. A team can produce a careful inventory of the tools people log into and never mention the network layer that sees every request before any of those tools do. It is not an oversight born of carelessness so much as of category: nobody experiences a CDN as a place where data is held.

Cloudflare is better documented than most vendors you will assess, which makes the gap in your own records the interesting part rather than anything in theirs. Your customers will eventually ask you the same question you should be asking here: who sees this data before we do. ComplyDog hosts a compliance portal on your own domain carrying your DPA, your subprocessor list — infrastructure included — your data subject request intake and your security page. It will not configure your network. It will mean the list is written down before somebody asks for it.

This article covers how the three deployment options change the legal picture, where the DPA is and how to get one, what the subprocessor list actually says, the capture controls worth setting, and what choosing Frankfurt does not do for you.

Three Deployment Choices, And They Change The Question

Most vendors in this category offer one architecture and a contract to paper over it. PostHog offers three.

PostHog Cloud EU runs on AWS in eu-central-1, Frankfurt. PostHog describes it as an entirely independent instance, with event data, user data and the product itself hosted on EU infrastructure, and answers the question of what is transferred from the EU to the US with a single word: none. PostHog Cloud US runs on AWS us-east-1 in Virginia. And PostHog remains self-hostable, which puts the data wherever you put it.

That matters because the hardest part of most vendor assessments is the transfer analysis, and choosing the EU region removes it rather than papering over it. Where a transfer is required from the UK, EU or EEA to PostHog's US environment, PostHog states it relies on EU Standard Contractual Clauses — but if you never make that transfer, you are not relying on anything.

Two practical notes. The regions are separate instances, so this is a decision made at setup rather than a toggle you flip later. And self-hosting moves the entire compliance burden onto you: no processor to point at, no DPA to file, and every technical and organisational measure your responsibility.

Where The DPA Is, And How To Get One

PostHog's security handbook states that it enters into data processing agreements with PostHog Cloud customers on request, links a generator for producing one, and confirms it maintains a register of every DPA it has entered into.

Note the shape of that: on request, rather than incorporated automatically. If nobody at your company has asked, you may not have one, and "we use their cloud product" is not the same as having an Article 28 contract in place. Check before a customer asks you to prove it. If you are unclear what the contract needs to contain, our guide to data processing agreements covers the required elements.

PostHog also publishes that it has assigned a data protection officer, takes privacy questions at a published address, and keeps a data processing register available to any interested party on request. Registering as a service provider rather than a controller under CCPA is stated separately. We checked these pages on 7 August 2026.

A Subprocessor List You Can Actually Read

This is the part worth showing your security reviewer. PostHog's subprocessor page, last updated 10 March 2026 when we checked, lists four entries: Amazon Web Services for cloud storage, Wiz for security vulnerability management, PlanetScale for database operations and performance monitoring, and Modal Labs for serverless compute used in isolated code execution.

Each row carries the processing location, and the locations track your region choice: US for PostHog US Cloud, Germany for PostHog EU Cloud, with the security vendor operating in Germany and France. PostHog describes keeping the list to a strict minimum, and four entries is a claim that survives contact with the page.

Four is unusual enough to be a competitive fact. When you publish your own subprocessor list — and if you process on behalf of business customers you should — a short, well-located chain is easier to defend than a long one. Our guide to subprocessors under GDPR covers what belongs on yours.

PostHog states that it posts updates to the page and gives notice in accordance with the DPA terms. Read your executed DPA for the notice period rather than assuming one.

What PostHog Captures, And What You Can Turn Off

PostHog's own framing is that product analytics does not require personal data to work, and that it provides controls for customers who want to minimise collection from end users.

That framing is fair but it is an invitation, not a default. PostHog's product spans insights, heatmaps, session recording and feature flags, and session recording in particular captures what happens on the page — which is where personal data arrives without anyone deciding to collect it — an email address rendered in an account header, an order reference, a support message. Masking configuration is the control, and it is applied deliberately rather than inherited.

Whether recording sessions is lawful at all, and on what basis, is a separate question from whether PostHog is configured well. Our guide to session replay under GDPR covers that analysis.

What Choosing Frankfurt Does Not Do

PostHog says this itself, plainly, and it is the most useful sentence on their site: deploying PostHog Cloud EU is not enough on its own. You still need a basis for the processing, and you still need to satisfy every other provision — including erasure.

So the EU region resolves the transfer question and nothing else. It does not establish a lawful basis for analytics. It does not obtain consent where consent is required. It does not set your retention period, identify a person across your events, or delete them on request. And it does not decide whether the identifiers you attach to events turn pseudonymous analytics into a directly identifiable profile, which is a decision you make the first time you call an identify method with an email address.

Common Mistakes With PostHog And GDPR

Assuming a DPA exists because you use the product. PostHog enters DPAs with Cloud customers on request. If nobody asked, check — an unrequested DPA is an absent one.

Treating the EU region as compliance. It settles where data rests. It says nothing about your lawful basis, your retention or your erasure path, and PostHog says so on its own site.

Choosing the region late. The clouds are separate instances. Decide before you have a year of events in the wrong one.

Identifying users out of habit. Attaching an email address to every event converts an analytics dataset into a personal-data store with your name on it. Decide whether you need the identifier before you send it.

Forgetting that self-hosting removes the processor. Running it yourself is a legitimate answer to the transfer question and a complete transfer of responsibility. There is no vendor to name and no security measures but yours.

FAQ

Does PostHog offer EU data residency?

Yes. PostHog Cloud EU runs on AWS in Frankfurt, Germany, and PostHog describes it as an entirely independent instance where the data and the product are hosted on EU infrastructure. PostHog Cloud US runs in Virginia. The regions are separate instances, so the choice is made at setup rather than switched later.

Do I need to sign a DPA with PostHog?

PostHog states that it enters into data processing agreements with PostHog Cloud customers when requested, and provides a generator for producing one. Unlike vendors who incorporate the terms automatically, this is opt-in — so confirm one is actually in place rather than assuming it came with the account.

Who are PostHog's subprocessors?

Its published list names four: Amazon Web Services for cloud storage, Wiz for security vulnerability management, PlanetScale for database operations monitoring, and Modal Labs for serverless compute. Processing locations follow your region choice, with the US for PostHog US Cloud and Germany for PostHog EU Cloud.

Does using the EU region make my analytics GDPR compliant?

No, and PostHog says so directly. Deploying in the EU addresses where data is stored and processed. You still need a lawful basis, consent where consent is required, a retention period, and a working process for erasure and other data subject rights.

Closing Thought

There is something clarifying about a vendor that tells you their product will not make you compliant. Most marketing pages in this category work hard to leave the opposite impression, and the result is teams who believe a procurement decision discharged a legal obligation.

The choice PostHog offers is real and worth taking seriously — few vendors let you remove the transfer question entirely. But it removes one question out of six, and the other five are about what you collect, why, for how long, and what happens when someone asks you to stop. ComplyDog gives you a compliance portal on your own domain covering your DPA, your subprocessor list, your data subject request intake and your security page. It will not configure your masking rules. It will mean that the answers you worked out once are somewhere a customer can read them.

This article covers how to get that signed copy, how the transfer position is structured, the subprocessor notice window, and the question that matters most and gets asked least: what your zaps are actually moving, and to whom.

The DPA Is Automatic, And A Signed Copy Is Self-Serve

Zapier's addendum lives at zapier.com/legal/data-processing-addendum. The version live when we checked, on 7 August 2026, was updated 1 April 2026 and effective 7 April 2026.

Zapier's own wording is that because its Terms of Service already incorporate the DPA, you do not need to sign a separate copy. Then it does something most vendors in this cluster do not: it states that if you need a standalone copy for your records or other compliance purposes, you can generate an electronically signed one. Zapier documents the flow — two emails from Zapier Dropbox Sign, the first requesting signature, the second confirming and carrying a fully signed PDF.

If you have ever lost a week to a buyer who would not accept "it is in the terms," that is the feature to know about. It costs nothing and it produces the artefact procurement asks for. Note the flip side, also stated by Zapier: it cannot sign DPAs issued by other companies, so if your customer sends you their paper expecting you to flow it down, that is not a route Zapier offers.

Worth knowing on the same theme: Zapier states it has appointed EU and UK representatives, which is the Article 27 mechanism that gives European individuals and supervisory authorities a contactable point inside their own jurisdiction.

Transfers: The Data Privacy Framework, With SCCs Behind It

Zapier states that it has certified compliance with the EU-US Data Privacy Framework, the UK Extension and the Swiss-US Framework, and points readers to the Data Privacy Framework Program participant list to confirm it — advice worth taking, since certification is a status that can lapse and the register is public.

The structure of the addendum is the interesting part. Clause 10.2.1 uses the Data Privacy Framework as the primary route for receiving European data in the US. Clause 10.2.2 then provides that if the Framework is invalidated, or does not cover a particular transfer, the applicable Standard Contractual Clauses are incorporated by reference automatically — controller-to-processor where Zapier acts as your processor, processor-to-processor where it acts as your subprocessor, plus the Swiss amendments, the UK Addendum, and Brazilian clauses for LGPD transfers.

That is a belt-and-braces design and it is worth understanding rather than skimming, because the Framework's durability has been questioned since it was adopted. A vendor whose transfer position collapses if the Framework falls is a vendor with a problem. One with pre-agreed fallback clauses is not. When you write your transfer impact assessment, the fallback structure is the fact to record.

Zapier's published transfer documentation states that it stores and processes personal data in the United States, and that data is also stored with its subprocessors. Its addendum contemplates processing in the US and other jurisdictions where Zapier and its subprocessors operate. If you have seen claims about EU data residency options, treat them as something to confirm directly with Zapier for your plan and get in writing, rather than as an established fact.

Subprocessors And The Fourteen-Day Window

Zapier maintains a subprocessors page listing each subprocessor and the locations where processing happens, and offers change notifications through its trust centre.

The current addendum sets out the mechanics at clauses 9.4 and 9.5: Zapier gives fourteen days' advance written notice of an update to the subprocessor list, by email, posting, portal notification or other reasonable means, and you may notify Zapier within fourteen days of that notice that you do not consent, on reasonable data protection grounds, after which the parties discuss the concerns in good faith.

One caution that applies to any vendor and bit us while researching this article. Older copies of Zapier's addendum are still findable and still hosted, and they set the objection window at ten business days rather than fourteen days. Ten business days and fourteen calendar days are different periods, and the older documents are not the current agreement. Always read the version on the live legal page and record its effective date — our guide to subprocessor management covers building that check into a routine.

What Zapier Is In Your Chain, And What It Is Not

Under a normal deployment you are the controller and Zapier is the processor, and its documentation describes processing personal data governed by European law on behalf of its customers. Where you are yourself a processor for your own customers, Zapier is your subprocessor — its addendum explicitly contemplates that arrangement in its transfer clauses.

That allocation carries the usual consequence for data subject requests: as controller, responding is your obligation, and the operational work of finding, exporting and deleting one person's data across your zaps and their destinations falls to you. Check the request-handling clause in the current version of the addendum rather than an older copy, for the reason set out above.

The Part Nobody Reads: A Zap Is A Transfer

Here is the thing that makes Zapier different from every other tool in this cluster, and it has nothing to do with Zapier's paperwork.

Zapier is not primarily a place where data rests. It is a mechanism for moving data between other people's systems. Every zap you build is a data flow from one processor to another, created by someone in your organisation, usually in a few minutes, usually without a review.

That has three consequences. Your Article 30 record needs to describe the flows, not the tool — "we use Zapier" says nothing, while "form submissions containing name and email pass from our form provider to our CRM and to a spreadsheet" describes a processing activity. Zapier's DPA covers Zapier's leg of the journey and does nothing for the destination, so a zap that drops personal data into a service you have no DPA with has created a gap that Zapier's compliance cannot close. And zaps built by whoever needed them accumulate: the person who built it leaves, the zap keeps running, and personal data keeps arriving somewhere nobody is reviewing.

Auditing your zaps is the single highest-value hour in this article, and your record of processing activities is where the results belong.

Common Mistakes With Zapier And GDPR

Not generating the signed copy. Zapier will produce an electronically signed standalone DPA on request. Teams spend days arguing that incorporation by reference is sufficient when a two-minute self-serve flow ends the conversation.

Reading an old version of the addendum. Superseded copies remain online and set a different subprocessor objection period. Read the version on the live legal page and record its effective date.

Documenting the tool instead of the flows. "We use Zapier" is not an entry in a processing record. Each zap moves specified categories of data between named systems, and that is the thing to describe.

Assuming Zapier's DPA covers the destination. It governs Zapier's processing. If a zap delivers personal data to a service you have no agreement with, that gap is yours.

Leaving orphaned zaps running. Automations outlive the people who built them. Review who owns each one and switch off the ones nobody can justify.

FAQ

Do I need to sign a DPA with Zapier?

No. Zapier states that its Terms of Service already incorporate its data processing addendum, so no separate signature is required. If you need a standalone executed copy for your records or for a customer's procurement process, Zapier lets you generate an electronically signed version, delivered as a signed PDF by email.

Does Zapier rely on the Data Privacy Framework or Standard Contractual Clauses?

Both, in a defined order. Zapier states it has certified to the EU-US Data Privacy Framework, the UK Extension and the Swiss-US Framework, and uses that as the primary route. Its addendum then incorporates the applicable Standard Contractual Clauses automatically if the Framework is invalidated or does not cover a given transfer.

How much notice does Zapier give before adding a subprocessor?

The current addendum provides fourteen days' advance written notice of an update to the subprocessor list, and gives you fourteen days from that notice to say you do not consent on reasonable data protection grounds, after which the parties discuss it in good faith. Older published copies state a different period — check the live version.

Where does Zapier process my data?

Zapier's published transfer documentation states that it stores and processes personal data in the United States and with its subprocessors, and its addendum contemplates the US and other jurisdictions where Zapier and its subprocessors operate. Its subprocessors page lists processing locations. Confirm anything you have heard about regional options directly, for your plan, in writing.

Closing Thought

Automation platforms are the quietest source of compliance drift in a small SaaS, because building a zap does not feel like a decision. Nobody convenes a review to connect a form to a spreadsheet. But every one of those connections is a route by which personal data leaves a system you documented and arrives in one you did not, and they are built by the people furthest from the privacy conversation, which is exactly why they work.

The vendor's paperwork is the easy part, and Zapier's is better than most — it will even hand you a signed copy, the same way ComplyDog hands your customers theirs through DocuSign and Dropbox Sign from a portal on your own domain. What neither can do is tell you what your zaps are moving. That is an hour with the list, and it is overdue on most teams reading this.

This article is about the vendor facts — where the paperwork actually is now, what it says about retention and transfers, and what the product captures. Whether recording your visitors' sessions is lawful in the first place, and on what basis, is a separate question with its own answer in our guide to session replay under GDPR.

Where The DPA Actually Is Now

This is the detail most write-ups get wrong, including older Hotjar pages.

Hotjar's legal overview at hotjar.com/legal/ lists the documents making up your agreement — Terms of Service, Privacy Policy, Data Processing Agreement, Acceptable Use Policy — and points the Data Processing Agreement at contentsquare.com/privacy-center/data-processing-agreement/ . That is the governing document, and the version live when we checked on 7 August 2026 was marked June 2026, v.2026.2.

Hotjar's separate GDPR commitment page still links to an older Hotjar-hosted path and still states that Hotjar does not offer the option to download or digitally sign a DPA. Treat that page as the historic position rather than the current one: it points at a location the legal hub no longer uses, which is a reliable sign it has not been revisited since the Contentsquare move. The mechanism is still incorporation rather than signature — the Contentsquare DPA states that by entering into the agreement the customer is deemed to have signed the incorporated Standard Contractual Clauses — but if a buyer demands a countersigned document, ask Contentsquare rather than assuming the old answer holds.

The same legal page names the contracting entity precisely: Hotjar Limited, a private limited liability company registered under the laws of Malta, company number C65490. That is the detail to put in your vendor register, not "Hotjar."

Hotjar's guidance on the related questions remains useful: one agreement covers multiple sites on the same account, and for agencies the agreement sits with whichever entity actually accepted the Terms of Service.

Hotjar Is Part Of Contentsquare Now

Hotjar's own site carries a banner stating that Hotjar is now part of Contentsquare, and the practical evidence is all over the surface: sign-in and sign-up route to Contentsquare domains, pricing points at Contentsquare, and the trust centre for Hotjar sits on Contentsquare's trust site.

The paperwork has followed. In Contentsquare's DPA, the Hotjar products sit inside the Voice of Customer schedule, which covers products "also licensed under the names Hotjar, Ask, Engage or Observe." That single line is what connects the tool you installed to the contract that governs it, and it is the reason a search for "Hotjar DPA" sends most people to a stale page.

So your subprocessor list, your processing locations and your security documentation now live on Contentsquare's privacy centre and trust portal rather than Hotjar's. Before your next customer questionnaire, confirm which entity you contract with, and update the URLs in your records. Corporate changes are one of the standard triggers for revisiting a processor record, and this is a live example — our guide to subprocessor management covers what a change of this kind should prompt.

The Dual Role: Processor For Your Visitors, Controller For You

Both documents set out the same split, and the second half gets missed.

For your end users' personal data — the visitors whose sessions and interactions are captured — you are the controller and the vendor is the processor. Hotjar's own guidance says exactly that, and the Contentsquare DPA repeats it at clause 2.1, adding that Contentsquare may also process customer data as a controller in its own right under its services privacy policy.

That split is normal and most vendors have it. It matters in your records because the two halves route differently. Questions about visitor data come to you and are governed by the DPA. Questions about your own account data are answered by the vendor as a controller.

One mechanism worth locating before you need it: the Contentsquare DPA directs customers to forward data subject requests through a dedicated data subject request portal, and commits Contentsquare to referring any request it receives directly back to you. Find that portal now rather than during a statutory deadline.

The Capture Controls To Set Before You Launch

This is where the vendor facts get useful, because Hotjar ships controls that change what is captured rather than what is stored.

The defaults are better than people assume. Hotjar states that it automatically suppresses all user keystrokes by default, which removes the single most dangerous category of capture — a visitor typing a password, a card number or a health condition into a form.

Beyond the default, Hotjar documents three product areas built for this purpose: suppression controls, which let you mark elements so their content is never captured; visitor lookup, which lets you find and act on data associated with a particular visitor; and feedback consent controls for its survey and feedback tools. Each has its own documentation in Hotjar's help centre.

Two things follow. First, defaults protect the obvious case and not yours. A page that renders an order confirmation, an account detail, an uploaded document name or an email address in the DOM is exposing it to capture whether or not anyone types. Suppression is something you apply deliberately, element by element, on the pages that need it. Second, visitor lookup is the mechanism you will reach for when an erasure request arrives, so find it before you need it rather than during a thirty-day statutory clock.

Retention, Transfers And Subprocessors

Going to the Contentsquare DPA rather than the Hotjar marketing pages answers the questions that usually go unanswered.

On retention, the Voice of Customer schedule is specific and differs by product. For surveys and feedback, customers can delete data manually at any time within the platform on a self-serve basis, and data is deleted automatically when the account is deleted. For interviews and user tests, recordings are kept for two years from the date of the session. Note that "deleted when the account is deleted" is not a retention period in the sense a regulator means — storage limitation is a decision you make and enforce, and self-serve deletion is the mechanism, not the policy.

On transfers, Contentsquare states it is certified to the EU-US Data Privacy Framework, the UK Extension and the Swiss-US Framework, with its certification checkable on the public Data Privacy Framework list, and its DPA incorporates the EU Standard Contractual Clauses in Schedule 2 as a fallback should the Framework be invalidated. Modules Two and Three both apply. The clauses are governed by French law with the courts of France as forum, and the French data protection authority named as competent supervisory authority.

On subprocessors and where data rests, both are published on Contentsquare's privacy centre subprocessors page, and you can subscribe there for advance notice of changes. The objection window is thirty calendar days from notice, by email to Contentsquare's privacy address, and silence counts as acceptance. If an objection cannot be resolved within thirty days, your remedy is to terminate the affected services with a pro-rata refund of prepaid fees — a narrower remedy than terminating the agreement, and worth knowing before you rely on it.

Common Mistakes With Hotjar And GDPR

Filing the wrong DPA. The governing document is now Contentsquare's, published on its privacy centre. Older Hotjar pages still link to a superseded location, so a vendor file built from a search result is probably pointing at the wrong document.

Assuming keystroke suppression covers everything. It covers typing. Personal data rendered on the page — order details, names, email addresses — is a separate exposure that only deliberate element-level suppression addresses.

Leaving the vendor record on the pre-Contentsquare position. The contracting entity is Hotjar Limited, Malta, company number C65490, and the subprocessor, residency and security documentation now sits on Contentsquare's privacy centre and trust portal. Update the URLs before your next security review.

Forgetting the controller half of the relationship. Hotjar is your processor for visitor data and a controller for your own account data. Requests about the second do not route through your DPA.

Treating installation as a decision. Adding the script is a two-minute job that starts collecting behavioural data about every visitor. Whether that collection is lawful, and on what basis, is decided before the script goes on — see our guide to session replay under GDPR.

FAQ

Where is Hotjar's DPA, and can I sign it?

Hotjar's legal overview points the data processing agreement at Contentsquare's privacy centre, and that published document is the governing one. It works by incorporation rather than signature — entering the agreement is deemed to be signing the incorporated Standard Contractual Clauses. Hotjar's older GDPR page says no downloadable or digitally signed DPA is offered; since that page links to a superseded location, confirm the current position with Contentsquare if a buyer requires countersigned paper.

Is Hotjar a controller or a processor?

Both, in different directions. Hotjar's documentation states that you are the controller of your end users' personal data and Hotjar is the processor of it, while for your own entity's data Hotjar is the controller. Record both halves, because they route requests differently.

Does Hotjar record what visitors type?

Hotjar states that it automatically suppresses all user keystrokes by default. That default addresses typed input. Personal data displayed on the page is not covered by it, and requires suppression controls applied to the specific elements concerned.

Where is Hotjar data stored, and how long is it kept?

Processing and storage locations are published on Contentsquare's privacy centre subprocessors page, which is where the DPA points for both. On retention, the Voice of Customer schedule covering the Hotjar products allows self-serve deletion at any time with automatic deletion when the account is deleted, and sets two years for interview and user test recordings. Confirm the specifics for the products on your plan.

Closing Thought

Behaviour analytics has an odd property: the more useful a recording is, the more of a person it contains. A session that shows nothing much is worthless, and a session that explains exactly why someone abandoned a form usually shows you what they typed, hesitated over, and corrected. The tool's value and its risk are the same property viewed from two sides, which is why the setup work is not overhead — it is the whole job.

Your customers are asking the same questions about you that this article asks about Hotjar. ComplyDog hosts a compliance portal on your own domain carrying your DPA, your subprocessor list — Hotjar included — your data subject request intake and your security page. It will not configure your suppression rules. It will mean that when a buyer asks who watches their users and where that data goes, the answer is a link rather than a week.

This article covers where the DPA actually lives, what role Notion occupies, how its subprocessor notifications work and why the AI providers on that list matter, the deletion timeline you inherit, and the obligations that stay with you.

Where Notion's DPA Is, And Why There Is Nothing To Sign

Notion publishes its GDPR position at notion.com/help/gdpr-at-notion, and links the addendum from there. Both the addendum and the subprocessor list are hosted as Notion pages on notion.so rather than as PDFs, which is charming and slightly awkward when a procurement team asks you for a document.

The mechanism is incorporation by reference. Notion's own wording is that the terms of the addendum are incorporated and apply to the extent Notion processes personal data subject to GDPR on the customer's behalf. There is no separate signature step in the self-serve flow. That satisfies Article 28(9), which permits a processing contract in electronic form, but it leaves you with the same evidence problem as every click-through arrangement: what you are bound by is the version that was live when you agreed.

The same page carries an explicit caveat from Notion that it is for informational purposes only and may be changed at any time. Take that at face value. Capture the addendum as it stands, note the date, and file it with your processor records. We checked these pages on 7 August 2026; if you are reading this later, assume the detail has moved and go and look.

If you are unsure what a processing contract is supposed to contain before you assess Notion's, start with our guide to data processing agreements.

What Notion Is In Your Data Chain

Notion's privacy documentation states the position plainly: where the customer is a controller or a processor, Notion is the processor of personal data that the customer and their users upload, processing it at the customer's direction and on the customer's behalf.

The clause worth pausing on is "and their users." A Notion workspace is not a database with a schema somebody designed. It is whatever your team has put in it. Interview notes on candidates. A spreadsheet of churned customers with reasons. A support escalation thread quoting a user's email. A performance review. None of that arrived through a form with a lawful basis attached to it, and all of it is personal data you are the controller of.

That is the practical difference between Notion and a purpose-built system. With a CRM you can describe the categories of data it holds. With Notion, the honest answer to "what personal data is in there" is usually "we would have to go and look," and that answer is not sufficient for an Article 30 record. Keeping your record of processing activities accurate means knowing what workspaces exist and roughly what lives in them.

Subprocessors, And The AI Providers On That List

Notion maintains a subprocessor list and links it from the same GDPR page. Notification is opt-in and the mechanism is manual: Notion's documentation describes customers signing up by emailing with the subject line "Subscribe to New Subprocessors," after which Notion provides notice of new subprocessors before authorising them to process customer data.

Notice before authorisation is better than most vendors offer, and an email-based subscription is easier to forget than most. Do it once and route it somewhere shared.

The list itself is the part that has changed character. Notion's trust centre discloses infrastructure providers alongside providers of large language model and embedding hosting. If your workspace has AI features in use, workspace content is reaching model-hosting infrastructure as part of normal operation, and those providers are subprocessors in your chain like any other.

This is not an accusation of anything. It is a description of an architecture, and it has two consequences you own. First, your own customers are entitled to know who is in your processing chain, which means these names may need to appear on your published list too — our guide to subprocessor management covers how far down the chain that disclosure runs. Second, "we do not use AI" is not a control. Availability of a feature and a documented decision about it are different things.

Deletion, Export And The Thirty-Day Window

Notion documents three mechanisms that matter for data subject rights.

Export works at two levels: an entire workspace can be exported from workspace settings, producing a folder of markdown, or individual pages can be exported from the page menu. That covers a portability request adequately at workspace scale and poorly at person scale, because nothing in an export is organised around an individual.

Workspace deletion is the sharper instrument. Notion documents that on requesting deletion, content immediately becomes inaccessible, and after 30 days it is deleted from Notion's servers and can no longer be recovered. Thirty days is a real window and it cuts both ways — it is your grace period if someone deletes the wrong workspace, and it is a period in which data you intended to erase still exists.

Neither mechanism gives you what an erasure request usually needs, which is the removal of one named person from the middle of hundreds of pages. That is manual work, and it is yours.

What Notion Does Not Decide For You

Notion does not set your lawful basis, your retention periods, or your access model. Workspace and page permissions are yours to configure, and the most common real-world failure is not a vendor failure at all: a page shared to the web, or a workspace where everyone can see everything because that was convenient at eight people and never revisited at forty.

It also does not tell you what is in there. No vendor can. The only way to answer a regulator's question about what personal data you hold in Notion is to have decided in advance what belongs in it.

Common Mistakes With Notion And GDPR

Looking for a DPA to sign. It is incorporated by reference and there is no signature step. Record the version and date instead of chasing a document.

Never subscribing to subprocessor notices. Notion gives notice before authorising a new subprocessor, but only to customers who opted in by email. Unsubscribed, you find out by re-reading the list.

Treating a workspace as infrastructure rather than a data store. Notion holds whatever your team put in it, including personal data nobody recorded a basis for. It belongs in your Article 30 record with an honest description.

Assuming public page sharing is internal. A page shared to the web is published. Audit what is shared externally before you audit anything else.

Confusing workspace deletion with erasure. Deleting a workspace clears everything after thirty days. Removing one person from across many pages is a manual job that no export or deletion feature performs for you.

FAQ

Do I need to sign a DPA with Notion?

No separate signature is required in the standard flow. Notion states that its data processing addendum is incorporated by reference and applies to the extent it processes personal data subject to GDPR on your behalf. Because nothing is countersigned, record which version you accepted and when, and confirm the position for your specific plan and contract if procurement needs a document.

Is Notion a controller or a processor?

A processor for the content you and your users upload. Notion's documentation states that where its customer is a controller or processor, Notion is the processor of that uploaded personal data and processes it at the customer's direction. Notion will separately be a controller of its own account and billing data about you.

Does Notion use Standard Contractual Clauses?

Yes. Notion's privacy documentation states that its data processing addendum incorporates both the EU and UK Standard Contractual Clauses, and its GDPR page describes relying on standard contractual clauses for transfers from the EU to countries outside it.

How long does Notion keep data after I delete a workspace?

Notion documents that content becomes inaccessible immediately on requesting deletion, and is deleted from its servers after 30 days, after which it cannot be recovered. That is a workspace-level operation and is not a substitute for handling an individual erasure request.

Closing Thought

The awkward thing about Notion is that it is good at the exact behaviour privacy programmes are built to prevent. It rewards putting things somewhere quickly, in whatever shape they arrive, so they are not lost. That is why teams love it, and it is why nobody can tell you what is in it.

There is no vendor setting that fixes that, and switching tools does not either — the same content would accumulate somewhere else. What helps is having a place where the answer lives: what you process, why, for how long, and who else touches it. ComplyDog gives you a compliance portal on your own domain covering your DPA, your subprocessor list, your data subject request intake and your security page. It will not index your workspace. It will mean the question of what you process has a documented answer rather than an archaeological one.

This article covers where Typeform's DPA actually is, when you would want a signed one instead, what the contract says about subprocessors and objections, the questions about storage location you should put to Typeform directly, and the controller obligations that sit with you the moment you publish a form.

The DPA Is In The Privacy Policy, Not Beside It

This is the single most common point of confusion, and it is worth stating precisely. Typeform's help centre states that Section 4 of its privacy policy contains its obligations for handling personal data under GDPR, and that as a result there is no need for customers to sign a separate data processing agreement. We checked Typeform's privacy policy and help centre on 7 August 2026; terms move, so confirm the version that applies to you before relying on it.

That is a legitimate structure. Article 28(9) permits a processing contract to be concluded in writing including in electronic form, and terms accepted electronically satisfy it. But it produces the same evidentiary awkwardness as any click-through arrangement: your DPA is a section of a document that can be revised, and what you agreed to is the version live on the day you agreed. Record the date, keep a copy of the section as it stood, and note it in your processor inventory. If you are unsure what a DPA is supposed to contain in the first place, start with our guide to data processing agreements.

Typeform's help centre also states that a custom, separately executed DPA is available on Enterprise or Growth Custom plans, arranged through its sales team. If your customers' procurement teams demand a countersigned document with your company name on it — and enterprise buyers routinely do — that plan requirement is a real cost input, not a footnote.

Who Is The Controller, And Why It Is Obviously You

Typeform's Master Enterprise Agreement is unambiguous on the point: the client is the data controller, and warrants that it will inform data subjects and obtain their consent where appropriate. That allocation is also the default position under GDPR for anyone who builds and publishes a form, so it holds regardless of which version of the agreement you are on.

Restated without the legal register: Typeform provides the machinery, you decide what to ask, who to ask, why, and on what basis. If your form asks for a phone number you do not need, that is your data minimisation failure. If it asks about dietary requirements or accessibility needs, you may be collecting special category data and you need a condition under Article 9, not merely a lawful basis under Article 6. If your form has a pre-ticked marketing checkbox, that is your invalid consent. The vendor is not in the room for any of those decisions.

The agreement also names Typeform S.L. as the contracting entity and contemplates assistance from its US affiliate, Typeform US LLC. A Spanish company is not automatically an EEA-only processing operation, and the presence of a US affiliate in the contract is the clue that transfers are in scope.

Subprocessors, Objections And The Fifteen-Day Window

Typeform provides subprocessor information through a subscription mechanism rather than an openly browsable table — you sign up and are notified when the list changes. Sign up for it. An unmonitored subprocessor list is the most common gap in an otherwise tidy vendor file.

The objection mechanics deserve a close read, and they cut in a direction most people do not expect. A published version of Typeform's Master Enterprise Agreement gives the client a non-extendable fifteen calendar days to reasonably oppose a new or replacement subprocessor — and provides that if the client exercises that right, Typeform becomes entitled to terminate the contractual relationship early on fifteen days' notice. The same clause defines "reasonably oppose" narrowly: a challenge grounded in the subprocessor's potential or actual failure to meet GDPR requirements, not a general preference.

Read together, that is a meaningful commercial fact. Objecting is not a free action. It is a right that, once exercised, hands the vendor an exit — so the decision to object belongs with someone who understands what losing the service would cost you, not only with whoever reviews the privacy paperwork.

One caution on sourcing. The clause above appears on a Typeform-hosted page that is presented as an archived version of the agreement, and enterprise terms are versioned and often negotiated. Treat it as indicative of how Typeform approaches subprocessor objections, then check the wording in the agreement you actually executed. Our guide to subprocessor management covers how to run that review without it becoming a full-time job.

On Storage Location, Get It In Writing

Here is where we stop and say what we do not know.

Typeform's transfer position is documented: the company points to the 2021 Standard Contractual Clauses for transfers, and its legal and compliance help centre section covers the DPA, the Standard Contractual Clauses and the availability of a business associate agreement. What is not settled by any single public page we could verify is where response data sits at rest for a given plan, or which plans — if any — offer an EEA-only storage option.

As of 7 August 2026, published third-party summaries disagree with each other on this point, confidently and in opposite directions. That is a good reason to trust none of them, including any summary you read of this article. If data residency matters to your customers or your risk assessment, ask Typeform's sales or support team directly, name your plan when you ask, and get the answer in writing. Then put that answer, with its date, in your records. A residency claim you cannot evidence is worse than no claim, because you will eventually repeat it to a customer.

The Embed Is Your Problem, Not Typeform's

If you embed a form in your own site rather than linking to a hosted one, the embed is a third-party resource loading inside your page, and everything it does on load happens under your cookie banner and your privacy notice.

That means the test is yours to run. Load the page in a clean browser, refuse all non-essential cookies, and look at what network requests fire and what gets written to storage before consent is given. If anything non-essential loads before the visitor has agreed, the correct fix is to gate the embed behind consent rather than to describe it in your policy afterwards. This is a configuration question about your site, and no vendor contract resolves it for you.

Common Mistakes With Typeform And GDPR

Looking for a DPA that does not exist as a separate file. It is Section 4 of the privacy policy. Teams waste a week asking support for a document, then conclude none exists.

Assuming a Spanish entity means EEA-only storage. The contracting entity is Spanish and a US affiliate appears in the agreement. Where response data rests is a question to ask, not to infer from an address.

Treating a subprocessor objection as a low-stakes tick-box. The published enterprise wording makes the window non-extendable at fifteen days and lets Typeform terminate early if you object. That is a commercial decision wearing a compliance costume — check your own executed agreement and route it to someone who can weigh it.

Collecting special category data without noticing. Health conditions, dietary needs, accessibility requirements and religious observance all appear in ordinary event and onboarding forms. Article 9 needs a condition of its own, and "the respondent typed it in" is not one.

Leaving responses in the account indefinitely. Retention is a decision you make and enforce. Nothing deletes a three-year-old response set for you, and every one of those responses is still your liability at the point somebody asks.

FAQ

Do I need to sign a DPA with Typeform?

Not on standard plans. Typeform's help centre states that Section 4 of its privacy policy contains its GDPR obligations for handling personal data and that no separate signature is required. A custom, separately executed DPA is available on Enterprise or Growth Custom plans through its sales team, which matters if a buyer insists on a countersigned document.

Is Typeform a controller or a processor?

A processor, for the responses you collect. Typeform's enterprise agreement identifies the client as the data controller and requires the client to inform data subjects and obtain consent where appropriate. It will also be a controller of its own account and billing data about you, which is a separate relationship.

Can respondents ask for their data to be deleted?

Yes, and the request is yours to handle. Responses can be deleted from the responses view of the relevant form, but the obligation to identify, verify and act on the request within the statutory deadline sits with you as controller, along with removing the same data from anywhere you exported it.

Where is my Typeform data stored?

Ask Typeform directly and name your plan. Public third-party summaries contradict each other on whether an EEA-only option exists and on which plans, so the only answer worth relying on is one you obtain from Typeform in writing and file with a date against it.

Closing Thought

Forms are where privacy programmes quietly fail, and the reason is that a form is trivially easy to make. Nobody convenes a review to add a field. Someone in marketing needs a phone number for follow-up, adds it in ninety seconds, and the organisation is now collecting a new category of personal data with no lawful basis recorded, no retention period set, and no entry in any register. The vendor's contract is immaculate throughout.

That gap is not a Typeform problem, and it is not solved by choosing a different form builder. It is solved by having somewhere that records what you collect, why, for how long and who else touches it. ComplyDog gives you a compliance portal on your own domain covering your DPA, your subprocessor list, your data subject request intake and your security page. It will not audit your forms. It will mean that when someone finally asks what you collect and on what basis, the question has an address.

This article covers where the addendum lives and whether you need to sign anything, what role Supabase occupies in your data chain, how its subprocessor notifications and region controls actually behave, the deletion and retention terms you inherit, and the obligations that stay with you regardless.

Where The DPA Is, And Whether You Have To Sign It

The addendum sits at https://supabase.com/legal/dpa. The version published when we checked, on 7 August 2026, is marked Version 1, dated 1 August 2026. Every clause cited below is from that version — a processor's terms are a moving target, so check the version number against your own records rather than assuming this article is current.

You do not sign it separately. Clause 12.2 states that accepting the agreement has the same effect as signing the Standard Contractual Clauses, which means your existing acceptance of Supabase's terms carries the Article 28 contract with it. This is normal for self-serve infrastructure and it is legally sufficient, but it has a practical consequence: there is no countersigned PDF sitting in your files. When a customer's security reviewer asks for your DPA with Supabase, you are pointing at a public page and a date, not producing a signed document. Screenshot the version and date, and record them in your processor inventory.

One detail worth noticing, because it is unusual. The contracting entity is Supabase Pte. Ltd, registered in Singapore, and it is Supabase Pte. Ltd that is named as the data importer under the Clauses. The addendum sets Irish law as governing law and the courts of Ireland as the forum. If you had assumed you were contracting with a US company under a US framework, you were not.

What Supabase Is In Your Data Chain

Clause 2 puts it plainly. Supabase is the processor, you are the controller. If you are yourself processing on behalf of your own customers, Supabase steps down a rung and acts as your subprocessor.

That second case is the one small SaaS teams get wrong. If you sell to businesses and your customers' end users are the people whose data lands in your Postgres tables, then your customers are controllers, you are their processor, and Supabase is a subprocessor you have engaged on their behalf. Your customers are entitled to know that. Supabase appearing on your own published subprocessor list is not a courtesy; it is the disclosure that makes your chain legible. Our guide to subprocessors under GDPR covers what that list needs to contain.

The addendum also constrains Supabase in ways worth quoting in a security questionnaire. Clause 3.3 prohibits it from selling your data, from sharing it for cross-context behavioural advertising, and from combining it with personal data it holds from other sources.

Subprocessors And Where Your Data Actually Sits

Supabase publishes its subprocessor list at https://supabase.com/legal/customer-resources/subprocessor-list as a dated PDF. The version live on 7 August 2026 was dated 1 June 2026.

The notification mechanism has a catch that matters. Under clause 6.3, Supabase gives at least thirty days' notice of a proposed subprocessor change — but only to customers who have subscribed to the notification form on that page. Subscribing is a thirty-second job and almost nobody does it. If you have not, the list changes and you find out when you next look. Your objection window is five days from notice, after which the parties work toward a resolution for up to thirty days, and if none is reached you may terminate the affected portion of the agreement.

On location, clause 6.1 says Supabase may process data anywhere it or its subprocessors maintain facilities. Where you direct a specific geographical region, it will store and primarily process the data in that region. Read the qualifier. Choosing an EU region at project creation is the right move if you have EU users, and it is meaningful, but "primarily" is not "exclusively" — the clause preserves room for processing elsewhere where needed to deliver the service or follow your other instructions. If a customer asks you to warrant that no data ever leaves the EEA, that is a warranty you cannot give on the strength of this clause alone.

Deletion, Retention And Breach Terms You Inherit

Three terms are worth knowing before someone asks.

On deletion, clause 11.2 gives you a thirty-day retention period after the agreement expires, during which you may request a copy of your data or export it yourself. After that window, Supabase deletes all copies held by it and its subprocessors. Thirty days is short if the person who knew about the export left.

On breach, clause 10 commits Supabase to notifying you without undue delay and, where feasible, within forty-eight hours of becoming aware of a security incident. That is faster than the standard requires of it and slower than the seventy-two hours you get for notifying a supervisory authority — so your own clock is already running when theirs stops.

On audit, clause 9.2 lets Supabase satisfy most diligence requests with certifications rather than a site visit. Its footer advertises SOC 2 Type 2, ISO 27001 and HIPAA. A physical audit is available at most once per calendar year, on thirty days' notice, at your expense.

One restriction to catch early: under Schedule 3, you may not submit data that would count as protected health information under HIPAA without first signing a separate business associate agreement with Supabase.

What Is Still Entirely Yours

Nothing above touches the questions a regulator would actually put to you.

Supabase does not decide your lawful basis, and Row Level Security policies are not a lawful basis — they are a security control. It does not set your retention periods. Schedule 3 records the retention period as the duration of your agreement unless you request earlier deletion, so nothing ages out on its own — the deleting is yours to do. It does not answer data subject requests. Under clause 7, if a data subject contacts Supabase directly, Supabase will forward the request to you and tell the person it has done so, and nothing further. Building the export and deletion paths across your tables, your storage buckets, your auth records and your logs is your engineering work.

It also does not write your Article 30 record. Supabase belongs in that record as a named processor with a purpose, a location and a retention period beside it, and keeping your record of processing activities current is a controller obligation no vendor discharges for you.

Common Mistakes When Relying On Supabase For GDPR

Treating the click-through addendum as nothing. It is a real Article 28 contract and it is enough. The failure is not signing it — it is having no record of which version you accepted when a reviewer asks.

Never subscribing to subprocessor notifications. Thirty days' notice is contractual but conditional. Without subscribing, the change happens and you learn about it later, which is exactly the gap your own customers will ask you about.

Reading region selection as a residency guarantee. The clause promises storage and primary processing in your chosen region. Warranting more than that to a customer puts you on the hook for a commitment your processor never made.

Assuming a Singapore entity is a US entity. The importer is Supabase Pte. Ltd, under Irish governing law. Any transfer impact assessment you write against the wrong jurisdiction is wasted work.

Believing deletion in your app equals deletion at rest. Soft deletes leave rows in place, and Supabase takes daily backups by default. A deletion path that ignores backups and logs is not an erasure path. Read our guide to data processing agreements for what the contract does and does not cover here.

FAQ

Does Supabase sign a DPA?

Not individually. Its data processing addendum is published at supabase.com/legal/dpa and takes effect when you accept Supabase's terms, with clause 12.2 confirming that acceptance carries the same effect as signing the Standard Contractual Clauses. Because nothing is countersigned, record the version number and the date you accepted it.

Where does Supabase store my data?

Its addendum permits processing anywhere Supabase or its subprocessors maintain facilities, and commits to storing and primarily processing in a specific region where you direct one. You choose a region when you create a project. Treat that as a strong default rather than an absolute guarantee of EEA-only processing.

Does Supabase use Standard Contractual Clauses?

Yes. Its addendum incorporates the EU Clauses from Commission Implementing Decision (EU) 2021/914, applying Module Two where you are a controller and Module Three where you are a processor, along with the UK International Data Transfer Addendum and a Swiss addendum naming the FDPIC as supervisory authority.

Who handles a deletion request from one of my users?

You do. Supabase forwards any request it receives to you and confirms to the data subject only that it has been forwarded. Building deletion across your tables, storage, auth records and backups is your work, and the thirty-day post-termination window is for your own data, not your users' requests.

Closing Thought

The interesting thing about reading a processor's addendum properly is how much of it turns out to be about you. Four clauses in, the document stops describing what Supabase will do and starts describing what it assumes you have already decided — your lawful basis, your retention periods, your consent for anything sensitive, your handling of requests. The vendor's contract is a mirror. Most teams read it looking for reassurance and find a task list.

That task list is also what your own customers will send you, in the form of a questionnaire, roughly one enterprise deal from now. ComplyDog hosts a compliance portal on your own domain carrying your DPA, your subprocessor list — Supabase included — your data subject request intake and your security page. It will not choose your lawful basis or write your deletion job. It will mean that when a buyer asks who processes their data and where, you send a link rather than starting a document.

This article covers how to extract a library from completed questionnaires, who should own it and how it gets governed, the tooling question and when a document stops being enough, how to handle the mapping problem when every buyer uses a different format, and the decay problem that quietly turns a library into a liability.

Start from what you have already answered

The instinct is to sit down and write a library from first principles. That project has a predictable arc: enthusiasm, a partial document, and abandonment when the first real deadline arrives.

Extraction works because the hard part is already done. Take your two or three most recent completed questionnaires. For each answer, ask one question: is this specific to that customer, or is it true about our company generally? Company-general answers go into the library, stripped of the buyer's phrasing and the buyer's question numbering. Customer-specific ones stay behind.

The output surprises people. A typical pair of completed assessments yields between sixty and a hundred reusable entries, which covers the substantial majority of what the next questionnaire will ask. You are not writing content; you are relocating it out of documents organised by customer into a document organised by subject.

If you have never completed one, do the CAIQ instead of writing a library from scratch. It is free, its 261 questions are a reasonable proxy for what buyers ask, and completing it produces both a publishable artifact and your first library in a single pass. Our guide to the CAIQ and the STAR Registry covers what that involves.

Structure it by subject, not by source

The organising principle that makes a library work is that entries are retrievable by what they are about rather than by where they came from.

That means no folders named after customers, and no library structured around the SIG's risk domains or the CAIQ's control domains, because the next questionnaire will use neither. Structure it around your own subject list — encryption, access control, backups and recovery, subprocessors, incident response, retention and deletion, data residency, personnel security, business continuity, secure development — and let each entry sit under a subject regardless of which framework asked about it.

Each entry needs a short answer of one or two sentences that pastes into a comment box, a longer paragraph for questionnaires expecting narrative, a pointer to the evidence that backs it, and a last-verified date. Our guide to what belongs in each entry and how to write it covers that structure in detail, including which parts belong in public and which stay internal.

Add one field that pure content guides usually omit: the questions this entry has answered. Keep the buyer's original phrasing alongside your answer. After three or four questionnaires you have a phrasebook mapping the many ways buyers ask about encryption onto the single answer you maintain, and that mapping is what lets a non-technical person answer a new questionnaire quickly.

Ownership and governance

A library with no owner decays into a liability within about a year, and the failure is silent.

One named owner. Usually whoever owns questionnaires generally — operations, customer success, or a founder at small scale. They are not responsible for knowing the answers; they are responsible for the library being current and for the review happening.

Named subject contributors. For each subject area, someone who can confirm whether an entry is still true. Usually one or two engineers covering the technical subjects and whoever handles contracts covering the legal ones.

Two update triggers. A quarterly review, in a calendar entry, working the last-verified dates oldest first. And an opportunistic update every time a real questionnaire is completed, while the corrections are visible — if a buyer's question exposed an answer that was wrong or missing, that is the cheapest moment you will ever have to fix it, and it is the one everybody skips because the deal has closed and attention has moved on.

A change signal for infrastructure. When you swap a subprocessor, change cloud regions, or re-architect something material, the library needs updating. The lightweight version of this is adding a line to your deployment or vendor-change checklist. The version that does not work is hoping someone remembers.

Tooling, and when a document stops being enough

Start with a document. A single well-structured document or spreadsheet handles most companies below roughly fifty people, and its advantages are real: everyone can edit it, nothing needs procuring, and it cannot be abandoned when a subscription lapses.

Three signals suggest you have outgrown it. Version conflicts, where two people answer questionnaires from different copies and give a buyer inconsistent answers. Search failure, where the document is long enough that people stop looking and just ask an engineer, which reintroduces the cost you built the library to remove. Volume, where questionnaires are frequent enough that manual mapping is a meaningful weekly cost.

At that point dedicated questionnaire-response tooling becomes worth evaluating, and the thing to evaluate it on is whether it improves retrieval and governance rather than whether it can auto-fill. Automated suggestions are useful and are also how a stale answer gets pasted into a live assessment with confidence. Any tool you adopt should make the last-verified date visible at the point of use.

Whatever the tool, keep the published half separate and public. The subprocessor list, DPA, retention policy, data residency, and data subject request process are not confidential, and published they answer questions before anyone asks. Our guide to subprocessors under GDPR covers the inventory that sits at the centre of that public half.

The decay problem

An answer library goes wrong in a specific and dangerous way. It does not become obviously outdated; it becomes confidently wrong.

Infrastructure changes, a vendor is swapped, a policy is rewritten, a retention period is shortened. The library says what was true eighteen months ago. Someone under deadline pastes it into a live questionnaire, because that is what the library is for, and now you have supplied an inaccurate answer to a buyer in writing — which is materially worse than the slow, uncertain answer you would have given without it.

The last-verified date is the whole defence, which is why it is worth insisting on despite being the field everyone omits. Two rules make it work. Any entry unverified for six months gets rechecked before reuse, not after. And an entry that cannot be verified gets deleted rather than kept, because an empty slot prompts a question while a stale entry prompts a paste.

This is also the argument for keeping the library smaller than feels complete. A hundred entries that are all current beats three hundred where forty are wrong and nobody knows which forty.

Common mistakes building an answer library

Starting from a blank template. Extract from completed questionnaires instead. The material exists; it is in the wrong shape.

Structuring it around one framework's domains. The next buyer will use a different format. Organise by your own subjects.

Omitting the last-verified date. It is the field that separates an asset from a liability, and it is the one most often left out.

Leaving it unowned. A library with no named owner and no review cadence is confidently wrong within a year.

Keeping stale entries "for reference." Delete what cannot be verified. An empty slot prompts a question; a stale entry prompts a paste.

FAQ

How do I build a security questionnaire answer library?

Extract it from questionnaires you have already completed rather than writing from scratch. Separate company-general answers from customer-specific ones, strip the buyer's phrasing, and file the result by subject. Two completed assessments typically yield sixty to a hundred reusable entries.

What should a security answer library contain?

For each subject, a short pasteable answer, a longer narrative version, a pointer to supporting evidence, a last-verified date, and the buyer phrasings that entry has already answered. Subjects should cover encryption, access control, backups, subprocessors, incident response, retention, residency, personnel, continuity, and development.

Do I need software for a security answer library?

Not initially. A single well-structured document serves most companies below around fifty people. Consider dedicated tooling when you hit version conflicts between copies, when people stop searching it, or when questionnaire volume makes manual mapping a weekly cost.

How often should a security answer library be updated?

Review quarterly against last-verified dates, and update opportunistically every time you complete a real questionnaire. Anything unverified for six months should be rechecked before reuse or removed.

Closing thought

The library is worth building for a reason that is easy to miss while you are in the middle of a questionnaire. It is not primarily a speed tool. It is a consistency tool. Buyers compare your answers across sections, across documents, and sometimes across years, and the failure that costs deals is not a slow response — it is two answers that cannot both be true, which turns a routine review into a set of follow-up questions asked in a different tone.

The half of the library that should not live in a document at all is the half buyers would rather look up than request. ComplyDog hosts your DPA, subprocessor list, data subject request process, and security overview on a portal at your own domain, kept current, which removes those entries from the maintenance burden entirely and turns them into a link that answers before you are asked. The internal library still needs an owner and a quarterly hour. It should just be smaller than the one you were about to build.

This article covers the difference between an answer and evidence, the six kinds of proof reviewers request and what makes each acceptable, what you should never send, how to redact properly, and how to build an evidence pack so requests take an hour rather than a week.

Answer versus evidence

Every questionnaire answer is an assertion. You are saying what you do. A completed SIG is a structured set of vendor assertions, and a STAR Level 1 CAIQ entry is a self-assessment — neither is independently verified by the act of submitting it.

Evidence is what a reviewer asks for when an assertion matters enough to check. That is not distrust; it is the job. Third-party risk exists because vendors sometimes describe an intended state rather than the current one, usually without meaning to.

Three things reliably trigger an evidence request. High impact: encryption, access control, backups, and incident response get checked more than personnel policies. Easy to overstate: anything phrased as always, all, or fully. Inconsistency: an answer that does not sit comfortably beside another one — you claimed quarterly access reviews in one section and annual in another, so now both get checked.

The practical implication is that the questions you were tempted to answer generously are exactly the ones most likely to be examined.

The six kinds of evidence

Configuration exports and screenshots. The most common request for technical controls. Your identity provider's MFA enforcement policy, your cloud storage encryption settings, your password policy, your logging configuration. What makes these acceptable is that they are system-generated rather than described: a screenshot of the actual setting, showing the date, beats a sentence saying the setting is enabled.

Policy documents. Information security, access control, incident response, acceptable use, business continuity. Reviewers check three things — that it exists, that it has a version and a review date, and that it says what you said it says. A policy last reviewed in 2022 is a finding even if its contents are perfect.

System-generated reports. Access review exports, vulnerability scan results, backup completion logs, patch status reports. These carry more weight than anything narrative because they were produced by a system rather than a person. An access review export with a date and a reviewer name is close to unarguable.

Third-party attestations. SOC 2 reports, ISO 27001 certificates with scope and Statement of Applicability, penetration test summaries, your cloud provider's own compliance documentation. The strongest form, because someone independent checked.

Records and tickets. Evidence that a process ran, not just that it exists. An incident ticket showing detection, escalation, and resolution. An onboarding checklist. A change approval record. This category is what separates a documented process from a practised one, and reviewers increasingly ask for it specifically.

Contracts and agreements. DPAs with your subprocessors, confidentiality agreements, and your own customer-facing DPA. Buyers assessing your vendor chain want to see that the obligations you accepted have been passed down. Our guide to GDPR subprocessor management covers the contractual chain reviewers are looking for here.

What makes evidence acceptable

Four properties, and most rejected evidence fails on one of them.

It is dated, and recently. Undated evidence proves nothing about the present. Most reviewers work to a twelve-month window and a shorter one for anything operational.

It is system-generated where possible. A configuration export outranks a description. A description outranks a promise.

Its scope is visible. A vulnerability scan covering one repository is not evidence about your estate. State what the evidence covers, because a reviewer who has to guess will assume the narrow reading.

It matches the claim. The commonest failure is evidence that is adjacent to the question. Asked for proof of quarterly access reviews, vendors send their access control policy — which proves they intend to do reviews, not that reviews happened. The policy answers "do you have a process." The export answers "did you run it."

What never to send

Full penetration test reports without careful thought. They contain exploitable detail. An executive summary with dates, scope, tester, severity counts, and remediation status is standard and accepted.

Anything containing customer data. Screenshots of production systems showing real records are a data protection incident, not evidence. Use a test tenant or redact thoroughly.

Credentials, keys, tokens, or internal hostnames. These appear in screenshots more often than people expect. Check the whole image, including browser tabs, notification banners, and terminal scrollback.

Named individuals beyond what is necessary. Access review exports listing every employee with role and email are frequently sent unredacted. Redact to what the reviewer actually needs.

Raw architecture detail that maps your attack surface. A logical data flow diagram is appropriate; a network diagram with internal IP ranges is not.

Redaction has its own trap: black rectangles drawn over text in a PDF frequently leave the text underneath extractable. Flatten the image or export to a format that discards the original layer, then reopen the file and try to select the redacted text before sending it.

Building the pack before you need it

Evidence requests are predictable, which means the pack is buildable in advance. Assemble a folder covering the controls that get checked most: encryption settings, MFA enforcement, access review output, backup and restore verification, vulnerability scanning, incident response records, and your policy set. For each item, store the artifact, the date it was captured, and a one-line note on what it demonstrates.

The item almost everyone is missing is restore verification. Reviewers ask when you last tested a restore, and "we back up nightly" does not answer it. Running a restore test once and keeping the record makes an otherwise awkward question routine.

Refresh the pack quarterly. Stale evidence is worse than none, because it will be sent with confidence and then dated by the reviewer. Our guide to running a GDPR compliance audit covers the same discipline applied to privacy documentation, where the evidence expectations increasingly mirror security ones.

Common mistakes with security evidence

Sending the policy when asked for the record. A policy proves intent. An export proves execution. Reviewers asking for evidence usually want the second.

Sending undated artifacts. Evidence without a date establishes nothing about the current state.

Redacting badly. Black boxes over PDF text often leave the text selectable. Flatten, then verify before sending.

Screenshotting production with real customer data. That is an incident, not evidence. Use test data or redact fully.

Letting the pack go stale. Quarterly refresh, or you will send twelve-month-old configuration exports with confidence.

FAQ

What evidence do buyers ask for in a security review?

Most commonly configuration exports or screenshots for technical controls, policy documents, system-generated reports such as access reviews and scan results, third-party attestations like SOC 2 or ISO 27001, records showing a process actually ran, and contracts including subprocessor DPAs.

Do I have to provide evidence for every questionnaire answer?

No. Evidence is typically requested on a minority of answers — the high-impact controls, anything phrased in absolutes, and anything that appears inconsistent with another answer. A well-organised evidence pack covering the common ones handles most requests.

Can I refuse to share security evidence?

You can decline specific items and frequently should, particularly full penetration test reports, anything containing customer data, and detailed network topology. Decline with a reason and an alternative — an executive summary, a redacted export — rather than a flat refusal.

How recent does security evidence need to be?

Most reviewers work to a twelve-month window for attestations and penetration tests, and expect operational evidence such as access reviews and scan results to be considerably more recent, typically within the last quarter.

Closing thought

The distinction worth internalising is between documenting a control and demonstrating it. Most small companies are reasonably good at the first and have never been asked for the second, which is why the evidence request rather than the questionnaire is where reviews slow down. The questions can be answered from knowledge. The evidence has to be found.

A meaningful share of what gets requested is data protection rather than security engineering — subprocessor DPAs, your customer-facing agreement, deletion and retention records, how data subject requests are actually handled. ComplyDog keeps those maintained and published on a portal at your own domain, which means that portion of an evidence request is answered by a link to a live page rather than a search through a shared drive. The configuration exports still have to come from your systems. They should just be the only part you have to go looking for.

This article covers realistic ranges by scenario, where the time actually goes phase by phase, the three things that consume far more of it than people expect, why the second questionnaire is so much cheaper, and how to give a buyer a date you can hold.

Realistic ranges

Treat these as planning estimates rather than promises. The spread is wide because the inputs vary enormously.

Short questionnaire, existing documentation. Thirty to eighty questions, answers already written down. One to two days of one person's time, plus a short engineering session.

Standard assessment, first time. A hundred to two hundred questions with no prior answer bank. Two to three weeks elapsed, perhaps five to eight person-days of actual work spread across three or four people. Most of the elapsed time is waiting rather than working.

Core-tier assessment, first time. Several hundred questions expecting narrative answers, plus a document pack. Three to five weeks elapsed. This is the scenario that surprises people, and it is worth naming as a risk to the deal owner early.

Repeat assessment with a maintained answer library. Two to four days regardless of length, because the work has become mapping rather than research.

Vendor portal with no bulk import. Add thirty to fifty percent to any of the above. Web forms that cannot be drafted offline, do not save reliably, and require answers to be pasted one field at a time are a real and frequently underestimated tax.

Where the time goes

Five phases, in the order they happen.

Triage — one to two hours. Read the whole questionnaire, count the questions, sort them by who can answer, identify the document requests, establish the real deadline. Skipping this is what turns a bounded task into an open-ended one.

Transcription — the largest block, and the least skilled. Roughly half of a typical assessment is writing down things that are already true and already known. This is where a non-technical owner does most of their work, and it is the block that shrinks most dramatically on repeat questionnaires.

The engineering session — ninety minutes to three hours. The flagged questions that require judgment. This should be a scheduled block with someone else typing, not an assignment. Run as an assignment, this phase alone routinely consumes two to three weeks of elapsed time.

Evidence gathering — days of elapsed time, hours of work. Requesting documents from vendors, locating policies, pulling configuration exports, getting an insurance certificate reissued. Almost none of this is your effort and almost all of it is calendar time, which is why it has to start on day one.

Review and return — two to four hours. Reading the whole thing for internal consistency, checking that no answer contradicts another, and packaging it. Genuinely worth doing, because contradictions are what reviewers catch and escalate into a second round.

The three things that take longer than expected

Finding evidence. Reviewers ask for backing on perhaps a fifth of answers, and the delay is almost never writing the answer — it is locating the document, the screenshot, or the vendor certificate that proves it. A team that knows exactly where its subprocessor DPAs live answers in an hour. A team that does not spends three days emailing vendors.

Waiting on other people. Your cloud provider's compliance documentation, your insurer, your penetration testing firm, the contractor who set up your monitoring two years ago. Every one of these is a multi-day round trip you do not control.

Deciding what an answer means. Questions like "is all data encrypted at rest" look binary and are not, once you consider backups, logs, search indexes, and analytics pipelines. The honest answer requires a conversation, and that conversation is genuinely valuable, but it is not fifteen seconds of work. Expect a handful of these in any real assessment.

Why the second one is so much faster

Because the expensive part of the first questionnaire is not answering questions. It is discovering, in writing, what your company actually does — often for the first time.

That discovery does not have to be repeated. What has to happen is that the output gets stored somewhere retrievable by topic rather than by customer. A completed workbook filed under a client name is a document you will never open again; the same answers organised by subject turn the next questionnaire from research into retrieval, which is a task a non-technical person completes at speed.

The multiplier is large. Teams that maintain an answer library commonly report repeat questionnaires taking a fifth of the time of the first, and the reason is arithmetic rather than skill: the transcription block collapses, the engineering session shrinks to a handful of genuinely new questions, and evidence gathering becomes a matter of checking dates. Our guide to building a reusable answer library covers how to construct one from the questionnaires you have already completed.

The other half of the saving comes from publishing. Anything sitting at a public URL — your DPA, subprocessor list, retention policy, security overview — is an answer supplied as a link rather than a paragraph, and one the buyer can verify without asking you.

Giving a date you can hold

Four rules.

Do not quote before you triage. An hour of sorting tells you whether this is two days or three weeks. Committing first and discovering after is how vendors miss dates on deals that were going well.

Ask what the real deadline is. The stated date is frequently an analyst's internal target rather than a hard stop. Asking for an extra week at the start is trivially easy and costs nothing; asking on the due date costs credibility.

Quote elapsed time, not effort. "Five days of work" means nothing to a buyer waiting on a calendar. Give them a date, and build in the evidence-gathering delays you do not control.

Add a buffer for the second round. Anything larger than a Lite generates follow-up questions. If the deal timeline assumes submission is the end, the deal timeline is wrong.

Common mistakes estimating questionnaire time

Quoting a date before opening the file. Length, tier, format, and document requests all vary per buyer. Triage first.

Estimating effort instead of elapsed time. Most of the calendar is waiting on vendors and on scheduling, not typing.

Treating the engineering block as an assignment. As an assignment it takes weeks. As a scheduled session with someone else typing, it takes hours.

Forgetting the document pack. Insurance certificates, vendor attestations, and penetration test summaries have lead times you do not control. Start on day one.

Assuming submission ends it. Follow-up questions are normal on anything substantial. Budget for a second round.

FAQ

How long does it take to complete a security questionnaire?

A first assessment of one to two hundred questions typically takes two to three weeks of elapsed time and five to eight person-days of work. With a maintained answer library, the same questionnaire is usually two to four days.

Why do security questionnaires take so long?

Most of the time is not spent writing answers. It goes on locating evidence, waiting for documents from vendors and insurers, scheduling engineering time, and resolving questions where the honest answer requires a decision rather than a fact.

Can I ask a buyer for more time on a security questionnaire?

Yes, and the stated deadline is often an internal target rather than a hard requirement. Ask at the start rather than at the end — an early request for two extra weeks is routine, while a request on the due date is remembered.

How can I complete security questionnaires faster?

Triage before answering, run engineering time as a scheduled session rather than an assignment, start evidence gathering on day one, keep answers organised by topic rather than by customer, and publish the non-sensitive portion so it can be supplied as a link.

Closing thought

The honest framing for a founder is that the first questionnaire is a one-time cost being charged to a specific deal. It feels disproportionate because it is: you are paying to document your entire security and privacy posture, and the invoice happens to arrive attached to one customer. That is genuinely unfair to that deal and genuinely useful to the company.

What determines whether you pay it again is entirely down to where the answers end up. ComplyDog keeps the recurring half — DPA, subprocessor list, data subject request handling, security overview — published and current on a portal at your own domain, so the next questionnaire opens with a section already answered and a buyer who can check it without emailing you. The first one will still take two weeks. The fourth one should not.

This article covers why the technical-owner instinct fails, the three ownership models and where each breaks, the accountability split that works at small scale, how the arrangement should change as you grow, and the specific trigger for hiring or outsourcing the function.

Why the technical owner fails

The reasoning is intuitive: it is a security questionnaire, so give it to the person who understands security. It fails for a structural reason rather than a personal one.

The work is roughly eighty percent coordination and twenty percent technical judgment. Coordination means chasing answers from three people, tracking what is outstanding, requesting documents from vendors who reply slowly, keeping the buyer updated, assembling the evidence pack, and getting the thing returned by a date. Technical judgment means deciding what a control actually does in your architecture and which answers carry risk if overstated.

Your senior engineer is uniquely valuable for the twenty percent and no better than anyone else at the eighty. Worse, they are the person most likely to be pulled into an incident mid-task, and questionnaires punish interruption badly — every return costs context reload on a document with two hundred rows.

The observable symptom is a questionnaire that sits at seventy percent for two weeks. Not blocked, not abandoned, just never the most urgent thing on an engineer's list. For questionnaire purposes, seventy percent complete on the due date is zero percent complete.

The three models, and where each breaks

Founder-owned. The founder runs the document, pulls answers from whoever has them, and writes the commercial framing themselves. This works well below roughly fifteen people and is often the fastest option, because the founder has both the full picture and the authority to interrupt people. It breaks on volume. When questionnaires become monthly rather than occasional, the founder is spending several days a month on document assembly, which is close to the worst possible use of that time.

Operations or customer-success owned. Someone in ops, CS, or sales ops owns the coordination and escalates technical questions. This is the right answer for most companies between roughly ten and fifty people. It breaks when the owner has no authority to get engineering time — if the flagged questions sit in a queue behind product work with nobody able to prioritise them, the model produces a well-coordinated document that is missing its hardest answers.

Engineering-owned. An engineer or engineering manager owns the whole thing. This is the most common arrangement and the one that fails most often, for the reasons above. It works in exactly one situation: when the engineer genuinely wants it, treats it as a defined responsibility with allocated time, and is not also on call for production.

There is a fourth non-model worth naming because it is so common: shared ownership, where the questionnaire belongs to a channel and everyone helps. This is not a model. It is the absence of one, and it reliably produces documents that are eighty percent finished at the deadline.

The split that works

Name two roles explicitly, in writing, in the first day.

The owner is accountable for the questionnaire being returned by an agreed date. They triage on arrival, sort the questions, run the document, gather supporting documents in parallel, chase, review for consistency before submission, and handle all buyer communication. They do not need deep security knowledge. They need to be organised and to have the standing to ask for people's time.

The technical contributor answers only the flagged questions requiring judgment — typically twenty to forty out of two hundred — in one or two bounded sessions. They are not accountable for the document, do not chase anyone, and do not attend buyer calls unless the buyer asks a technical question.

Two supporting roles usually matter. Someone with authority — a founder or department head — needs to be able to unblock engineering time when the contributor's session slips. And someone should review the completed document for internal consistency before it goes out, because contradictions between sections are what reviewers catch and escalate. The reviewer should not be the person who wrote the answers.

Write these names down. An arrangement everybody understands in principle and nobody has written down is shared ownership wearing a disguise. Our guide to answering a security questionnaire without a security team covers how to run the technical contributor's session so it takes ninety minutes rather than three weeks.

How this changes as you grow

Under ten people. Founder owns it. Nothing else is worth the coordination cost, and there is no volume to justify a process.

Ten to thirty. Move ownership to operations or customer success, keep engineering as a named contributor, and start the answer library. This is the transition most companies delay too long, usually until a founder misses a deadline on a large deal.

Thirty to eighty. Ownership consolidates into a defined role, often within a broader compliance or revenue operations remit. This is typically when a formal answer library, a document repository, and a published portal stop being nice ideas and start being load-bearing.

Beyond eighty. Dedicated security or compliance headcount, and the questionnaire function becomes part of a wider trust programme rather than a per-deal task.

The transitions are triggered by volume, not headcount. A twenty-person company selling into financial services can hit enterprise-level questionnaire load years before a sixty-person company selling to startups.

When to hire or outsource

The trigger is measurable rather than a feeling. Track two numbers for a quarter: how many questionnaires you received, and how many engineering hours went into them.

If engineering time is consistently over roughly one day per month on questionnaires, the answer is usually not to hire but to build the answer library, because most of that time is re-answering questions somebody already answered. Fix that first; it is cheap and it typically removes most of the load.

If the volume is still high after the library exists, the question becomes whether the remaining work is coordination or judgment. Coordination scales with a hire or a contractor and does not require security expertise. Judgment does not outsource well, because the bottleneck is knowledge of your own systems, which an external party does not have — which is why a consultant hired to answer your first questionnaire mostly interviews your engineers and charges you for it.

The other honest trigger is deal size. If a single enterprise deal is worth more than a quarter of a person's salary and the security review is the gating item, the arithmetic answers itself.

Common mistakes in questionnaire ownership

Handing the whole document to an engineer. Eighty percent of the work is coordination, which is not their skill and not their best use.

Leaving ownership implicit. If nobody's name is written against it, it belongs to everyone, which means it stalls at seventy percent.

Making the owner someone with no authority to get engineering time. The flagged questions will sit behind product work indefinitely.

Having the same person write and review. Contradictions between sections are what reviewers catch. The reviewer needs fresh eyes.

Hiring before building the library. Most questionnaire load at small companies is repeated work. Fix the repetition before adding a person to absorb it.

FAQ

Who should fill out security questionnaires at a startup?

Coordination should sit with whoever is accountable for the deal — usually a founder below fifteen people, and someone in operations or customer success above that. Your most senior engineer should answer only the flagged questions requiring technical judgment, in bounded sessions.

Should engineers answer security questionnaires?

They should answer the subset that requires judgment about how your systems actually work, which is typically ten to twenty percent of the questions. They should not own the document, chase contributors, or manage the deadline.

Do I need a dedicated compliance person for security questionnaires?

Rarely below fifty people. Build a reusable answer library first, since most questionnaire load at small companies is re-answering the same questions. Hire when volume remains high after the library exists and the residual work is coordination rather than judgment.

How do I stop security questionnaires from blocking engineering?

Name a non-engineering owner, sort the questions before anyone starts answering, and give engineering a bounded list in a scheduled session rather than the whole document. Then capture the answers so the next questionnaire draws on them.

Closing thought

The reason ownership matters more here than in most internal processes is that a questionnaire has an external deadline, an audience that reads carefully, and a deal attached. Almost every other partially-finished internal document can wait a week. This one cannot, and the failure is invisible until it is not — the document looks nearly done right up until the day it is late.

Ownership gets considerably lighter when the recurring answers live somewhere permanent rather than in whoever last did one. ComplyDog puts your DPA, subprocessor list, data subject request process, and security overview on a hosted portal at your own domain, so the owner is assembling rather than researching, and so the arrangement survives that person leaving. The judgment questions still need your engineer. Everything else should not depend on a single memory.

This article covers the nine documents buyers most commonly request, what each one actually is, why a reviewer wants it, what to send when you do not have it, and the specific traps in each — including the two documents most often requested and most often missing at companies under twenty people.

The attestations

SOC 2 report. The most requested document in US enterprise procurement. It comes in two forms and the difference matters: a Type I report assesses whether your controls are designed appropriately at a single point in time, while a Type II assesses whether they operated effectively over a period, typically several months to a year. Buyers who know the difference want Type II. If you have a Type I, say which you have rather than sending it labelled as "our SOC 2" and letting them discover it.

Send the full report under NDA, not the marketing summary. Reviewers read the exceptions section, and a vendor who supplies only a one-page badge signals they would rather the exceptions were not read.

If you have neither, say so plainly and describe the compensating position: what controls you run, what evidence you can supply directly, and whether an audit is genuinely planned. A stated Q3 date that slips is worse than no date.

ISO 27001 certificate. Sought more often by European and international buyers. Three things get requested together and vendors usually send only the first: the certificate itself, the scope statement, and the Statement of Applicability. The scope matters because a certificate covering only your London office says nothing about the product; the SoA matters because it lists which Annex A controls you applied and which you excluded, with justification. A reviewer asking for the SoA is asking what you left out.

Note that ISO 27001:2022 restructured Annex A, so a certificate issued against the older revision will look different from a current one. That is normal during a transition and worth a sentence of explanation rather than leaving the reviewer to wonder.

Penetration test report. Usually the most recent one, within twelve months. Most vendors send an executive summary rather than the full report, which is standard and accepted — the full document contains exploitable detail and reasonable buyers do not expect it. What they do expect is the date, the scope, the tester, the severity counts, and evidence that findings were remediated. A summary showing three high-severity findings and a remediation letter reads considerably better than a summary showing zero findings, which mostly signals a narrow scope.

The contracts and lists

Data Processing Agreement. Requested whenever the buyer has EU customers or operates under GDPR, which is most B2B software buyers of any size. They want your standard DPA, and increasingly they want to see it before legal review rather than during. Our guide to what a DPA is and what it must contain covers the required clauses; if you are drafting one, the DPA template guide is a reasonable starting point.

The trap is having a DPA that exists as a Word document someone drafted in 2023 and which nobody can find. If the request takes you three days to answer, that is three days visible to the buyer.

Subprocessor list. Every third party that touches customer data, what each processes, and where it sits. This is one of the two documents most commonly requested and most commonly missing at small companies, and it is entirely within your control to fix. Buyers increasingly want it published rather than emailed, along with a mechanism for notifying customers of changes. Our guide to subprocessors under GDPR covers what belongs in the inventory and the notification obligations attached to it.

Certificate of cyber liability insurance. Frequently requested by procurement rather than security, often with a minimum coverage figure attached. It is a quick win when you have it and a slow one when you do not, because binding a policy takes weeks. Worth checking your coverage limits before a deal depends on them.

The internal documentation

Security policies. Typically information security, access control, and incident response, sometimes also acceptable use and business continuity. The common trap is claiming policies you do not have in document form. If your access control policy is four paragraphs in a shared document, send those four paragraphs. A short real policy is defensible; a claimed policy that does not exist collapses the moment a reviewer asks for it.

Architecture or data flow diagram. What the system looks like, where personal data enters, where it is stored, which third parties it reaches, and where it crosses borders. Many vendors do not have one and draw it under deadline. Drawing it once, properly, pays for itself immediately — it answers a document request, it feeds your records of processing activities, and it makes the data residency questions in the questionnaire answerable rather than guessed. Our guide to records of processing activities covers the inventory this feeds into.

Business continuity and disaster recovery plan. Reviewers want RTO and RPO figures, single points of failure, and — the question that catches people — the last date you actually tested a restore. "We back up nightly" is not an answer to "when did you last verify you could restore." If you have never tested, say so and schedule one, because it will be asked again.

What to send when you do not have it

The same structure works for every gap: name it, describe what you do instead, offer what you can evidence, and give a date only if the date is real.

"We do not currently hold a SOC 2 report. We run annual third-party penetration testing, enforce MFA on all production access with quarterly access reviews, and can provide our cloud provider's attestations for the infrastructure layer. We are scoping a Type II audit and expect to begin the observation window next year."

That answer is a no, and it will pass at most buyers, because it demonstrates that you understand what the document is for. The version that fails is silence, and the version that fails worse is a document sent under a label it does not deserve.

Common mistakes with supporting documents

Discovering the document requests on day nine. They arrive with the questionnaire. Read the covering email properly and start gathering immediately, because these depend on other people.

Sending a SOC 2 Type I as "our SOC 2." Reviewers check. Name which type you hold.

Sending only the ISO certificate. Scope statement and Statement of Applicability are usually part of the same request. Sending one of three generates a follow-up round.

Claiming policies that exist only as intentions. A short real policy beats a claimed one that cannot be produced.

Treating the subprocessor list as a one-off email. It changes, buyers are entitled to notice, and publishing it converts a recurring request into a URL.

FAQ

What documents do buyers ask for with a security questionnaire?

Most commonly a SOC 2 report or ISO 27001 certificate, a recent penetration test summary, your DPA, a subprocessor list, security policies, an architecture or data flow diagram, a business continuity plan, and a cyber liability insurance certificate. Not every buyer asks for all of them.

Do I need a SOC 2 report to sell to enterprise?

Not always, but its absence needs an explanation and compensating evidence. Some enterprise buyers treat it as a hard requirement; many will proceed with a thorough questionnaire, a penetration test summary, and clear documentation if the risk profile is moderate.

Should I send the full penetration test report?

Usually not. An executive summary showing date, scope, tester, severity counts, and remediation status is standard and accepted, since the full report contains exploitable detail. Be ready to discuss findings if asked.

What is a Statement of Applicability?

An ISO 27001 document listing which Annex A controls you have applied, which you have excluded, and the justification for each exclusion. Buyers request it alongside the certificate because it shows the shape of your implementation rather than just its existence.

Closing thought

The document request is where security reviews actually stall. Questionnaire answers can be written quickly under pressure; a subprocessor list that has never existed, a DPA nobody can find, and a data flow diagram that lives in one engineer's head cannot be. Each is a small job done calmly and a genuine problem done on a deadline in front of a customer.

Several of the documents on this list are also things a buyer would rather look up than request. ComplyDog hosts a compliance portal on your own domain covering your DPA, subprocessor list, data subject request process, and security overview, kept current, so the recurring half of the pack is already published when the questionnaire arrives. The SOC 2 report still has to come from an auditor. The rest does not have to come from a scramble.

This article works through the five differences that actually change what you do — publisher, cost, scope, format, and whether the result is public — then covers which one a given buyer is likely to ask for, whether either can substitute for the other, and what to do if you are starting from nothing and can only produce one this quarter.

The five differences that matter

Who publishes them. The SIG comes from Shared Assessments, a membership organization focused on third-party risk management. The CAIQ comes from the Cloud Security Alliance, an industry body whose corporate membership includes the major cloud providers. Both are credible with buyers; neither is a regulator.

What they cost. This is the sharpest practical difference. The SIG requires agreement to terms plus either Shared Assessments membership or an annual subscription, which means as a vendor you generally answer a file your buyer licensed rather than holding your own copy. The CAIQ is free — no licence fee, no per-seat charge, no membership — and submitting it to the STAR Registry at Level 1 is also free. If you want to prepare in advance without spending money, the CAIQ is the one you can just download.

What they cover. The SIG spans your business as a supplier: governance, resilience, personnel security, physical security, compliance, and much more alongside the technical controls. The CAIQ is cloud-specific across IaaS, PaaS, and SaaS, and goes deep on shared responsibility boundaries, encryption at rest, key management, identity and access management, and tenancy. Those are the questions a SIG asks at lower resolution.

Their shape. The SIG has historically been an Excel workbook driven by a tool called SIG Manager, with scoping by risk domain and control family, and in March 2026 Shared Assessments launched SIG Evolution, a browser-based platform for distributing and scoring assessments. Offline Excel completion is still supported and importable. The CAIQ is a single spreadsheet of yes-or-no questions with a fixed structure — CAIQ v4 holds 261 questions mapped to the 197 control objectives of the Cloud Controls Matrix v4 across 17 domains.

Whether the answers are public. The SIG you complete goes to one buyer. The CAIQ can be published on the CSA STAR Registry where anyone can read it. This is the difference with the largest downstream consequence and the one most vendors underweight.

The publishability point, expanded

A completed SIG is a private document with a single recipient. Its value is consumed by one deal. Do it again next quarter for the next buyer.

A published CAIQ works on buyers you have not met. A security reviewer building a shortlist can check the registry before contacting you, which means your answers do work in the window between being shortlisted and being emailed — precisely the window where a small vendor is most likely to be quietly dropped for lack of visible evidence.

Two caveats keep this honest. STAR Level 1 is a self-assessment that nobody audits, and calling it a certification in front of a reviewer who knows the registry will cost you more credibility than the entry earns. And self-assessments are updated annually, so a visibly stale entry is a worse signal than no entry, because it says your security documentation is something you did once.

STAR Level 2 involves a certification or attestation from an independent auditor. That carries real weight, costs real money, and is a later-stage decision for most small SaaS companies.

Which one a buyer will send you

Rough patterns, with the usual caveat that individual companies vary.

Financial services, insurance, healthcare, and large regulated enterprises lean SIG. These are the industries Shared Assessments was built around, and their third-party risk teams already hold licences and process SIGs at volume.

Cloud-forward technology buyers and security teams assessing infrastructure lean CAIQ, or check the STAR Registry first. If your prospect's security engineer is the one asking, the questions are more likely to be cloud-shaped.

Mid-market buyers without a formal TPRM function send a bespoke spreadsheet that borrows from both, or a vendor portal with its own questions. This is the most common experience for a small SaaS vendor, and it is the case where a reusable answer bank matters more than knowing either standard.

Anything you have answered once maps onto the next format. Our guide to building a reusable answer library covers the mapping work that makes format-agnostic answering possible.

Can one substitute for the other?

Partly, in one direction, and not at all in the other.

A published CAIQ can often satisfy the cloud portion of a broader assessment. If a SIG asks about encryption at rest, key management, and tenancy, pointing at your STAR entry answers those questions with a link and a line, and many buyers accept that. It reduces the SIG rather than replacing it.

A completed SIG does not substitute for a CAIQ. It covers cloud controls at lower resolution than a buyer asking specifically about cloud wants, and it is not published, so it cannot do the pre-contact work that a STAR entry does.

Neither substitutes for an attestation. A SIG produces structured vendor assertions and a STAR Level 1 entry is a self-assessment. A buyer who wants independent verification wants a SOC 2 report, an ISO 27001 certificate, or a STAR Level 2 attestation, and no amount of questionnaire completion produces one. If ISO 27001 is on your roadmap, our guide to ISO 27001 readiness covers what that path involves.

If you can only do one this quarter

Do the CAIQ, for three reasons that have nothing to do with which framework is better.

It is free, so the only cost is time. It is publishable, so the work compounds across every future buyer rather than being consumed by one. And you can start it today without a buyer, a licence, or a deal on the line, which means you are writing your security documentation while calm rather than under a procurement deadline.

The 261 questions also function as a self-audit. Working through them surfaces the controls you assumed existed and the ones nobody owns. Finding those in a spreadsheet on a quiet week costs considerably less than finding them in a call with a prospect's security team.

Then, when a SIG eventually arrives, a meaningful portion of it is already written.

Common mistakes comparing the CAIQ and SIG

Treating them as alternatives. They cover different ground. Most cloud SaaS vendors selling to enterprise eventually deal with both.

Assuming a completed SIG covers the cloud questions. It covers them at lower resolution than a cloud-focused reviewer wants, and it is not public.

Calling a STAR Level 1 entry a certification. It is an unaudited self-assessment. Level 2 involves a third-party auditor. Reviewers know the difference.

Publishing a CAIQ and forgetting it. Self-assessments are updated annually. Stale is worse than absent.

Waiting for a buyer to ask before starting either. The CAIQ costs nothing and can be done in advance. Doing it under deadline is a choice, not a requirement.

FAQ

What is the difference between the CAIQ and the SIG?

The SIG is a broad third-party risk questionnaire from Shared Assessments that covers your business as a vendor and requires a subscription or membership to license. The CAIQ is a free cloud-specific questionnaire from the Cloud Security Alliance, with 261 questions in version 4 mapped to the Cloud Controls Matrix, and it can be published publicly on the CSA STAR Registry.

Do I need both a CAIQ and a SIG?

If you sell cloud software to enterprise buyers, you will probably encounter both eventually. They are complements rather than alternatives: the CAIQ goes deep on cloud controls, and the SIG covers governance, resilience, personnel, and compliance alongside technical questions.

Is the CAIQ easier than the SIG?

Generally yes, for a cloud SaaS vendor. It is shorter, its questions are yes-or-no rather than narrative, its scope matches how your product actually works, and it is free to obtain. It is also fixed rather than scoped by the buyer, so you know what you are getting.

Can I send a buyer my CAIQ instead of completing their SIG?

You can offer it, and it frequently reduces the work by answering the cloud sections with a link. Buyers with a formal third-party risk process will usually still want the broader questionnaire completed, because the SIG asks about areas the CAIQ does not cover.

Closing thought

The useful way to hold these two apart is by what they are for rather than what they contain. The SIG answers "is this company safe to do business with," across everything a supplier relationship touches. The CAIQ answers "is this cloud service built the way it should be," in depth, publicly. A buyer with a mature risk function wants both answers and will get them from wherever is cheapest.

The overlap between them, and between both and every bespoke spreadsheet you will receive, is largely data protection documentation: subprocessors, DPAs, retention, deletion, residency, breach notification. ComplyDog publishes those on a compliance portal at your own domain so they answer once, in public, in whatever format the next questionnaire happens to use. Knowing which framework you are looking at is useful. Not having to rewrite the same twenty answers for each one is more useful.

This article covers how to identify which tier actually landed in your inbox, why the file may not match either template cleanly, what the buyer's choice signals about the deal, how the effort and staffing differ between the two, and what to do if you have received a Core and think the scope is wrong.

Identifying which one you received

Do not go by the filename. Buyers rename files, and a workbook called "Vendor Assessment 2026" tells you nothing. Three checks settle it in about five minutes.

Count the populated rows. Shared Assessments describes the 2023 SIG Lite as 126 risk control questions. If your file sits roughly in that range, you have a Lite or something close to it. Several hundred rows means Core or a scoped equivalent. The full content library runs to 1,855 questions, so nothing you receive will be everything.

Look at the shape of the coverage. A Lite touches many risk domains with a handful of questions each. A Core goes several levels deeper inside each domain, asking not just whether you have a control but how it is implemented, who reviews it, and how often. If a domain has one question, that is Lite behaviour. If it has fifteen, that is Core behaviour.

Check whether the question text asks for narrative. Lite questions tend to resolve to yes, no, or not applicable. Core questions frequently expect a description alongside the answer, and that expectation is the bulk of the extra work.

If you are still unsure, ask the buyer directly. "Is this scoped as a SIG Lite or a Core?" is a normal question that costs nothing and gets an answer.

Why your file may match neither

The SIG is built to be scoped, and this is the part that surprises people who read about the tiers and then open the workbook.

A buyer generates an assessment by selecting risk domains and control families. They can mix scope levels per domain, which means a single questionnaire can be Lite across most areas and Core in the two domains they actually care about. This is not an edge case; it is how experienced third-party risk teams use the tool.

That has a useful consequence. The dense sections tell you what the assessment is really about. If your file is broadly shallow but suddenly detailed on data retention and subprocessors, the reviewer has a specific concern about data retention and subprocessors, and those answers deserve disproportionate care. Treating a scoped questionnaire as uniform — spreading effort evenly across every section — is how vendors write beautiful answers about physical security for a datacentre they do not operate while giving a thin answer to the question the whole review exists to settle.

There is also a third tier. SIG Detail draws from the full library for buyers who want to go beyond standard scoping into specific control families. It is uncommon for small vendors and usually appears in regulated industries.

What the tier tells you about the deal

The tier is a risk classification, and it is worth reading as commercial information.

A Core means you are in scope for something the buyer is regulated on. Shared Assessments positions Core for third parties that store or manage highly sensitive or regulated information — payment data, health data, and similar. Receiving one means the buyer has decided your product handles material they answer for. That is a burden and also a signal: nobody spends a security analyst's week on a vendor they are lukewarm about.

A Lite can mean two very different things. Sometimes it means genuinely low risk and a routine box to tick. Sometimes it is explicitly a preliminary screen before a deeper review, which Shared Assessments names as one of its intended uses. The second case matters, because a vendor who treats the Lite as the whole engagement is unprepared when the Core arrives three weeks later. If a Lite arrives early in a large enterprise deal, ask whether a fuller assessment follows.

A hybrid means someone thought about it. Scoped assessments take effort to build, which usually means a real risk function rather than a procurement checklist. Expect follow-up questions on the dense sections.

How the effort differs

The gap is wider than the question count suggests, and it is not linear.

A Lite is mostly transcription. Broad yes-or-no questions across many domains map cleanly onto facts you either know or can find in an afternoon. For a company with existing documentation, a Lite is realistically a day or two of one person's time.

A Core is a different category of work, for three reasons. The narrative expectation means writing rather than ticking. The depth means questions where the honest answer requires a decision about what your architecture actually does — which is engineering judgment, not documentation. And Core answers attract follow-ups, so you should budget for a second round after submission.

The staffing follows from that. A Lite can be owned end to end by one non-technical person with an engineer on call for a handful of questions. A Core needs the split properly: a coordinator running the document and a senior engineer working a flagged subset in a bounded session. Our guide to answering a security questionnaire without a security team covers how to run that split so it takes hours of engineering time rather than weeks.

When the Core is the wrong scope

Occasionally you receive a Core that does not fit — most often when your product is narrow and the buyer's default assessment was built for a vendor that hosts everything.

The tell is a large "not applicable" count. If you are working through a questionnaire marking forty questions N/A because they ask about datacentres you do not operate, hardware you do not own, or business lines you are not in, the assessment was scoped for a different kind of company.

Raise it, early, in a specific way. Not "this is too long," which reads as reluctance, but "roughly a third of these questions cover physical datacentre operations. We run entirely on managed cloud infrastructure and can supply our provider's own attestations for that domain. Would you like us to complete those sections as N/A with a reference, or would you prefer to rescope?"

That framing is doing real work for the reviewer, who does not want forty meaningless N/A rows either. Buyers frequently narrow the assessment. What they will not do is narrow it on day nine, after you have already answered half of it.

Common mistakes with SIG tiers

Judging the tier by filename or by an article's question count. Open the file, count populated rows, and look at how deep the coverage goes inside each domain.

Spreading effort evenly across a scoped questionnaire. The dense sections are what the review is about. Weight your care accordingly.

Treating a SIG Lite as the end of the process. Shared Assessments lists preliminary screening as an intended use. Ask whether a deeper assessment follows.

Answering a Core with Lite-depth responses. Core questions expect narrative. A bare yes where a description was expected generates a follow-up round and delays the deal further than writing it properly would have.

Silently marking forty questions N/A. If the scope is genuinely wrong, say so in the first days with a concrete alternative. Buyers rescope early and refuse to rescope late.

FAQ

How many questions are in SIG Lite versus SIG Core?

Shared Assessments describes the 2023 SIG Lite as 126 risk control questions. SIG Core is substantially larger and third-party sources cite differing figures, partly because the SIG is on an annual release cycle and partly because buyers scope assessments themselves. Count the file you received rather than relying on a published number.

Which SIG will a buyer send me?

It depends on how they have classified your risk. Lite goes to lower-risk third parties or is used as a preliminary screen. Core goes to vendors that store or manage highly sensitive or regulated information. Buyers can also generate a scoped hybrid that is Lite in most domains and Core in a few.

Is SIG Core harder than SIG Lite?

Meaningfully, yes, and not only because of length. Core questions typically expect narrative descriptions rather than yes-or-no answers, they go deep enough to require engineering judgment, and they attract follow-up questions after submission.

Can I ask a buyer to send a SIG Lite instead of a Core?

You can ask, and it sometimes works when the scope genuinely does not fit your product — for example when a large portion of the questionnaire covers infrastructure you do not operate. Raise it in the first few days with a specific alternative rather than as a general objection to length.

Closing thought

The tier question is worth answering carefully because it is the cheapest planning information you will get. Five minutes counting rows and reading section depth tells you whether this is a two-day task or a two-week one, whether you need an engineer, and how much the buyer cares. Vendors who skip that step commit to a date first and discover the shape of the work afterwards, which is how a routine security review becomes a missed deadline in a deal that was going well.

Whichever tier arrives, a consistent slice of it is data protection documentation rather than security engineering: your subprocessor list, your DPA, retention periods, deletion process, where data sits. ComplyDog keeps those on a hosted portal at your own domain, current and public, so that portion of a Core is a link rather than a fortnight. The rest still needs your engineer. There is simply less of it.

This article covers the split that makes this tractable, the four-bucket sort that sizes the work, how to run the engineering session so it takes hours rather than weeks, how to answer honestly when the answer is no, and what to do about the questions that assume a security function you do not have.

The split that makes this possible

Take a two-hundred-question assessment at a company of twelve people. Sorting the questions by who can actually answer them typically produces something like this.

Roughly half are documentation: what your retention period is, who your subprocessors are, whether you have a written policy, what your notification window is. These require finding out and writing it down. No security expertise required.

Roughly a third are simple technical facts that any engineer on your team knows without research: whether MFA is enforced, whether data is encrypted at rest, which cloud provider you use, whether production access is logged.

The remainder — often twenty to forty questions — require real judgment. These are the ones where the honest answer is nuanced, where a careless yes creates a commitment you cannot keep, or where you need to decide what a term means in your architecture.

Only that last group needs your most senior engineer. If they are handling all two hundred, you are spending your scarcest resource on transcription, and it will take three weeks because they will do it between other work.

The four-bucket sort

Before anyone answers anything, one person reads the whole questionnaire and sorts every question into four buckets. This takes an hour or two and saves days.

Bucket 1 — Already documented. The answer exists in a policy, a previous questionnaire, or a vendor's own documentation. Pure transcription.

Bucket 2 — Known but unwritten. Someone on the team knows it; it has never been written down. A short conversation, then transcription.

Bucket 3 — Needs judgment. The nuanced ones. Flag for the engineering session.

Bucket 4 — Not applicable. Questions about datacentres you do not operate, hardware you do not own, or business lines you are not in. Every questionnaire has these, and marking them clearly with a one-line reason is a real answer, not a dodge.

The sort also tells the buyer something useful. If bucket 3 is small, you can commit to a date with confidence. If bucket 4 is large, that is worth raising early — it usually means the questionnaire was scoped for a different kind of vendor, and buyers will often narrow it rather than have you write "N/A" two hundred times.

Running the engineering session

Bucket 3 gets one meeting, not an assignment.

Book ninety minutes. Bring the flagged questions, already extracted into a single list, with the buyer's exact wording. Have a non-engineer in the room whose job is to type the answers as they are spoken. Work down the list.

This structure matters more than it sounds. An engineer given a spreadsheet will open it, answer four questions, get pulled into an incident, and return to it three days later having lost context. An engineer in a room with a list and someone typing will clear thirty questions in ninety minutes, because the task is talking rather than writing, and talking is the part they are fast at.

Two rules for the session. Anything that cannot be answered in two minutes gets parked with a named owner and a date, rather than being debated. And nobody writes final prose in the room — capture the substance, polish afterwards, because wordsmithing is what turns a ninety-minute session into a four-hour one.

Answering honestly when the answer is no

Without a security team you will have gaps: no penetration test, no SOC 2, no formal security training programme, no on-call security rota. Reviewers know what a twelve-person company looks like. They are not expecting a CISO. What they are assessing is whether you know your own posture.

The structure that works is: state the gap, describe what compensates, give a timeline only if it is real, offer evidence.

"We do not have a formal security awareness training programme. All staff complete onboarding covering credential handling, phishing, and data classification, and access to production requires MFA and is reviewed quarterly. We are evaluating a formal programme for the second half of the year."

That answer is a no. It will not fail an assessment at most buyers, because it demonstrates that you know what the control is for and have thought about the risk. The version that does fail is "No" alone, and the version that fails worse is a yes you cannot evidence.

Resist the pull toward the generous interpretation. Every long questionnaire contains a question where you could plausibly answer yes if you squint. A reviewer who asks a follow-up and finds the yes was aspirational will re-read every other answer with suspicion, and that is a far more expensive outcome than the gap would have been. Our guide to running a GDPR compliance audit covers the same principle applied to the privacy half of the same review.

The questions that assume a function you do not have

Some questions presume an org chart you do not have: "Who is your Chief Information Security Officer?" "Describe your security operations centre." "How many staff are in your information security function?"

Do not leave these blank and do not invent a title. Name the person who actually holds the responsibility and describe the arrangement plainly. "Security is owned by our CTO, [name], alongside engineering leadership. We do not maintain a separate information security function at our current size."

This reads as accurate rather than deficient. What reads as deficient is a blank field, because a blank field is indistinguishable from an oversight and generates a follow-up. What reads worse is a fictional CISO title assigned to whoever seemed closest, which becomes awkward the moment the reviewer asks that person a question.

The same applies to policies. If your access control policy is four paragraphs in a shared document rather than a formal signed document, say that. A short real policy is defensible. A claimed policy that does not exist is not.

Common mistakes when answering without a security team

Assigning the whole questionnaire to an engineer. They will context-switch on it for weeks. Sort first, then use their time only on the questions that need judgment.

Skipping the sort. An hour of triage turns an unbounded task into four defined ones and lets you commit to a real date.

Letting the engineering session become a writing session. Capture substance verbally with someone else typing; polish afterwards.

Leaving org-chart questions blank. A blank field looks like an oversight and generates follow-ups. Name who actually owns it and describe the arrangement.

Answering yes where the honest answer is "not yet." One unevidenced yes causes a reviewer to re-read everything else sceptically. The gap was cheaper.

FAQ

Can a company without a security team pass a security questionnaire?

Yes, routinely. Questionnaires are not pass-or-fail exams; they are inputs to a buyer's risk decision. Small vendors are assessed on whether they understand and document their posture, not on whether they have a dedicated security function.

How long should answering a security questionnaire take?

With existing documentation and a sorted question list, a mid-sized assessment is typically a few days of part-time work with one focused engineering session. A first assessment with no prior answers is realistically two to three weeks, most of which is discovering and writing down what you already do.

What if I don't have SOC 2 or ISO 27001?

Say so directly and describe what you do have — encryption, access control, logging, dependency scanning, vendor due diligence. The absence of an attestation is a known and common situation. Attempting to imply one you do not hold is not.

Should I hire a consultant to answer security questionnaires?

Rarely worth it for a first questionnaire, because the bottleneck is knowledge of your own systems, which a consultant does not have. It becomes worthwhile when questionnaire volume is consistently consuming engineering time and you want an answer bank built and maintained.

Closing thought

The reason these feel disproportionate at a small company is a mismatch of units. The questionnaire was designed to assess a vendor with a security department, and it asks its questions in that vocabulary. You are answering in a different one. The work is largely translation — taking what your team genuinely does and expressing it in the terms the document expects — and translation is a documentation skill, not a security skill.

Once translated, most of it stops being per-deal work. The recurring questions about subprocessors, data retention, residency, deletion, and data subject requests have stable answers that belong at a URL rather than in a spreadsheet. ComplyDog hosts those on your own domain and keeps them current, so the next questionnaire starts with a section already answered. The judgment questions still need your engineer. There should just be far fewer of them by then.

This article covers why a blank template is the wrong artifact for a vendor, the ten topics that recur across nearly every assessment, how to structure each entry so it survives being pasted into someone else's format, which parts belong in public and which stay internal, and how to keep the thing from going stale.

Why a blank questionnaire is the wrong tool for a vendor

Downloadable security questionnaire templates exist in quantity, and nearly all are built for the buyer. They assume you are assessing someone else. As a SaaS vendor you are on the receiving end, and you do not choose the format — the buyer does. You will be sent a SIG one quarter, a CAIQ the next, a bespoke spreadsheet after that, and a web portal after that.

So a template that fixes the questions is useless, because the questions change. What does not change is the underlying subject matter. Encryption, access control, backups, subprocessors, incident response, data retention, residency, personnel security, business continuity, and secure development appear in essentially every assessment, phrased differently each time.

Build the answers around the subjects. Then answering a questionnaire is a mapping exercise: read the question, identify the topic, retrieve the answer, adjust the phrasing to fit their wording. That is a task a non-technical person can do at speed. Researching from scratch is not.

The ten topics to cover

Each of these should have a written answer before you need it.

Encryption. At rest and in transit, stated separately, with the algorithm and key management approach. "We use industry-standard encryption" fails; "AES-256 at rest, TLS 1.2 or above in transit, keys managed in [service] with rotation every N days" passes.

Access control and authentication. How employees access production, whether MFA is enforced, how access is granted and revoked, and how often it is reviewed. Offboarding timelines get asked about specifically.

Backups and recovery. Frequency, retention, storage location, encryption status, and — the one most vendors cannot answer — the last date a restore was actually tested.

Subprocessors. The full list, what each processes, where it is located, and how customers are notified of changes. This overlaps directly with GDPR obligations, and if you maintain it for one purpose it serves the other. Our guide to subprocessors under GDPR covers what belongs in the inventory.

Incident response. How an incident is detected, who is notified, the customer notification window, and whether you have ever run the process. A documented process nobody has rehearsed is still better than none, and you should say which it is.

Data retention and deletion. How long data is held, what happens at contract termination, how long deletion takes across backups, and whether a customer can request deletion mid-contract.

Data residency. Where data is physically stored and processed, including where your subprocessors sit. Buyers with EU customers ask this early.

Personnel security. Background checks, security training, confidentiality agreements, and offboarding.

Business continuity. RTO and RPO if you have them, single points of failure, and what happens if a key vendor goes down.

Secure development. Code review, dependency scanning, whether you run a penetration test and when, and how vulnerabilities are triaged.

How to write an entry so it survives reuse

Give each topic four parts.

The short answer. One or two sentences, specific, pasteable directly into a yes-or-no field with a comment box. This is what gets used ninety percent of the time.

The long answer. A paragraph with the detail, for questionnaires that want narrative. Written once so nobody improvises it under deadline.

The evidence. A link or file reference to whatever backs the claim — the policy document, the configuration screenshot, the vendor's own certification. Reviewers ask for evidence on roughly a fifth of answers and the delay is almost always in locating it.

The last verified date. The single most valuable field, and the one everyone omits. An answer written eighteen months ago about a system that has since been re-architected is worse than no answer, because you will paste it in with confidence.

Write in the first person plural and in plain language. Avoid absolutes — "always," "never," "fully compliant" — because reviewers probe them and because they age badly.

What goes public and what stays internal

Split the bank in two, because the public half does work while you sleep.

Publishable, for most SaaS companies: your subprocessor list, your DPA, your privacy policy, your data retention policy, your data residency, your data subject request process, and a general security overview describing encryption, access control, and incident response at a level that does not help an attacker.

Internal only: specific infrastructure detail, security tooling and configuration, penetration test findings, named personnel, and anything that would function as a map of your attack surface.

The public half means a chunk of every future questionnaire is answered with a URL. It also means a buyer evaluating you before making contact finds something. A published subprocessor list and DPA are, in practice, the two documents most often requested and most often missing at companies under twenty people.

Keeping it current

An answer bank decays. Infrastructure changes, vendors get swapped, policies get rewritten, and nobody updates the document because it is nobody's job.

Two mechanisms handle this cheaply. Review the bank once a quarter, in a calendar entry, with the last-verified dates as your worklist — anything older than six months gets checked or deleted. And update it every time you complete a real questionnaire, while the corrections are in front of you. If a buyer's question exposed an answer that was wrong or missing, that is the cheapest moment you will ever have to fix it.

The version that goes stale silently is worse than none, because it produces confident wrong answers under time pressure, which is exactly the failure that turns a routine security review into a contradiction the reviewer has to escalate.

Common mistakes with security questionnaire templates

Downloading a buyer-side template. Most templates are built for assessing vendors, not for being one. As a vendor you do not control the format; build answers by topic instead.

Organising by customer. A folder per account means starting over each time. Organise by subject so any question maps to an existing entry.

Writing only long answers. Most fields are short with a comment box. Without a one-sentence version, someone improvises one under deadline.

Omitting the last-verified date. It is what turns the bank from a liability into an asset, and it is the field everyone leaves out.

Keeping everything internal. The subprocessor list, DPA, and retention policy are not secrets. Published, they answer questions before they are asked.

FAQ

Is there a standard security questionnaire template for SaaS companies?

There are standard questionnaires — the SIG from Shared Assessments and the CAIQ from the Cloud Security Alliance are the most widely used — but they are chosen by the buyer, not the vendor. As the vendor, what helps is an internal answer bank organised by topic that maps onto whatever format arrives.

What should a security questionnaire cover?

Encryption, access control and authentication, backups and recovery, subprocessors, incident response, data retention and deletion, data residency, personnel security, business continuity, and secure development. Nearly every assessment touches these, however differently they phrase them.

Should I publish my security questionnaire answers?

Publish the half that is not sensitive: subprocessor list, DPA, privacy policy, retention, residency, data subject request process, and a general security overview. Keep infrastructure specifics, tooling configuration, and test findings internal.

How often should I update security questionnaire answers?

Review quarterly against the last-verified dates, and update opportunistically every time you complete a real assessment. Anything unverified for six months should be rechecked before reuse.

Closing thought

The reason questionnaires feel disproportionate to small teams is that they are priced as a per-deal cost when they are really a one-time cost with a maintenance charge. The team that answers each one from scratch pays the full price every quarter. The team that built an answer bank pays once and then pays a small amount to keep it honest.

The public half of that bank is the part with the best return, because it works without anyone being asked. ComplyDog hosts exactly that on your own domain — DPA, subprocessor list, data subject request handling, and a security page, kept current and linkable. The internal half still needs to exist. But the questions you were about to answer for the fourth time stop being questions.

This article covers how to triage a questionnaire in the first hour, who should own it at a company with no security team, what to do in the first forty-eight hours, how to handle the questions where your honest answer is no, and how to make sure the second questionnaire costs a fraction of the first.

The first hour is triage, not answering

Open the file and establish five things before you write anything.

What format is it. A standard template like a SIG or a CAIQ means the questions are known quantities and much of your answer is reusable. A bespoke spreadsheet written by the buyer means bespoke work. A vendor portal that requires you to create an account and answer in a web form means you cannot easily draft offline, and you should find out early whether it supports bulk import.

How long it actually is. Count populated rows, not the file's reputation. Questionnaires range from thirty questions to several hundred, and the difference determines everything downstream.

Who is asking, and why now. A security engineer running a genuine review behaves differently from a procurement analyst clearing a checklist. If the questionnaire arrived immediately after a pricing conversation, it is a gate. If it arrived from an unfamiliar name with no context, ask the account contact what triggered it.

What the real deadline is. The stated date is often the analyst's internal target rather than a hard stop. Ask. Buying two weeks at the start is trivially easy and asking for an extension at the deadline is not.

What else they want alongside it. Questionnaires usually travel with requests for a SOC 2 report, an ISO 27001 certificate, a penetration test summary, a DPA, or an architecture diagram. Finding out on day one that they also want a pen test report is very different from finding out on day nine.

Name one owner before the end of day one

The single most reliable predictor of a questionnaire being returned late is that it belonged to everybody. It sits in a shared drive, three people each answer the sections they find easy, the hard ones stay blank, and the deadline arrives with the document eighty percent done — which for this purpose is the same as zero percent.

So before anything else, put one name against it. That person does not need to be your most technical; they need to be the person who will notice on Thursday that nobody has answered the backup questions. Coordination is the larger half of this job and it is not an engineering skill. Our guide to who should own security questionnaires at a small SaaS company covers the ownership models in depth, including where each one breaks as you grow.

The first forty-eight hours

Four things, in order.

Acknowledge and set a date. Same day. A short reply confirming receipt and giving a realistic return date buys more goodwill than a fast partial answer.

Split the questions into three buckets. Known and documented; known but not written down; genuinely unknown. The first bucket is transcription. The second is a conversation with an engineer. The third is the real work, and it is usually a small fraction of the total. Sizing these three buckets tells you whether this is a two-day task or a two-week one, and you cannot know that without doing the split.

Gather the evidence pack in parallel. Whatever documents were requested alongside the questionnaire, start collecting them immediately, because they often depend on other people or on vendors who take days to respond.

Flag the noes early. If there is a question you will have to answer no to, and it looks material, raise it with the buyer before you return the document rather than letting them discover it. Reviewers respond very differently to a known gap raised proactively than to one they find themselves.

The questions you have to answer no to

Every small vendor has them. No formal penetration test yet. No SOC 2. No dedicated security personnel. No twenty-four-hour incident response rota.

A no is not automatically disqualifying. What determines the outcome is whether the reviewer believes you understand the gap. Three answers to the same question land very differently:

"No." — Reads as a gap with nothing behind it.

"No, but we take security seriously." — Reads worse, because it is a gap plus a deflection.

"No formal penetration test to date. We run automated dependency and container scanning on every build, our infrastructure is single-tenant per customer, and we have budgeted a third-party test for Q1. Happy to share the scanning configuration." — Reads as a company that knows its own posture.

The third answer takes ninety seconds longer to write and changes the reviewer's assessment of everything else in the document. The pattern is: state the gap plainly, describe what compensates, give a timeline if one genuinely exists, and offer the evidence. Do not invent the timeline. A reviewer who is told Q1 will check in Q2.

Making the second one cheap

The first questionnaire is expensive because you are discovering your own controls in writing for the first time. The second should not be, and for most small companies it is, because the answers were left inside a completed spreadsheet in a folder named after the customer.

Keep the answers somewhere they can be found by question rather than by customer. Even a simple document organised by topic — encryption, access control, backups, subprocessors, incident response, data retention, data residency — turns the next questionnaire from research into retrieval.

Publish the parts that can be public. A large portion of what buyers ask is not confidential: your subprocessor list, your DPA, your data retention policy, your security overview, how you handle data subject requests. Anything sitting at a public URL is an answer you supply with a link rather than a paragraph, and it is an answer the buyer can check without asking. Our GDPR compliance checklist covers much of the documentation that overlaps with these questions.

Common mistakes when responding to a security questionnaire

Starting to answer before triaging. An hour of scoping tells you the format, the length, the real deadline, and the accompanying document requests. Answering first means discovering the pen test request on day nine.

Accepting the stated deadline without asking. It is frequently an internal target. Asking for two extra weeks at the start is easy; asking on the due date is not.

Handing the whole document to an engineer. They will context-switch on it for weeks. Flag the questions needing technical judgment and book a session for those specifically.

Overstating to avoid a no. A generous yes that unravels under follow-up costs more than the gap would have. Reviewers have seen gaps before; they have not forgiven contradictions.

Filing the completed answers under the customer's name. Organise by topic instead, or the next questionnaire costs what this one did.

FAQ

How long does a vendor security questionnaire take to complete?

It depends almost entirely on length and on whether you have answered one before. A short template with existing documentation can be a day. A first-time Core-tier assessment with several hundred questions and no prior answer bank is realistically two to three weeks of part-time work across several people.

Do I need SOC 2 to answer a security questionnaire?

No. Questionnaires exist partly because not every vendor has a formal attestation. A SOC 2 report shortens the process considerably because it answers many questions by reference, but its absence is a gap to explain rather than a disqualification.

Who should fill out a security questionnaire at a small company?

Split it. Someone in operations or on the deal owns coordination, tracking, and return. Your most senior engineer answers the flagged technical questions in a bounded block of time. Single ownership by an engineer is the most common way these stall.

Can I refuse to complete a security questionnaire?

You can, and it usually ends the deal at any buyer with a formal procurement process. A more productive path is to negotiate scope: offer a published security page, a completed standard questionnaire, or an existing attestation in place of a bespoke document.

Closing thought

The uncomfortable thing about a first security questionnaire is that it is not really testing your security. It is testing whether you can describe your security, in writing, on a deadline, without contradicting yourself. Those are different capabilities, and the second one is what small vendors typically lack — not because their systems are bad, but because nobody has ever had to write it down.

The way that stops being painful is to write it down once, publicly, and keep it current. ComplyDog hosts a compliance portal on your own domain covering your DPA, subprocessor list, data subject request handling, and security posture, so the recurring questions arrive at a page instead of an inbox. It does not answer the questionnaire. It removes the portion of the questionnaire you were about to answer for the fourth time.

This article covers what the CAIQ is and how it relates to the Cloud Controls Matrix, the file-naming trap that causes rejected submissions, what the CSA STAR Registry is and the difference between its two levels, how the CAIQ compares to the SIG and why most cloud vendors end up dealing with both, and the argument for completing one before anyone requests it.

The CAIQ and the Cloud Controls Matrix

The two are easy to confuse and the relationship is simple. The Cloud Controls Matrix, or CCM, is the controls framework: 197 control objectives across 17 security domains. The CAIQ translates those objectives into 261 specific yes-or-no questions. The CCM says what should be true; the CAIQ asks whether it is.

Version 4 streamlined the questionnaire from 310 questions in the previous version down to 261, and added sections covering the Shared Security Responsibility Model, which lets a provider describe which parts of a control they own and which parts the customer owns. That addition matters more than it sounds. A great deal of avoidable cloud risk comes from both parties assuming the other one handled something, and the SSRM sections exist to force that boundary into writing.

The scope is cloud services specifically, across IaaS, PaaS, and SaaS. If your product is a hosted SaaS application, you are in scope.

The free part, and the file that cannot be submitted

The CAIQ is genuinely free. No licence fee, no per-seat charge, no membership requirement, and submitting a completed CAIQ to the STAR Registry at Level 1 is also free. This is unusual in the questionnaire world and it is the main practical difference from the SIG, which requires a subscription or membership.

There is one trap, and it catches people every year. The CSA publishes two different downloads. One is "CCM + CAIQ v4," which bundles the controls matrix with the questionnaire and is explicitly for reference only. The other is "STAR Level 1: Security Questionnaire (CAIQ v4)," which is the version you fill in and submit. You cannot submit the bundled reference spreadsheet to the registry. Teams routinely complete the wrong file, discover this at submission, and redo the transcription.

Download the STAR Level 1 file first. Check the filename before you start typing, not after.

The STAR Registry, and its two levels

STAR stands for Security, Trust, Assurance and Risk, and the registry is a public directory of cloud provider security postures. It has two levels, and the distinction is the whole point.

Level 1 is a self-assessment. You complete the CAIQ, you submit it, it is published. Nobody audits it. Its value is transparency and speed: a buyer can read your answers without contacting you, and you can answer a request with a link instead of a spreadsheet. There is an optional paid submission tier that adds automated validation of responses, but the standard Level 1 entry is free and unaudited.

Level 2 is third-party. An organisation earns a certification or attestation from an independent auditor against the CCM. It carries more weight because someone other than you checked. It also costs money and takes time, and it is a later-stage decision for most small SaaS companies.

Self-assessments are updated annually, which is a commitment worth understanding before you publish. A STAR entry that has visibly gone stale is a worse signal than no entry, because it tells a reviewer that your security documentation is something you did once.

AWS, Azure, and Google Cloud all publish in the registry, which is part of why buyers have learned to look there.

CAIQ versus SIG, and why you may face both

They are not competitors and they do not fully overlap.

The SIG is broad third-party risk. It asks about your business as a vendor: governance, resilience, HR security, physical security, compliance, and much more besides the technical controls. The CAIQ is narrow and deep on cloud. It asks about shared responsibility boundaries, encryption at rest, key management, identity and access management, and tenancy — the questions a SIG asks at lower resolution.

The practical consequence is that a buyer running a serious assessment often wants both, or wants a SIG with the cloud sections answered to a depth the SIG alone does not reach. If you maintain a published STAR Level 1 entry, you can frequently satisfy the cloud portion of a broader questionnaire with a single line and a link, which is precisely why cloud-native vendors keep one current.

There is also a CAIQ-Lite, a 124-question short form used for early-stage vendor screens. Same 17 domains, fewer questions in each.

The case for doing it before anyone asks

Most security documentation is written reactively, when a deal is already waiting on it. The CAIQ is the strongest argument against that pattern, for three reasons.

It is free, so the only cost is your time. It is publishable, so the work is reusable across every buyer rather than consumed by one. And it is checkable without your involvement, which means it can do work for you in deals you do not yet know exist — a security reviewer building a shortlist can find your entry and move on to the next question rather than sending an email and waiting three days.

The 261 questions also function as a decent self-audit. Working through them surfaces the controls you assumed were in place and the ones nobody actually owns, and it is considerably cheaper to find those in a spreadsheet on a quiet week than in a follow-up call with a prospect's security team.

Several of the answers overlap with data protection documentation you may already maintain — encryption, retention, subprocessor relationships, incident response. Our guide to GDPR subprocessor management covers the vendor chain that the supply chain sections draw on.

Common mistakes with the CAIQ

Completing the reference file. "CCM + CAIQ v4" cannot be submitted to the registry. Download "STAR Level 1: Security Questionnaire (CAIQ v4)" before you start.

Publishing once and letting it age. Self-assessments are updated annually. A visibly stale entry signals that your documentation is a one-off, which is worse than having none.

Treating Level 1 as a certification. It is a self-assessment that nobody audited. Describing it as certification to a buyer who knows the registry damages your credibility on everything else.

Answering yes without reading the SSRM boundary. Several v4 questions turn on which party owns a control. Answering as though you own something the customer configures produces a contradiction the reviewer will find.

Assuming a CAIQ replaces a SIG. It covers cloud controls deeply and business risk barely. Buyers running full third-party assessments will still want the broader questionnaire.

FAQ

What does CAIQ stand for?

Consensus Assessments Initiative Questionnaire. It is published by the Cloud Security Alliance and consists of yes-or-no questions that let a cloud customer or auditor determine a provider's compliance with the Cloud Controls Matrix.

How many questions are in the CAIQ?

CAIQ v4 contains 261 questions, reduced from 310 in the previous version. They map to the 197 control objectives of the Cloud Controls Matrix v4 across 17 security domains. A shorter CAIQ-Lite exists with 124 questions for early-stage screening.

Is the CAIQ free?

Yes. The questionnaire is a free download from the CSA, and submitting a completed CAIQ to the STAR Registry for a Level 1 listing is also free. An optional paid submission adds automated validation of your responses.

What is the difference between STAR Level 1 and Level 2?

Level 1 is a self-assessment that you complete and publish yourself, with no independent review. Level 2 involves a certification or attestation from a third-party auditor. Level 1 is free and fast; Level 2 carries more weight with buyers and costs considerably more.

Closing thought

The CAIQ is unusual among security questionnaires in that the version you publish is the version everyone can read, which changes what it is for. A SIG is a document you send to one buyer. A STAR entry is a document that answers buyers you have not met, in the window between them shortlisting you and them contacting you, which is exactly the window where a small vendor is most likely to be quietly dropped for lack of visible evidence.

The same logic applies to the data protection half of the same conversation, which the CAIQ only partly covers. ComplyDog runs a hosted compliance portal on your own domain that keeps your DPA, subprocessor list, data subject request process, and security page public and current, so the privacy questions that follow a cloud security review have an answer already sitting at a URL. Two public documents, both maintained, is a materially different posture from a folder of completed spreadsheets.

This article covers what the SIG actually is and who produces it, why the question count you read online will not match the file you were sent, the three tiers you might receive and how to tell which one you have, what changed in 2026 with the move to SIG Evolution, and the single most important thing to understand about a completed SIG: it is not a certification, and treating it like one will cost you the deal.

Who publishes the SIG, and what it is for

Shared Assessments is a membership organization that maintains third-party risk management tooling, and the SIG is its flagship product. The questionnaire exists so that a bank assessing forty vendors does not write forty different sets of questions, and so that a vendor answering forty assessments does not answer forty different sets. That is the entire premise: one vetted question bank, reused across an industry.

The SIG is not free in the way a public standard is free. It requires agreement to terms and conditions plus either a Shared Assessments membership or an annual subscription. This matters to you as a vendor in a specific and slightly absurd way: the buyer holds the licence, sends you the file, and you fill in a document you do not have your own copy of. If you want to work ahead of demand and prepare answers before a questionnaire arrives, you either subscribe yourself or you build your own internal answer bank and map it across when a real SIG lands.

The underlying content library is large. Shared Assessments puts it at 1,855 risk control questions, from which buyers scope a specific assessment. Nobody sends all of them.

Why the question count you read will not match your file

Search for the SIG and you will find confident, contradictory numbers. SIG Core is cited at 825 questions in one place and 855 in another. The risk domain count appears as 18, 19, and 21 depending on who is writing. SIG Lite is given as 126, as 128, and as 150.

These are not all errors. The SIG is on an annual release cycle, so a number that was right for the 2022 release is wrong for 2026, and much of the published commentary was written once and never revisited. But the deeper reason is that the SIG is designed to be scoped. A buyer selects risk domains, control families, or a regulatory scope, and generates a questionnaire from the library. Two customers can both send you "a SIG Core" and you can receive two different files.

The practical instruction is short. Do not plan your effort around a number you read in an article, including this one. Open the file, count the rows, look at which domains are populated, and size the work from that. A vendor who quotes a two-week turnaround based on a blog post and then opens a 900-row workbook has already set an expectation they will miss.

The three tiers, and telling them apart

Shared Assessments structures the SIG in three tiers, and knowing which you received tells you what the buyer thinks of your risk profile.

SIG Lite is the high-level pass. Shared Assessments describes the 2023 SIG Lite as 126 risk control questions designed to give a basic level of assessment due diligence. You get it when the buyer has categorised you as lower risk, or when they are running a preliminary screen before deciding whether to go deeper. It is broad and shallow by design.

SIG Core is the full assessment, meant for third parties that store or manage highly sensitive or regulated information. If you have received a Core, the buyer believes your product touches material they are accountable for. This is the tier where answers get read carefully and where a vague response generates a follow-up rather than a tick.

SIG Detail is the deepest level, drawn from the full library when a buyer wants to go beyond the standard scoping into specific control families.

You can also receive a hybrid. The scoping tool lets a buyer mix levels per domain, so a questionnaire can be Lite across most areas and Core on the two domains they actually care about. If the file you received is short overall but suddenly dense in one section, that section is what the assessment is really about, and it is where your answers should be strongest.

What changed in 2026

Two things, if your last SIG was a year or more ago.

The first is where the questionnaire lives. On 17 March 2026, at its 19th Annual Third-Party Risk USA Summit in Nashville, Shared Assessments launched SIG Evolution, or SIG EV, which moves building, sending, reviewing and scoring an assessment into the browser. For you as the vendor the practical effect is smaller than the announcement suggests. The Excel route is still open: answer offline, and the buyer imports what you send back. SIG EV also reads old files, works out which version it is looking at, and takes workbooks from the current year and the two before it as a starting point, so the fortnight you spent on a 2024 questionnaire is not written off.

The second is what the questions map to, and that changes the answers you have to write. Shared Assessments deepened four reference points in the 2026 release. ISO/IEC 42001 is now referenced, which makes AI management a standing subject rather than an occasional aside: expect to be asked what data trains a model, how it reaches production, and who watches it afterwards, and to answer even when the model is someone else's, reached through an API. The NIST SP 800-171 mapping is more granular, which matters if you serve the defence supply chain or touch Controlled Unclassified Information and is background noise if you don't. Alignment with the Business Resilience Council's Operational Resilience Framework is the one most likely to catch a small SaaS off guard, because it pushes resilience past "do you have a disaster recovery plan" toward whether you can keep operating through a disruption at all, which means knowing your own critical dependencies and therefore your vendors' vendors. And the older ISO 27001 mappings were brought up to ISO 27001:2022 and its restructured Annex A, so a certificate on the current revision lines up more cleanly than it used to; our ISO 27001 readiness guide covers what earning one involves.

A mapping is a filing convenience for the buyer, not a credential for you. It lets one answer close out a control in two frameworks. It does not make you compliant with anything referenced, and the reviewer reading your file knows that even if the person who forwarded it doesn't.

A completed SIG is not a certification

This is the misunderstanding that does the most damage, and it runs in both directions.

Returning the file is testimony, not a verdict. What you hand back is a record of what you say your controls are, with evidence attached wherever the buyer asked to see it. The judgment happens afterwards and on their side of the table: someone reads your answers against the risk their organisation is willing to carry, then decides whether to ask you to explain, ask you to fix, accept a different control that reaches the same place, or write the gap down as a risk they will hold. Submission triggers none of that. It only starts the reading.

Which means two things. First, do not describe yourself as "SIG certified" anywhere, because there is no such thing, and a security reviewer who sees that phrase on your website will read everything else you claim more sceptically. Second, an honest "no, and here is the compensating control" is a legitimate answer that assessments are designed to accommodate. Reviewers are used to gaps. What they are not used to is a yes that unravels under a follow-up question, and the follow-up is where a deal actually stalls.

A large share of what a SIG asks about is data protection rather than pure security: which subprocessors touch customer data, what the contractual chain looks like, how long data is retained, how a deletion request is handled, what happens on breach. Those are GDPR artifacts, and if you already maintain them, a meaningful part of the questionnaire is transcription rather than research. Our guide to subprocessors under GDPR covers the inventory that several of those answers draw on.

Common mistakes when answering a SIG

Quoting a turnaround before opening the file. The tier and scoping vary per buyer. Open the workbook, count the populated rows, then commit to a date.

Claiming to be "SIG certified." No certification exists. The SIG produces assertions, not a pass, and the phrase signals to a reviewer that you have not read the framework you are citing.

Answering yes where the honest answer is "not yet, and here is what compensates." Reviewers expect gaps and have a process for them. What they escalate is an answer that collapses on follow-up.

Treating each SIG as a fresh writing project. The overlap between assessments is high. Answering ad hoc every time is how a two-day task becomes a two-week one for the fourth quarter in a row.

Assuming the mappings do the compliance work. A question mapped to ISO 27001 does not make you ISO 27001 certified. The mapping saves the buyer from asking the same thing twice, nothing more.

FAQ

What does SIG stand for?

Standardized Information Gathering. It is a questionnaire product published by Shared Assessments, a membership organization focused on third-party risk management, and it is used by buyers to assess the security and privacy controls of their vendors.

How many questions are in a SIG questionnaire?

It depends on the tier and how the buyer scoped it. Shared Assessments puts the full content library at 1,855 risk control questions and describes the 2023 SIG Lite as 126. Because buyers scope assessments by risk domain and control family, two files described as the same tier can differ, so count the file you received rather than relying on a published figure.

What is the difference between SIG Lite and SIG Core?

SIG Lite is a high-level screen for lower-risk third parties. SIG Core is the deeper assessment used for vendors that store or manage highly sensitive or regulated information. Receiving a Core means the buyer considers your product material to data they are accountable for.

Do I have to pay to answer a SIG?

Not to answer one your customer sends, since they hold the licence and supply the file. Using the SIG yourself, to prepare in advance or to assess your own vendors, requires Shared Assessments membership or an annual subscription.

Closing thought

The first SIG is always the expensive one, because the work is not really answering questions. It is discovering what you actually do, in enough detail to state it in writing, for the first time. The second one is cheaper only if you kept the answers somewhere better than the completed workbook in a shared drive, which is where most small teams leave them.

The parts a buyer asks about most often are the parts you can publish once and point at rather than retype: your subprocessor list, your DPA, how data subject requests are handled, where data lives, what your security posture actually is. ComplyDog gives you a hosted compliance portal on your own domain that keeps those current and public, which turns a recurring set of questionnaire answers into a link. It will not fill in a 900-row SIG for you. It will mean that the fifteen questions every buyer asks are already answered before the workbook arrives.

To enhance alignment with European privacy and consumer protection laws, Google announced the upcoming release of Google Consent Mode v2.

Anyone using Google services to track the online behavior of users in the European Union (EU) or European Economic Area (EEA) must implement Google Consent Mode v2 by March 2024 to maintain access to the ad personalization, remarketing, and measurement features.

In this guide, learn what Google Consent Mode v2 is, how it differs from the previous version, and how to implement it on your website easily.

Table of Contents

1. What Is Google Consent Mode v2?

2. Google Consent Mode v2 Key Features

3. How Do I Implement Google Consent Mode v2?

4. How Is Google Consent Mode v2 Different From v1?

5. Does ComplyDog Support Google Consent Mode v2?

What Is Google Consent Mode v2?

Google Consent Mode v2 is an updated mechanism that allows websites to read and adjust Google Tags based on a consumer's consent preferences regarding personal advertising and analytics trackers.

The updates to Google Consent Mode better align the way consent preferences are communicated to websites with new and existing EU privacy laws like the Digital Markets Act DMA.

It ensures websites using Google Services obtain adequate consent from EU visitors, adjusting how Google Tags behave based on how consumers interact with a compatible consent banner.

Google Consent Mode v2 Implementation Date

Google requires all websites serving ads to or monitoring the behavior of EU/EEA users to implement Google Consent Mode v2 since March 2024.

Google Consent Mode v2 Key Features

The key feature of Google Consent Mode v2 assists websites with supporting the collection of granular consent, a requirement under the GDPR.

Granular consent means the person you're obtaining consent from fully understands each specific piece of data being collected from them and how it's used.

It introduces two additional parameters to Google's consent mode API:

• ad_user_data: This string sets consent for sending user data to Google for the purpose of advertising.

• ad_personalization: This string sets consent for personalized advertising.

How Do I Implement Google Consent Mode v2?

To implement Google Consent Mode v2, you must use a consent banner on your website.

If you use a Google-certified consent management platform (CMP), the banner will meet all guidelines automatically before the March deadline, and CMPs help manage user consent signals for Google tags, similar to other GDPR consent management platforms and cookie consent banner solutions.

Ensure you've enabled Consent Mode in your banner settings, and follow the instructions communicated to you by your CMP provider. For easier setup, use google tag manager as your tag manager, or deploy a free, GDPR-compliant cookie consent banner that integrates smoothly with your existing tags.

Otherwise, if you build and maintain your own banner, you must use manual implementation, including consent initialization, so consent mode signals and other consent signals are set before page load completes and before any Google tags fire, following GDPR cookie compliance implementation best practices.

You can then use either basic consent mode or advanced consent mode for implementation. In basic mode, data collection is prevented until consent granted, and if consent denied, no data is sent. This basic mode setup requires a manual restart so full measurement data collection begins only after consent is granted. Advanced mode sends minimal data while waiting for user consent.

What If You Don't Implement Google Consent Mode v2?

If you don't implement GCM v2 before the March deadline, Google Services like Google Analytics 4 and Google Ads won't capture any data about your new users from the EU or EEA, leading to weaker conversion data and less reliable conversion tracking.

Without this data, the effectiveness of your advertising strategies could be severely impacted. Without Consent Mode, Google Ads audience building may also be disabled, which can reduce the effectiveness of google's advertising.

How Is Google Consent Mode v2 Different From v1?

Google Consent Mode v2 is an updated version of the original consent mode and differs by introducing the two additional parameters to Google's consent mode API, ad_user_data and ad_personalization

Laws like the GDPR and DMA regulate how entities can collect, process, and use data from EU/EEA website users, shaping user consent choices to meet data privacy regulations and support data protection for targeted advertising or analytics, which in turn drives the need for robust GDPR compliance tools and software.

By obtaining their opt-in consent, websites can legally use their information to deliver ads or track their analytics behaviors online.

But if those users deny consent and consent denied signals apply, Google Consent Mode v2 uses conversion modeling to estimate total conversions without tracking individual identities. This can support more accurate full measurement data once users have granted consent, while still respecting user consent preferences.

The additional parameters introduced from GCM v2 better align the technology with the legal conditions for consent described in the GDPR and the DMA.

Google Consent Mode v2 vs. Google Additional Consent Mode

Google also recently rolled out another technical specification, called Additional Consent, which is not the same as Google Consent Mode versions 1 or 2, despite the similar names.

Additional Consent is meant to be used alongside the Transparency and Consent Framework (TCF), a voluntary framework from the European Interactive Advertising Bureau (IAB Europe), and understanding what the IAB Transparency & Consent Framework is can clarify how these specifications work together.

Implementing Additional Consent allows ad publishers, registered CMPs, and Google partners to obtain user consent in tandem with the TCF for companies not yet registered with IAB Europe's Global Vendor List, and many organizations start by running a free website cookie checker to understand their current tracking landscape.

Does ComplyDog Support Google Consent Mode v2?

With our new rebrand and overhaul of the platform, ComplyDog's GDPR compliance software and consent management platform fully supports Google Consent Mode v2, with consent settings for Google tags and built in consent checks where relevant through Google Tag Manager integrations.

Google Consent Mode v2 helps websites better align their data collection protocols for targeted advertising and analytics with EU privacy laws, helping teams manage consent states and enable consent mode in line with European Economic Area requirements.

Because of its advanced data-mapping technology, website owners can respect their users' consent preferences without compromising the integrity of their data sets. Once a user interacts with the consent banner, the platform can apply those choices and update consent states accordingly, and these same principles of granular, auditable consent also underpin GDPR-compliant email marketing campaigns and GDPR email marketing consent practices.

Overall, these efforts help create a safer online environment for businesses and consumers.

```

Key Takeaways

• A privacy terms generator can quickly generate privacy policy text tailored to your specific company name, website, app, or ecommerce store, typically in under 5 minutes.

• Modern generators support global privacy laws like the General Data Protection Regulation, California Consumer Privacy Act, CalOPPA, and others—avoiding one-size-fits-all templates.

• Copying someone else’s privacy policy creates legal and accuracy risks; a generator creates unique wording based on how your business actually processes personal data.

• Quality tools cover websites, mobile apps, SaaS products, and other sites while offering free hosting links, HTML embeds, or app store URLs.

• This guide walks you through how to generate a privacy policy, where to publish it, and how to keep it current as privacy regulations evolve.

What Is a Privacy Terms Generator?

A privacy terms generator is an online tool that asks structured questions about your information collection practices, then outputs a ready-to-use privacy policy and related legal terms. Unlike static templates from years past, these platforms create customized policies based on your specific answers.

A privacy policy generator is an online tool that creates a customized, legally compliant, and legally binding privacy policy based on your actual business practices. This differs significantly from copying a free privacy policy template or someone else’s privacy policy, which rarely matches how your operation actually handles data.

Privacy policy generators offer a cost-effective alternative to hiring a lawyer for drafting a standard policy—often saving $1,500-5,000 compared to attorney fees.

What generators can create policies for:

• Ecommerce stores using payment processors and shipping partners

• Mobile apps collecting device data, location, or push notification permissions, which must follow GDPR mobile app compliance guidelines

• SaaS platforms managing customer accounts and team member data, where secure GDPR-compliant API design and security are critical

• Blogs and content sites using analytics, advertising, or newsletter tools

• Free hosting projects and side businesses with basic data collection

Popular privacy policy generators include TermsFeed, Termly, iubenda, and Termageddon. TermsFeed alone has generated policies for over 1.2 million sites since its 2013 launch, while Termly reports 500,000+ users with 99% uptime on hosted policies.

Why You Need a Privacy Policy if You Collect Personal Data

A privacy policy is legally required if you collect personal data from users, regardless of the platform, including websites and mobile apps. Most privacy laws worldwide, including GDPR, CCPA, and PIPEDA, mandate having a privacy policy that outlines how personal data is collected, used, and shared.

The General Data Protection Regulation requires businesses in the EU or those operating in the EU to have a privacy policy that outlines how they collect, use, and protect personal data. Meanwhile, the California Consumer Privacy Act grants California consumers rights regarding their personal data, including the right to request disclosure of the data collected and the right to request deletion of their data.

Common data collection points requiring disclosure:

• Contact forms and newsletter signups

• Checkout pages on ecommerce stores

• Google Analytics and similar tracking tools

• Ad platforms like Google AdSense

• Embedded third-party services (YouTube, social widgets) that often rely on cookies and fall under ePrivacy Directive cookie and communications rules

• Customer loyalty programs storing purchase history

Failure to have a privacy policy can lead to legal liabilities and penalties under various data protection laws, as it is essential for compliance and user trust. By 2025, GDPR fines alone totaled €2.7 billion, with 40% targeting insufficient transparency in privacy notices, underscoring how regulators calculate and apply GDPR fines and penalties to enforce data protection rules.

Beyond legal requirements, a clear privacy policy helps build customer loyalty by demonstrating transparency—differentiating your data practices from other sites that may be less forthcoming about how they handle personally identifiable information.

How a Privacy Terms Generator Works (Step by Step)

A privacy policy generator can help businesses create a compliant privacy policy in just a few minutes by answering a series of guided questions. Most tools follow a straightforward workflow:

Step 1: Select your platform type Choose whether you need a privacy policy for website, mobile apps, desktop app, or combination of platforms. Ecommerce store selections might trigger clauses about payment processors like Stripe.

Step 2: Answer guided questions Typical questions cover your company name, business address, what data you collect, which analytics tools you use, and whether you share information with third parties. Most generators ask 10-30 questions, taking 2-5 minutes to complete.

Step 3: Generate your policy The tool maps your answers to specific clauses. Selecting “California residents” as part of your audience triggers CCPA CPRA opt-out language. Indicating you use Google Analytics adds appropriate tracking disclosures.

Step 4: Publish and implement Export your privacy policy document in your preferred format and add it to your website or app. Many generators provide free hosting URLs for immediate use.

Privacy policy generators typically allow users to customize their policies and download them in various formats, such as HTML or DOCX. The experience emphasizes minimal legal jargon, progress indicators, and instant previews.

Key Features to Look For in a Privacy Terms Generator

Key features of effective privacy policy generators include flexibility, high customization, and compliance with GDPR and CCPA. Privacy policy generators are rated for international legal compliance, custom configurations, and automated updates.

Multi-jurisdiction support:

• GDPR CCPA compliance for EU and California visitors

• UK GDPR for post-Brexit requirements

• Australia Privacy Act provisions

• PIPEDA for Canadian compliance

• Electronic Documents Act considerations where applicable

Customization options:

• Add your exact website name, domains, and app identifiers

• Specify which third-party services you integrate

• Detail your specific data retention periods

• Name your data protection officer if applicable

Technical output formats:

• HTML export for direct embedding

• DOCX for editing in word processors

• Plain text and Markdown options

• Free hosting links for single-URL deployment

Integration helpers:

• Code snippets for WordPress, Shopify, or Wix

• Direct URLs for Google Play and Apple App Store listings

• Embeddable widgets for app privacy policy pages

Tools like iubenda and Termly offer auto-updating policies, which help maintain compliance easily when laws change. Some privacy policy generators automatically update policies when legal requirements change—critical as new laws emerge globally.

Essential Clauses Your Generated Privacy Policy Should Include

The contents of privacy policies vary depending on applicable laws, but they generally need to disclose what personal data is collected, how it is used, and whether it is shared with third parties. A standard privacy policy should include what data you collect from visitors, how you collect it, why you are collecting the data, and how you are using the data.

Information collection and types of data:

• Personal identifiable information (names, emails, phone numbers, addresses)

• Technical data (IP addresses, cookies, device identifiers, log files)

• Payment and billing details for ecommerce transactions

• User-generated content and account preferences

Use of data and legal bases:

• Performance of contract (processing orders, providing services)

• Legitimate interests (fraud prevention, security)

• Consent for email marketing and non-essential cookies

Sharing and disclosure:

• Payment processors handling transactions

• Cloud providers storing data

• Advertising networks (when applicable)

• Clear statement on whether you sell data

Common clauses in a privacy policy include information about cookies, user rights regarding their data, and how users can opt-out of data collection. Cookie consent mechanisms should explain categories (essential, functional, analytics, marketing) and how users control preferences, aligning your implementation with GDPR cookie compliance best practices.

Region-specific rights sections:

• GDPR: access, deletion, correction, portability (1-month response, extendable to 3)

• CCPA CPRA: disclosure, deletion, opt-out of sale/sharing (45-day response)

Additional important details include children’s data protections, links to other sites disclaimers, security practices, retention periods, and change notification procedures.

Using a Generator vs. Copying Someone Else’s Privacy Policy

Privacy laws like the GDPR, CCPA, and PIPEDA require businesses to be transparent about their data collection practices and to inform users about their rights regarding personal data, and many site owners still need a plain-language introduction to GDPR data protection basics. Copying another site’s policy undermines this transparency.

Risks of copying existing policies:

• Copyright infringement (a 2022 settlement, TermsFeed v. Copycat, resulted in $50,000 damages)

• Mismatched disclosures—claiming you don’t use cookies when you do

• Missing platform-specific details for mobile apps or new integrations

• FTC Section 5 violations for deceptive practices

Advantages of using a generator:

• Unique wording based on your actual practices

• Proper disclosure of your specific third-party services

• Clauses matching your actual data collection methods

• 98% plagiarism-free output per analysis tools

Even when using a free generator, review the output carefully. Your privacy policy applies specifically to your business—accept at your own risk any template that doesn’t accurately reflect how your operation handles personal data. Immediately delete or revise any clauses that don’t match your practices.

Where and How to Publish Your Generated Privacy Policy

Your comprehensive privacy policy needs visibility everywhere you collect personal data. Accessibility builds trust and satisfies regulatory requirements.

Website placement:

• Footer links labeled “Privacy Policy” or “Privacy & Cookies”

• Links on signup forms, contact pages, and checkout flows

• Clickwrap consent checkboxes where users actively agree

Mobile app placement:

• Settings or account menus within the app

• App store listing pages (Google Play, Apple App Store require direct URLs)

• First-launch prompts for new users

Ecommerce and SaaS placement:

• Account creation flows

• Subscription checkout pages

• User dashboards and billing sections

Many generators offer free hosting URLs, simplifying deployment across your website or app without managing multiple uploads. Use a single hosted link for consistency.

Always include a “Last updated” date (e.g., “Last updated: May 13, 2026”) so users and regulators can verify currency. App stores reject approximately 5% of listings lacking proper privacy URLs.

Keeping Your Privacy Terms Up to Date

Privacy regulations and your business practices both evolve. A custom privacy policy created in 2024 may contain outdated information by 2026 without regular reviews.

When to update your policy:

• Adding new analytics tools or advertising networks

• Expanding to new geographic markets

• Launching new features that collect additional data

• Annual review regardless of changes

Generators that save your previous answers let you log back in, adjust details about your data collection, and regenerate updated policies instantly. The best privacy policy generators provide free versions or trial periods, making ongoing updates cost-effective.

Privacy policy generators help ensure compliance with major privacy regulations, including GDPR, CCPA/CPRA, and CalOPPA, which continue to evolve through GDPR 2025 updates and new compliance strategies. Keep an internal log documenting when policies changed and why—useful for demonstrating compliance during audits.

Special Considerations for Different Types of Projects

A single generator can typically handle diverse use cases, but outputs must accurately reflect each project type.

Ecommerce stores:

• Disclose payment processor integrations (Stripe, PayPal)

• Name shipping and fulfillment partners

• Detail loyalty programs using customer accounts data

• Address marketing email practices

Mobile apps:

• Specify permissions (location, camera, microphone, contacts)

• Disclose device IDs and push notification usage

• Ensure app continue compliance with platform requirements

• Link app privacy policy in store listings

SaaS and B2B platforms:

• Cover team member data and account management

• Address API integrations and CRM connections

• Explain data retention after subscription cancellation

• Include processor agreements under GDPR Article 28

Content sites and blogs:

• Disclose newsletter subscription practices in line with GDPR-compliant email marketing consent rules

• Address comment system data collection

• Name advertising networks and their tracking

• Cover analytics tracking user behavior and the GDPR compliance tools you rely on to manage data, rights requests, and records

FAQ

Is a free privacy policy generator enough to keep my site compliant in 2026?

Many small websites and apps can start with a free privacy policy generator, which provides a strong baseline for compliance. A free generator can help you create legally compliant documents covering core requirements under GDPR and CCPA. However, complex operations involving sensitive data, healthcare information, or heavily regulated industries may need additional legal review. Treat free tools as your foundation, then layer professional advice for high-risk or multi-jurisdiction scenarios.

Do I need separate privacy policies for my website and mobile apps?

Many businesses can use a single, well-structured website app privacy policy covering both platforms, provided the legal document clearly describes each platform’s data practices. When generating privacy terms, select all relevant platforms (web, iOS, Android) and verify that mobile-specific features like geolocation or push notifications are properly disclosed. App stores require direct URLs to your policy, which generator free hosting options can fulfill.

How often should I update the privacy policy generated by the tool?

Review your privacy policy at least once per year and after any significant change—launching new features, entering new markets, or adding third-party tools. Laws like GDPR and CCPA CPRA expect privacy notices to remain accurate, so outdated information creates compliance issues even if the original policy was acceptable. Use automatic updates features or manually regenerate when your business collects data differently.

Can I use someone else’s privacy policy as a starting point in the generator?

While you can learn from how other sites structure their policies, never copy another company’s privacy policy text directly. Copyright concerns aside, their disclosures likely don’t match your actual practices, creating legal exposure. Instead, note important topics from other sites, then answer the generator’s questions honestly to produce your own custom privacy policy with accurate blank spaces filled in.

What happens if I change analytics tools or add new third-party services later?

Adding or removing analytics, advertising networks, or customer support tools changes how you collect data and share personal information, requiring policy updates. Log back into your generator, update your service list, and produce refreshed terms naming the new tools and their purposes. Schedule compliance checks whenever your tech stack changes to ensure compliance across your operations.

This guide breaks down everything you need to know about meeting your obligations under the General Data Protection Regulation in 2026, from core principles to practical implementation steps.

Key Takeaways

• GDPR compliance is mandatory for any organization processing personal data of people in the European Union, whether the organization is based inside or outside the EU.

• The General Data Protection Regulation has applied since 25 May 2018, and 2025–2027 reforms mainly refine enforcement mechanisms and cross-border cooperation rather than changing the core rules.

• Risks of non compliance include fines up to €20 million or 4% of annual global turnover, whichever is greater, plus significant reputational damage following a data breach.

• GDPR compliance requires businesses to follow a structured framework built on seven core principles, clear legal bases for personal data processing, robust data security, and strong record keeping.

• Cross-border transfers, biometric data, and other special categories require additional safeguards such as Standard Contractual Clauses and Binding Corporate Rules.

What GDPR Compliance Means Today

GDPR compliance means the ability to demonstrate ongoing adherence to the data protection regulation across all processing operations involving EU residents’ information. It is not a checkbox exercise completed once and forgotten, but an ongoing process that requires integrating data protection into every business operation.

Compliance covers how an organization collects, uses, shares, stores, and deletes personal data in any filing system, whether digital databases or structured paper records. Organizations must be able to prove compliance to supervisory authorities at any time through documented policies, access logs, consent records, and clearly recorded decisions about how they handle information.

Even small and medium-sized businesses, universities, and non-profits are fully in scope if they handle data relating to EU residents. Consider an online retailer serving customers in Germany: they must map customer names, addresses, and purchase histories; classify such data by category and purpose; encrypt storage; and log all consents to avoid regulatory action.

Overview of the General Data Protection Regulation

The GDPR is the core data privacy law for the European Union, harmonizing data protection rules across all EU and EEA member states since 25 May 2018. It replaced a patchwork of 27+ national laws with a single, unified framework and provides the foundational GDPR basics organizations must understand.

The regulation serves two purposes: protecting individuals’ data privacy rights while allowing the free flow of personal data within the EU internal market. This balance supports both commerce and fundamental rights.

Critically, the GDPR applies extraterritorially. Organizations outside the EU must comply if they offer goods or services to EU citizens or monitor the behavior of EU residents. This means a US e-commerce site shipping to France or a mobile app tracking user locations in Spain falls within scope.

Supervisory authorities in each country enforce the regulation. France has the CNIL, Ireland the DPC, and the UK (pre-Brexit) the ICO. The European Data Protection Board coordinates these data protection authorities across borders. The 2025 enforcement reforms streamlined cross border processing cases and investigation cooperation rather than rewriting the core obligations organizations must meet, but GDPR 2025 updates and compliance strategies still require close attention from organizations.

Scopes of GDPR: Does It Apply to Your Organization?

Determining whether your organization must comply requires analyzing both material scope (what data and activities) and territorial scope (where the processing occurs and whom it affects).

If you meet either condition, you must treat all covered processing activities as fully subject to GDPR requirements.

Material Scope: Personal Data and Processing Activities

Material scope focuses on the nature of the data and the type of personal data processing performed. The regulation applies whenever you process data in automated systems or maintain structured filing systems that allow retrieval by specific criteria.

Personal data means any information relating to an identified or identifiable natural person. This includes obvious identifiers like names and email addresses, but also extends to:

• IP addresses and device identifiers

• Location data from mobile applications

• Online identifiers and cookies

• Photographs and video footage

The GDPR also defines special categories requiring heightened protection: health information, biometric data used for identification, genetic data, and data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, or information about sex life or sexual orientation.

Processing is interpreted broadly under Article 4(2) to include collection, recording, organization, structuring, storage, access, use, disclosure, alignment, restriction, erasure, and destruction. Almost any operation performed on data relating to individuals qualifies.

Purely personal or household activities fall outside scope—your private address book, for instance. But virtually all business-related data handling triggers compliance obligations.

Territorial Scope: Inside and Outside the European Union

Territorial scope determines whether non-EU organizations must comply when interacting with people located in the EU.

Any controller or processor established in the EU must comply with the regulation, regardless of where servers are located or where staff work. But the regulation reaches further: the GDPR’s extraterritorial application means that even non-EU entities must adhere to its regulations when processing personal data of EU citizens, which can include online services and e-commerce platforms.

Organizations outside the EU must comply with the GDPR if they offer goods or services to EU residents or monitor their behavior within the EU. Triggers include:

• Displaying prices in euros

• Offering shipping to EU countries

• Using language specific to EU markets

• Tracking user behavior through analytics or cookies

A US e-commerce website displaying prices in euros and shipping to Spain clearly falls within scope. Similarly, a mobile app tracking the location of users in the Netherlands triggers compliance obligations even if the company has no EU presence.

Organizations outside the EU should appoint an EU representative when required under Article 27 and document their territorial scope analysis as part of their compliance file.

Key Principles of GDPR Personal Data Processing

Article 5 of the GDPR defines seven key principles that underpin lawful and responsible personal data processing. The GDPR sets forth a series of principles relating to the processing of personal data to ensure the protection of individuals’ privacy rights, outlined in Article 5 of the GDPR.

Organizations must create an actionable plan using these seven principles at the heart of GDPR compliance to ensure compliance with data protection requirements:

Lawfulness, Fairness, and Transparency

Every processing activity must have a valid legal basis under Article 6 and must be understandable to data subjects. The principle of lawfulness of processing mandates that organizations must have a valid legal basis for processing personal data, ensuring compliance with the law as outlined in Article 6 of the GDPR.

Each processing activity must have one of the six lawful bases for processing:

1. Consent – freely given, specific, informed, and unambiguous indication

2. Contract – necessary for performing contractual obligations

3. Legal obligation – required by law

4. Vital interests – protecting someone’s life

5. Public task – exercising official authority vested in the controller

6. Legitimate interests – balanced against the individual’s rights

Organizations must select one primary legal basis for each processing purpose and communicate it clearly in their privacy notice. Avoid dense legal text; use customer-friendly language explaining how data collected is used, who receives it, and how long it is kept.

When relying on legitimate interests for marketing or analytics, document your balancing test. This legitimate interests assessment should explain why your needs outweigh the individual’s rights and be available for regulatory review.

Data Minimization, Storage Limitation, and Accuracy

These data protection principles reduce risk by limiting both the amount and duration of personal data processing.

Data minimization is a key requirement of the GDPR, which mandates that organizations only collect and process the minimum amount of personal data necessary for their intended purpose. For B2B contacts, this might mean collecting only work email addresses rather than full personal profiles including home addresses and personal phone numbers.

Organizations must maintain accurate and up-to-date personal data, which contributes to data security by ensuring that outdated or incorrect information is not retained or processed. Provide easy mechanisms for individuals to correct their information through self-service portals or simple request processes.

The GDPR mandates that personal data should not be retained longer than necessary, encouraging organizations to establish secure data retention and deletion policies. Storage limitation requires:

• Clear retention schedules justified by purpose or legal requirements

• Automated deletion or archiving routines

• Documentation in a formal data retention policy

For example, delete unsubscribe requests from newsletter lists promptly, and archive customer purchase records only as long as required for warranty claims or tax compliance.

Integrity, Confidentiality, and Accountability

Integrity and confidentiality correspond to data security, while accountability covers governance and evidence of compliance.

Implementing technical measures such as encryption, pseudonymization, and anonymization is essential for GDPR compliance. Key security practices include:

• AES-256 encryption at rest and in transit

• Role-based access controls

• Multi-factor authentication

• Regular penetration testing and vulnerability assessments

Organizational measures complement technical controls: staff training, incident response plans, and vendor risk management all contribute to protecting personal data.

Accountability means keeping detailed records of processing activities, decisions about lawful bases, Data Protection Impact Assessments, and responses to data subject requests. Organizations must demonstrate compliance by adhering to accountability and documentation requirements under GDPR.

Consider how documented controls help during a regulatory investigation. When Meta faced its record €1.2 billion fine in 2023 for unlawful EU-US transfers, the depth of their documentation was scrutinized. Organizations with clear records of their decision-making and risk mitigation demonstrate good faith and may receive more favorable treatment.

Special Categories, Biometric Data, and High-Risk Processing

Certain types of information demand extra care and often require additional legal bases and safeguards under Articles 9 and 10.

Special categories of data include:

• Racial or ethnic origin

• Political opinions

• Religious or philosophical beliefs

• Trade union membership

• Genetic data

• Biometric data for identification (fingerprints, facial templates, voiceprints)

• Health data

• Data concerning sex life or sexual orientation

Processing these categories generally requires explicit consent or another stringent basis from Article 9(2). A healthcare provider storing patient health records, or a company using facial recognition for building access control, must implement enhanced protections.

Large-scale processing of special categories, systematic profiling, or deployment of novel technologies like AI-based decision-making often triggers mandatory Data Protection Impact Assessments and broader Privacy Impact Assessment (PIA) processes.

Data Protection Impact Assessments (DPIAs)

Data Protection Impact Assessments must be conducted for high-risk data processing activities. Organizations must operationalize DPIAs to identify and mitigate risks associated with processing activities that may impact individuals’ rights.

A DPIA follows these main steps:

1. Describe – Document the processing operations and their purposes

2. Assess necessity – Evaluate proportionality relative to the purpose

3. Identify risks – Consider impacts on rights and freedoms

4. Define mitigations – Implement measures like pseudonymization or access restrictions

5. Document outcomes – Record decisions and residual risks

Your data protection officer or privacy lead should guide DPIAs and maintain documentation. When residual risks remain high despite mitigations, consult your supervisory authority before proceeding under Article 36.

Conducting DPIAs for AI-driven tools in HR is necessary for ensuring explainability and oversight. Similar assessments apply to large-scale profiling, new biometric systems, or systematic monitoring of public areas.

Operational GDPR Compliance: A Practical Checklist

This section turns legal principles into a concrete, step-by-step GDPR compliance checklist. Following this roadmap helps both EU-based organizations and non-EU companies serving EU residents build a defensible compliance program.

Step 1: Map Personal Data and Create a Processing Register

The first step is cataloguing all personal data processing activities across systems, departments, and third parties.

Build a data inventory capturing:

• Processing purposes

• Data categories and data subject types

• Legal bases for each activity

• Retention periods

• Recipients and transfers

The GDPR requires organizations to maintain a processing register as outlined in Article 30 records of processing activities, which involves keeping records of their data processing activities up to date. Organizations with over 250 employees or those involved in high-risk processing must maintain a detailed Register of Processing Activities (RoPA).

Keep the register living and updated whenever new systems, projects, or vendors are introduced. Include both digital systems and structured paper filing systems to capture full scope.

Step 2: Define Legal Bases and Update Privacy Notices

Review each processing activity and assign a single primary legal basis under Article 6 (or Article 9 for special categories).

Update internal records and external privacy notices to clearly state:

• Specific purposes for each type of data collection

• The legal basis relied upon

• Retention periods

• Data subject rights and how to exercise them

• Contact details for the data protection officer or privacy team

Draft separate explanations for different processing contexts: marketing communications, analytics, HR processing, and product-related data collection each warrant distinct descriptions.

Reserve consent for cases where it is genuinely freely given and easy to withdraw. Consent bundled with terms of service or pre-ticked boxes does not meet GDPR standards. Translate notices for EU markets where necessary to meet transparency obligations.

Step 3: Build a Robust Consent and Cookie Management Framework

Organizations must obtain explicit consent from data subjects to collect, use, or process personal data, ensuring that consent is specific, informed, and unambiguous.

To comply with GDPR, organizations need to build a framework for GDPR consent management, ensuring that consent is specific, clear, and easy to withdraw. Implement:

• Granular checkboxes separate from terms of service

• Double opt-in for high-risk uses like marketing

• Consent logs showing exact text presented and timestamps

Cookie banners and preference centers should follow GDPR cookie compliance best practices and distinguish between:

Provide single-click rejection options and respect browser privacy signals. In 2026, regulators actively scrutinize dark patterns that make rejection difficult.

Step 4: Operationalize Data Subject Rights (DSARs)

The GDPR outlines eight fundamental data subject rights, including the right to access, rectification, erasure, and data portability, which empower individuals to control their personal data.

Organizations should establish a process for handling Data Subject Access Requests (DSARs) under GDPR within one month. Set up:

• Standardized intake channels (web forms, dedicated email addresses)

• Identity verification procedures

• Request tracking and escalation workflows

• Clear responsibilities for response

Data subjects have the right to withdraw consent at any time, which must be as easy to do as giving consent in the first place, ensuring ongoing control over their personal data. Under the GDPR, individuals can request the restriction of processing their personal data, which allows them to limit how their data is used under certain circumstances.

A typical Data Subject Access Request (DSAR) workflow:

1. Receive request via intake channel

2. Verify requester identity

3. Log in tracking system with deadline

4. Gather responsive data across systems

5. Review and redact third-party information

6. Deliver response within one month

7. Document completion

You may refuse or charge for manifestly unfounded or excessive requests, but document your reasoning carefully.

Step 5: Strengthen Data Security and Breach Management

The GDPR requires organizations to implement appropriate technical and organizational measures to ensure a level of security proportional to the risk of data processing activities.

Essential security measures include:

• Network segmentation

• Encryption at rest and in transit

• Secure software development practices

• Regular vulnerability assessments and penetration testing

• Access logging and monitoring

Organizations must prepare an incident reporting and breach management workflow to meet the GDPR’s strict 72-hour notification requirements for data breaches. Your incident response plan should define:

• Roles and responsibilities

• Communication channels

• Investigation procedures

• Notification templates

Example scenario: A laptop containing unencrypted customer data is lost. Response steps:

1. Contain – disable remote access, change credentials

2. Assess – determine what data was exposed and to whom

3. Report – notify the lead supervisory authority within 72 hours

4. Inform data subjects – if high risk to rights and freedoms

5. Document – record timeline, decisions, and remediation

Step 6: Manage Processors, Vendors, and Cross-Border Transfers

Data controllers remain responsible for how data processors handle personal data on their behalf.

Contracts with vendors must include Data Processing Agreements (DPAs) that clearly state their GDPR obligations, covering:

• Processing scope and purpose

• Security requirements

• Subprocessor approval

• Breach notification obligations

• Audit rights

For transfers to third countries without adequacy decisions, use appropriate safeguards:

Document transfer impact assessments when sending data to countries without adequacy, evaluating local surveillance laws and supplementary measures. Cloud services hosting EU personal data require special attention to data localization and contractual protections.

Step 7: Embed Governance, Training, and Continuous Improvement

Assign clear privacy responsibilities across your organization. A Data Protection Officer must be appointed for large-scale or sensitive processing under GDPR. Organizations not meeting mandatory thresholds should still designate a privacy lead responsible for compliance tasks.

Staff training on GDPR should be conducted regularly, ideally at least twice a year, to minimize human error. Keep attendance records for audit purposes.

Privacy policies should be regularly reviewed and updated to reflect changes in data collection or third-party usage. Schedule formal reviews at least annually, with additional reviews for:

• New product launches

• Market expansions

• Technology changes (especially AI-based profiling)

• Regulatory updates

Data protection should be integrated into the project from its inception, known as Privacy by Design. The GDPR emphasizes the principle of data protection by design and by default, which requires organizations to integrate data protection into their processing activities and business practices from the design stage across the entire data processing lifecycle.

Annual audits of data processing activities and security measures are a requirement for GDPR compliance. Internal audits or external assessments validate program effectiveness and identify gaps before regulators do.

Record Keeping, Filing Systems, and Demonstrating Compliance

Regulators expect organizations to provide documented evidence of how they comply with GDPR obligations. The ability to demonstrate compliance through records separates organizations that merely claim compliance from those that can prove it.

Article 30 records of processing activities must include:

For Controllers:

• Controller name and contact details

• Processing purposes

• Categories of data subjects and personal data

• Recipients including third countries

• Transfer safeguards

• Retention periods

• Security measures description

For Processors:

• Processor and controller names

• Processing categories

• Transfers and safeguards

• Security measures

Maintain logs of:

• Consent records and withdrawal requests

• DPIA assessments and outcomes

• Data breach investigations and notifications

• Training attendance

• Policy review dates

Organize documentation in central repositories with appropriate access controls. Establish retention schedules for compliance records themselves—seven years is common practice for audit trails and DPIAs.

Consequences of Non Compliance and Recent Enforcement Trends

Non compliance can lead to severe financial penalties, corrective measures, and lasting damage to customer trust.

The GDPR establishes two tiers of fines for violations, with the severity of the penalty depending on the nature of the infringement:

Under the GDPR, organizations can face fines of up to 4% of their annual global revenue or €20 million, whichever is greater, for violations. In addition to fines, data subjects have the right to seek compensation for damages resulting from violations of the GDPR.

Supervisory authorities can also:

• Order processing to stop

• Mandate specific remediation steps

• Require public notification of breaches

• Ban international data transfers

Cumulative fines have reached €7.1 billion since 2018 across over 2,500 cases, with €1.2 billion issued in 2025 alone, as outlined in recent GDPR fines and penalties enforcement guides. Recent enforcement trends focus on:

• Consent validity and dark patterns in cookie banners

• Transparency failures in privacy notices

• Cross-border data transfers post-Schrems II

• Insufficient security measures (consistently among top violation categories)

Proactive cooperation with authorities and a well-documented compliance program can significantly mitigate outcomes after a personal data breach. Organizations demonstrating compliance through thorough records and good-faith remediation efforts typically face better treatment than those with poor documentation.

FAQ about GDPR Compliance

Does GDPR apply if my company has no legal entity in the EU?

Yes. The GDPR applies to any organization that processes personal data of individuals located in the EU, regardless of whether the organization is based in the EU or outside of it. If your company offers goods or services to people in the EU or monitors their behavior, you must comply.

Such organizations may need to appoint an EU representative under Article 27 and must meet the full set of GDPR obligations for in-scope processing. A US-based SaaS vendor with EU customers, for example, cannot avoid compliance simply because they have no European office.

How often should we review and update our GDPR compliance program?

Conduct a formal review at least once per year. Additional reviews are necessary when launching new products, entering new markets, or adopting new technologies like AI-based profiling or automated processing.

Update your processing register, DPIAs, privacy notices, and data security measures whenever significant organizational or legal changes occur. Document each review cycle to demonstrate continuous improvement and accountability to supervisory authorities.

Do small businesses really need a Data Protection Officer?

A DPO is mandatory only in specific situations: when core activities involve large-scale systematic monitoring, large-scale processing of special categories of personal data, or when the organization is a public authority exercising official authority vested in it.

Small businesses not meeting these thresholds can appoint a privacy lead or team responsible for compliance tasks instead. Consider factors like the number of EU customers, scope of profiling activities, and whether you process health or biometric data when assessing your requirements.

Is pseudonymised data still considered personal data under GDPR?

Yes. Pseudonymisation reduces direct identifiability but does not fully anonymize data. Because the information can still be linked back to individuals using additional information, it remains personal data under GDPR.

The GDPR encourages pseudonymisation as a security and privacy measure, particularly for analytics and testing environments. However, only truly anonymized data—where individuals can no longer be identified by any reasonably likely means—falls outside GDPR scope entirely.

What’s the difference between Standard Contractual Clauses and Binding Corporate Rules?

Standard Contractual Clauses are pre-approved contractual templates used between separate organizations to legitimize international data transfers. They work well for vendor relationships and cloud service providers, requiring no regulatory approval before use.

Binding Corporate Rules are internal codes of conduct approved by supervisory authorities that allow multinational groups to transfer personal data within their own group of companies. They require significant investment to establish but provide flexibility for large, integrated global operations with frequent intra-group data flows.

That might work for a quick listicle. It does not help if you are actually trying to choose the right platform.

Because the truth is, most GDPR software is built for the wrong company.

It is built for enterprises with privacy teams, legal ops, procurement cycles, and broader governance needs. It is built for companies managing multiple frameworks at once. It is often built for teams that can afford a long implementation, a heavy setup, and software that needs ongoing ownership.

That is not most SaaS companies. It is not most startups. It is not most ecommerce teams either.

If your goal is simply to get GDPR compliant, stay compliant, and prove it when asked, most tools in this category create more work than they remove.

That is the core problem. And it is also the easiest way to understand the market.

What GDPR compliance software should actually do

At its best, GDPR compliance software should take a repetitive, operational problem and make it boring.

That means helping you:

• handle data subject requests without manual tracking
• manage cookie consent properly
• automate DPA workflows
• keep compliance records in one place
• provide proof of compliance when customers, partners, or regulators ask for it

That is the real job to be done.

Not building a giant privacy program.
Not turning your compliance stack into a six month implementation project.
Not paying enterprise prices for features you will never touch.

The best GDPR software does not just give you more control. It removes work.

Why most GDPR software feels heavier than it should

Most of the big names in this category did not start by solving GDPR for lean software teams.

They started somewhere else.

Some started in security compliance. Some started in privacy program management. Some started in data discovery and governance. GDPR got added later, often as one module inside a broader platform.

That origin matters, because it shapes the product.

When a tool is built for audit workflows first, GDPR becomes something you adapt to the platform.

When a tool is built for enterprise governance first, GDPR becomes one workstream among many.

When a tool is built for data intelligence first, GDPR becomes downstream of a much bigger data architecture problem.

That is why so many companies end up with software that looks impressive in a demo but feels excessive in practice.

The three types of GDPR compliance software

1. Enterprise privacy platforms

This is where tools like OneTrust and TrustArc sit.

They are designed for large organisations that need broad privacy management capabilities across multiple regulations, teams, and workflows.

That breadth can make sense at enterprise scale.

It also tends to come with more setup, more internal ownership, and more complexity than smaller teams actually need.

2. Compliance automation platforms

This is where Vanta fits.

Vanta is best known for security and compliance automation around frameworks like SOC 2 and ISO 27001. GDPR can be part of that wider setup, but it is not the centre of gravity.

If you are solving for audit readiness across multiple frameworks, that can be useful.

If you are trying to solve GDPR operationally, it can be the wrong starting point.

3. Purpose-built GDPR software

This is where ComplyDog fits.

Instead of treating GDPR as one requirement inside a broader system, ComplyDog is focused entirely on GDPR. That means the product is built around the workflows that matter, not around enterprise sprawl.

That focus changes the experience dramatically.

You are not configuring a privacy program. You are getting GDPR handled.

Why focus matters more than feature count

A lot of GDPR buying decisions go wrong because teams compare tools by how much they can do.

More modules.
More dashboards.
More workflows.
More coverage.

On paper, that sounds safer.

In practice, it often means paying for software that assumes your company is much larger, more regulated, and more operationally complex than it really is.

The better question is:

How much of the GDPR workload does this tool actually remove?

A focused product can beat a bigger product when the job is clear.

ComplyDog vs Vanta

Vanta alternative for GDPR compliance

Vanta is a compliance automation platform designed for frameworks like SOC 2 and ISO 27001.

That makes it strong for audit workflows and security controls.

But GDPR is not its core focus.

When GDPR sits inside a broader compliance platform, it often lacks depth in operational workflows like DSAR handling, consent management, and documentation.

ComplyDog takes a different approach.

It is built entirely for GDPR:

• DSARs handled end-to-end
• DPA workflows automated
• Consent managed natively
• No audit-first complexity

Further reading:

• https://complydog.com/alternatives/vanta
• https://complydog.com/blog/vanta-data-leak

ComplyDog vs OneTrust

OneTrust alternative for GDPR compliance

OneTrust is one of the most widely used privacy platforms.

It offers broad capabilities across governance, vendor risk, and multi-regulation compliance.

That breadth makes it powerful, but also complex.

For smaller teams, it often means:

• Long implementation cycles
• Higher costs
• Ongoing internal ownership

ComplyDog is built for a different use case.

• No implementation project
• No ongoing management
• Built specifically for GDPR

Further reading:

• https://complydog.com/alternatives/onetrust
• https://complydog.com/blog/onetrust-vs-complydog-privacy-management-platform-comparison-saas

ComplyDog vs TrustArc

TrustArc vs ComplyDog comparison

TrustArc is designed for structured privacy programs.

It includes:

• Risk assessments
• Data inventory
• Reporting tools

It is a strong platform for enterprises.

But it still requires:

• Active management
• Setup effort
• Internal ownership

ComplyDog removes that overhead.

It is designed for teams that want GDPR handled without building a full privacy program.

ComplyDog vs DataGrail

DataGrail vs ComplyDog comparison

DataGrail focuses on privacy rights management, especially DSAR workflows.

It is more focused than enterprise platforms, but still requires:

• Integrations
• Workflow setup
• Ongoing coordination

ComplyDog handles the full GDPR lifecycle in one place:

• Requests
• DPAs
• Consent
• Documentation

Without requiring integrations or complex setup.

ComplyDog vs BigID

BigID vs ComplyDog comparison

BigID is a data intelligence platform focused on:

• Data discovery
• Classification
• Governance

It is useful for large organisations with complex data environments.

But GDPR for most companies is not a data discovery problem.

It is an execution problem.

ComplyDog focuses on execution:

• Handling obligations
• Maintaining records
• Providing proof

Without requiring a data platform.

What makes ComplyDog different

ComplyDog is not trying to be everything.

It is focused entirely on GDPR.

That focus allows it to:

• Get companies compliant quickly
• Remove ongoing operational work
• Provide transparent pricing
• Keep everything in one place

It is built for founders and small teams who do not have time to manage compliance systems.

Final thoughts

The GDPR software market looks crowded until you realise most tools are built for different types of companies.

Some are built for enterprises.
Some are built for security compliance.
Some are built for data infrastructure.

Very few are built for teams that just want GDPR handled.

That is where ComplyDog fits.

Because for most growing companies, the goal is not to manage GDPR more effectively.

It is to stop worrying about it.

FAQ

What is the best GDPR compliance software for startups?

The best GDPR compliance software for startups is the one that removes the most manual work without introducing enterprise complexity.

Is OneTrust too complex for smaller teams?

Yes, it can be. It is designed for broader privacy management, which often makes it excessive for smaller teams.

Is Vanta a GDPR tool?

Vanta includes GDPR features, but it is primarily a compliance automation platform for frameworks like SOC 2.

Why does transparent pricing matter?

Transparent pricing helps avoid long sales cycles, hidden costs, and unexpected pricing increases.

You know you need it. You know it matters. But it rarely feels worth the time it takes to get right.

So most teams do one of two things. They either ship something basic and move on, or they get pulled into a tool that turns a simple task into a long setup process.

We think there’s a better middle ground.

That’s why we rebuilt the ComplyDog cookie consent banner from scratch.

Designed for how teams actually work

ComplyDog exists for founders and small teams who don’t have time to become GDPR experts.

The goal has always been simple. Get compliant quickly, stay compliant without thinking about it.

The cookie banner should follow the same logic.

Not something you configure endlessly. Something you set up once and forget about.

What changed

The update isn’t about adding more features. It’s about removing friction.

Customization is now straightforward. You can match the banner to your brand without digging through layers of settings or second guessing what each option does. It’s fast, and it feels obvious.

The UI has been rebuilt to be calmer and more focused. There’s no clutter, no unnecessary steps, just a clear path from setup to done.

And the design itself has been rethought. Cookie banners don’t need to look like compliance tools. They should feel like part of your product. Minimal, structured, and intentional.

Because when something sits on every page of your site, it shouldn’t feel like an afterthought.

Compliance, without the overhead

There’s a pattern we see a lot.

Compliance tools tend to overcomplicate simple things. They assume time, resources, and attention that most teams don’t have.

ComplyDog takes the opposite approach.

Everything is built to be clear, direct, and usable without explanation. Less like a legal document, more like a knowledgeable friend who just handles it for you :contentReference[oaicite:0]{index=0}

The new cookie banner is a small part of that, but it reflects the same philosophy.

Free when you need it. More when you’re ready.

The cookie banner is completely free to use.

No trial. No credit card. No hidden limits.

If all you need is a clean, compliant banner, you can try it here.

When you need more, the full ComplyDog plan goes further. It handles data subject requests, automates DPA signing, and gives you a hosted compliance portal you can share with customers and partners.

Everything lives in one place. Set up in under an hour, and then it runs in the background.

GDPR. On Guard.

GDPR compliance is something every company knows they need, but very few know how to communicate.

Behind the scenes, you might be doing everything right. Handling data subject requests. Managing DPAs. Running compliant consent flows. But none of that is visible to the people who matter most.

When someone lands on your website, they are not reading your internal processes. They are making a quick judgment.

Can I trust this company with my data?

That moment is where compliance either works for you, or disappears entirely.

That is why we have introduced ComplyDog GDPR Compliance Badges.
They are designed to make compliance visible, not just operational.

Making compliance something people can see

Trust on the internet is built in seconds.

Users do not read legal documents. They scan. They look for signals. They decide quickly whether something feels safe.

Most companies rely on privacy policies buried in the footer. Necessary, but invisible.

A GDPR badge changes that.

It gives users an immediate, recognizable signal that your business takes data protection seriously and has the systems in place to back it up.

Instead of asking users to assume you are compliant, you show them.

Designed to feel like part of your product

Most compliance elements feel bolted on. Ours do not.

The ComplyDog badges are part of a broader design system built around clarity, structure, and calm. The goal is not just to say “you are compliant”, but to make it feel handled.

Something users do not need to worry about.

The badges come in multiple formats, including light and dark modes, versions designed for imagery, and minimal inline variants for tighter layouts. They are built to integrate naturally into modern products without disrupting the design.

At the same time, they are intentionally consistent.

They are not meant to be modified, recolored, or restyled. Consistency is what gives them meaning. If every company presents the badge differently, the signal weakens. If it is used correctly, it becomes instantly recognizable.

From hidden compliance to visible trust

Compliance has traditionally lived in the background.

Something implemented to meet requirements. Rarely something communicated.

But expectations have changed.

Customers care how their data is handled. They want reassurance before they sign up, before they purchase, before they share anything.

A GDPR badge bridges that gap.

It connects the work happening behind the scenes with the experience users have on the surface. It turns compliance into something tangible.

It signals that your business is not just aware of GDPR, but actively managing it. Requests are handled. Agreements are in place. Nothing is left to chance.

Built for teams that do not have time to overthink compliance

ComplyDog exists to make GDPR fast, affordable, and maintenance free.

You should be able to get compliant quickly, and then move on.

The badges are a natural extension of that idea.

Once your compliance is set up, you should be able to show it just as easily.

No long explanations. No repeated reassurance. Just a clear signal that does the job for you.

Adding a badge to your site

Getting started takes minutes.

Download your badge, place it where it matters, and let it do its job.

For most companies, that is the footer. A consistent, expected place where users look for trust signals.

In other cases, it might sit closer to conversion. Signup flows, checkout pages, or anywhere a user is deciding whether to continue.

Wherever it appears, the goal is the same.

Make compliance visible at the moment it matters.

Download your GDPR badge

Compliance. Visible.

Most companies treat compliance as something users will never notice.

We think that is a missed opportunity.

Trust is not built in backend systems or documentation. It is built in small moments, when someone decides whether they feel comfortable moving forward.

The ComplyDog GDPR badge is a simple way to support that decision.

GDPR. On Guard.

GDPR is not something most founders want to think about. It is not a feature, not a differentiator, not something anyone wakes up excited to work on. It is just something that needs to be done, correctly, and ideally once.

But the way compliance software presents itself often makes things worse. It turns a boring problem into a complicated one. It introduces legal language, dashboards, workflows, and ongoing effort where there should be none.

From the beginning, ComplyDog took a different approach. Handle the problem fully, keep it simple, and get out of the way.

The product has followed that philosophy for a long time. The brand had not.

Why we changed it

Over time, ComplyDog evolved into something more complete.

It now handles data subject requests, automates DPA signing, manages cookie consent, and gives companies a compliance portal they can share externally. Everything lives in one place, and everything is designed to be set up quickly and then run without constant attention.

But the way we presented ourselves still felt like a typical compliance tool.

Too functional. Too generic. Not reflective of what the product actually does, which is remove an entire category of work from your plate.

So the rebrand was not about changing direction. It was about finally aligning how ComplyDog looks, sounds, and communicates with what it already is.

What we wanted it to feel like

The starting point was not visual.

It was a feeling.

Using ComplyDog should feel like relief.

You set it up, and then you stop worrying about GDPR. No ongoing maintenance, no constant checking, no second-guessing whether you missed something.

That idea runs through the entire new brand.

The tone is clear and direct, more like talking to someone who understands the problem than reading a legal document.

The personality is warm, approachable, and precise. Confident without being intimidating.

Because trust in compliance does not come from sounding complex. It comes from being clear.

A visual system that reflects the product

The new identity builds on that same idea.

At the center is a geometric dog mark, structured and symmetrical, but softened enough to stay approachable. It reflects the balance the product tries to strike, bringing order and logic to something messy, without feeling heavy or corporate.

Around it, everything is designed to reduce noise.

The color palette is grounded and deliberate. Deep blue anchors the brand with authority, while warmer tones add depth without distraction. Neutral backgrounds keep everything calm and readable.

The imagery moves in a different direction than most SaaS brands. Instead of dashboards or abstract graphics, it uses open skies. Bright, uncluttered, and expansive.

It is a simple metaphor. When compliance is handled, things feel clear again.

GDPR. On Guard.

The new tagline says it simply:

GDPR. On Guard.

ComplyDog is not something you actively manage. It is something that runs in the background, watching what needs to be watched, handling what needs to be handled.

You do the setup once. After that, it stays on guard.

What stays the same

Underneath all of this, the product has not changed in its core purpose.

It is still built for founders and small teams who do not have the time or desire to become compliance experts.

It still aims to get you compliant quickly and keep you that way without ongoing effort.

The rebrand simply makes that clearer.

Where this goes next

This is not a cosmetic update.

It is a foundation.

A clearer brand makes it easier to build, easier to communicate, and easier for the right people to understand what ComplyDog is for.

There is still a lot to improve in the product. More automation, fewer edge cases, less manual work.

But the direction stays the same.

Make compliance something you set up once, and then stop thinking about.

A final note

ComplyDog exists to take a boring, necessary task off your plate.

That idea guided the product from the start. Now it guides the brand too.

If it feels simpler, clearer, and more focused, then it is doing its job.

And if it means you spend less time thinking about GDPR at all, even better.

But here's the reality check: only 29% of European organizations feel genuinely prepared to handle future incidents. Healthcare and education sectors lag behind, while IT, financial services, and retail demonstrate stronger readiness. This gap between threat levels and preparedness creates serious risks for businesses operating in or with the European Union.

The EU responded by building one of the world's most robust regulatory frameworks for cybersecurity. These regulations protect businesses, consumers, and critical infrastructure from evolving digital threats. Understanding and implementing these requirements isn't optional anymore. It's a survival skill for modern enterprises.

Table of contents

• Why EU cybersecurity compliance matters for your business
• The European cybersecurity regulatory landscape
• Key organizations shaping EU cybersecurity
• Core EU cybersecurity regulations
  • EU Cybersecurity Act
  • EU Cybersecurity Strategy
  • Network and Information Systems Directive
  • NIS2 Directive
  • GDPR and cybersecurity obligations
  • Digital Operational Resilience Act
  • European Cybersecurity Certification Framework
• Industry-specific compliance requirements
• Implementation roadmap for EU cybersecurity compliance
• Common compliance challenges and solutions
• Future of EU cybersecurity regulations
• Streamline compliance with automation

Why EU cybersecurity compliance matters for your business

Regulatory compliance in the EU goes beyond checking boxes. It establishes transparency, accountability, and ethical business practices while safeguarding consumer rights. Organizations that treat compliance as a strategic asset gain competitive advantages.

The benefits extend across multiple dimensions:

Legal protection and risk mitigation: Non-compliance carries severe consequences. GDPR violations can result in fines up to €20 million or 4% of global annual revenue (whichever is higher). NIS2 penalties reach €10 million or 2% of worldwide turnover. Beyond fines, organizations face operational restrictions, reputational damage, and potential legal action from affected parties.

Market access and competitive positioning: EU compliance certifications open doors. They demonstrate commitment to security standards that customers, partners, and regulators expect. Companies with strong compliance programs win contracts that require proven security practices.

Operational efficiency: Streamlined compliance processes reduce manual work and human error. Automated monitoring, policy enforcement, and evidence collection cut compliance efforts by up to 70% while improving accuracy. Teams spend less time on administrative tasks and more time on strategic security initiatives.

Customer trust and brand value: Data breaches erode consumer confidence quickly. Organizations with robust compliance frameworks protect customer data, maintain trust, and preserve brand reputation. Studies show that 87% of consumers won't do business with companies they don't trust to handle data responsibly.

Supply chain requirements: Large enterprises increasingly require vendors to meet specific compliance standards. Third-party risk management has become a critical procurement factor. Suppliers without proper certifications lose business opportunities.

The global reach of EU regulations means organizations outside Europe must comply if they process EU resident data or provide services to EU markets. Financial services, healthcare, technology, and e-commerce sectors face particularly strict requirements.

The European cybersecurity regulatory landscape

EU cybersecurity regulations evolved from basic awareness initiatives in the early 2000s to comprehensive frameworks addressing sophisticated threats. This progression reflects the changing nature of cyber risks and the growing digital economy.

Key milestones shaped the current landscape:

2004: The EU established ENISA (European Network and Information Security Agency) to provide cybersecurity expertise and support member states.

2013: The EU Cybersecurity Strategy introduced pan-European cooperation frameworks for cyber defense, recognizing that threats cross borders freely.

2016: Two landmark regulations arrived. The Network and Information Security (NIS) Directive became the first EU-wide cybersecurity law. GDPR established stringent data protection standards. Both took effect in 2018.

2019: The EU Cybersecurity Act granted ENISA permanent status and created the European Cybersecurity Certification Framework, standardizing security certifications across member states.

2020-2023: Rapid expansion occurred. The Digital Operational Resilience Act (DORA) proposal emerged in 2020 for financial services. The NIS2 Directive proposal followed the same year to strengthen the original NIS framework. Both became law by 2023.

2024-2025: The Cyber Resilience Act introduced security requirements for digital products, including IoT devices. Targeted amendments expanded managed security services coverage. The regulatory framework continues evolving to address emerging threats.

This regulatory evolution demonstrates the EU's commitment to proactive cybersecurity governance. Regulations adapt to technological advances, threat landscapes, and lessons learned from major incidents.

Key organizations shaping EU cybersecurity

Several organizations drive EU cybersecurity policy, implementation, and coordination. Understanding their roles helps organizations identify relevant resources and obligations.

ENISA (EU Agency for Cybersecurity): The cornerstone of European cybersecurity efforts. ENISA develops policy recommendations, coordinates incident response, maintains the European Cybersecurity Certification Framework, and provides technical expertise to member states. The agency operates as the primary knowledge hub for cybersecurity best practices.

CSIRTs Network: Computer Security Incident Response Teams from each member state collaborate through this network. They share threat intelligence, coordinate responses to cross-border incidents, and provide operational support during cyber crises. ENISA serves as the network secretariat.

European Cybersecurity Certification Group (ECCG): This group assists the European Commission in developing and maintaining certification schemes. Members include representatives from national certification authorities and ENISA.

ECSO (European Cyber Security Organisation): A contractual counterpart to the European Commission, ECSO represents the cybersecurity industry. It brings together companies, research centers, universities, and associations to promote European cybersecurity capabilities and innovation.

European Energy Information Sharing and Analysis Centers (EE-ISACs): Sector-specific organizations focused on energy infrastructure. They facilitate information sharing about threats targeting critical energy systems.

Joint Research Center (JRC): The European Commission's science and knowledge service. JRC provides independent scientific advice and technical support to EU policymakers on cybersecurity matters.

These organizations work in concert to create, implement, and enforce cybersecurity standards across the EU's 27 member states.

Core EU cybersecurity regulations

Multiple regulations form the EU cybersecurity framework. Each addresses specific aspects of digital security while complementing other regulations.

EU Cybersecurity Act

Adopted in June 2019, this Act transformed ENISA from a temporary agency into a permanent institution with expanded responsibilities and resources. The regulation addresses two primary objectives: strengthening ENISA's operational capacity and establishing a unified certification framework.

ENISA's expanded mandate includes:

• Preparing technical groundwork for cybersecurity certification schemes
• Maintaining a public website with information about certification schemes and issued certificates
• Supporting member states with cyber incident response coordination
• Assisting in large-scale cross-border cyberattack management
• Operating as secretariat for the CSIRTs Network

A January 2026 proposal further expanded ENISA's role. The agency will issue early alerts about cyber threats, support ransomware recovery efforts with Europol and CSIRTs, develop a common vulnerability management service, and operate the single-entry point for incident reporting under the Digital Omnibus initiative.

The Act also tackles ICT supply chain security. Recent incidents highlighted vulnerabilities from third-country suppliers with cybersecurity concerns. The revised framework establishes a trusted ICT supply chain using harmonized, proportionate, and risk-based approaches.

A 2023 amendment extended certification to managed security services. This covers incident response, penetration testing, security audits, and cybersecurity consultancy. Certification ensures quality and reliability for these sensitive services that companies rely on for prevention, detection, and recovery.

EU Cybersecurity Strategy

Released in December 2020, the EU Cybersecurity Strategy promotes cyber resilience while maintaining an open digital economy. The strategy emphasizes EU cyber sovereignty, ensuring member states control their cybersecurity capabilities while protecting critical sectors.

Three initiatives form the strategy's core:

EU Cyber Shield: A pan-European network of Security Operations Centers (SOCs) using AI and advanced tools for real-time threat detection and response. This initiative aims to create coordinated monitoring capabilities across the EU.

Joint Cyber Unit (JCU): Proposed in June 2021, the JCU coordinates operational responses to major incidents. It serves as a collaborative platform for EU institutions, member states, and private sector partners to streamline crisis response and threat intelligence sharing.

Legislative strengthening: The strategy drove proposals for the NIS2 Directive, the Critical Entities Resilience (CER) Directive for infrastructure protection, and enhanced cyber diplomacy initiatives.

The strategy also promotes investment in cybersecurity research, innovation, and secure European internet infrastructure like DNS4EU (a European DNS resolver service).

Network and Information Systems Directive

The original NIS Directive, implemented by May 2018, represented the first EU-wide cybersecurity legislation. It established baseline security requirements for operators of essential services (OES) and digital service providers (DSPs) across finance, energy, healthcare, and transport sectors.

The directive focused on three areas:

National capabilities: Member states must develop Computer Security Incident Response Teams (CSIRTs), implement risk management frameworks, and adopt national cybersecurity strategies.

Cross-border collaboration: The CSIRTs Network and NIS Cooperation Group facilitate information sharing and coordinated incident response across borders.

Supervision and enforcement: National competent authorities oversee compliance, ensure risk management implementation, and verify incident reporting for significant security events.

While groundbreaking at its introduction, the NIS Directive faced limitations in scope, inconsistent implementation across member states, and outdated threat models. These shortcomings led to NIS2.

NIS2 Directive

The NIS2 Directive replaced the original NIS framework, entering force on January 16, 2023. Member states had until October 17, 2024 to transpose it into national law. NIS2 significantly expands cybersecurity obligations across industries and company sizes.

Key changes include:

Broader scope: NIS2 covers more sectors including public administration, space, postal services, and waste management. It applies to medium and large companies, eliminating the previous OES/DSP distinction. Approximately 28,700 companies fall under NIS2, including 6,200 small and medium enterprises.

Risk-based approach: Organizations must implement cybersecurity measures proportional to their risk exposure. This includes supply chain security, system resilience, and business continuity planning.

Stricter incident reporting: Organizations must report significant incidents without undue delay (ideally within 24 hours of detection). An initial notification goes to authorities, followed by a detailed report within one month. This accelerated timeline reflects the need for rapid threat intelligence sharing.

Enhanced enforcement: Non-compliance penalties reach €10 million or 2% of annual global turnover. Personal liability extends to management in some cases. Authorities gain broader supervisory powers including on-site inspections and security audits.

Coordinated vulnerability disclosure: NIS2 establishes frameworks for identifying and addressing cybersecurity vulnerabilities across the EU, promoting transparency about security flaws.

The regulation aims to harmonize cybersecurity standards across member states, reducing fragmentation and improving collective defense capabilities.

GDPR and cybersecurity obligations

While primarily a data protection regulation, GDPR contains significant cybersecurity requirements. Adopted in 2016 and enforceable since May 2018, GDPR applies to any organization processing personal data of EU/EEA residents, regardless of the organization's location.

GDPR's cybersecurity dimensions include:

Data breach notification: Organizations must report personal data breaches to supervisory authorities without undue delay, and where feasible within 72 hours. If a breach poses high risk to individuals' rights and freedoms, affected persons must be notified directly.

Privacy by design and default: Security measures must be integrated into products and services from inception. Organizations should minimize data collection and processing to what's necessary for stated purposes.

Technical and organizational measures: GDPR requires appropriate security measures including encryption, pseudonymization, access controls, regular security testing, and incident response procedures. These measures should reflect the state of the art and the risk level.

Accountability requirements: Organizations must maintain Records of Processing Activities (RoPA), conduct Data Protection Impact Assessments (DPIAs) for high-risk processing, and appoint Data Protection Officers (DPOs) when required (public authorities, large-scale monitoring, or special category data processing).

Penalties for violations: GDPR uses a tiered fine structure. Serious violations incur fines up to €20 million or 4% of global annual revenue. Lesser infractions face fines up to €10 million or 2% of turnover.

GDPR applies throughout EU member states and the European Economic Area (Iceland, Liechtenstein, Norway). It works alongside NIS2, DORA, and the EU Cybersecurity Act to create comprehensive protection for personal data and digital systems.

Digital Operational Resilience Act

Enforced from January 2023 with a compliance deadline of January 17, 2025, DORA establishes uniform ICT risk management rules for financial entities. It harmonizes EU financial cybersecurity policies with global standards.

DORA applies to banks, investment firms, insurance companies, payment service providers, crypto-asset service providers, and financial market infrastructures. Third-party ICT service providers to these entities also fall within scope.

Core requirements include:

ICT risk management: Financial institutions must implement comprehensive cybersecurity controls covering network security, threat detection, encryption, incident response, access management, and business continuity planning.

Third-party risk management: Organizations must assess cyber risks from cloud providers, software vendors, and other ICT service providers. This includes due diligence, contractual security requirements, and ongoing monitoring.

Incident reporting: Initial reports must reach regulators within four hours of incident detection. A detailed follow-up report is due within 72 hours. This rapid reporting enables swift regulatory response and threat intelligence distribution.

Operational resilience testing: Regular cybersecurity stress tests, vulnerability assessments, and Threat-Led Penetration Testing (TLPT) for high-risk entities verify the ability to withstand attacks and maintain financial stability.

Information sharing: DORA encourages financial entities to share threat intelligence and security best practices, strengthening collective resilience across the financial sector.

The regulation addresses the financial sector's unique risk profile where operational disruptions can trigger systemic crises affecting multiple institutions and broader economic stability.

European Cybersecurity Certification Framework

Established under the EU Cybersecurity Act, this framework provides voluntary (unless mandated) certification for ICT products, services, and processes. It addresses market fragmentation where different member states had incompatible certification schemes.

The framework offers three assurance levels:

Organizations choose assurance levels based on risk assessments considering the intended use, threat landscape, and potential impact of security failures.

Benefits of the certification framework:

• Single certification recognized across all EU member states
• Reduced compliance costs from eliminating multiple certifications
• Increased transparency about product security capabilities
• Enhanced customer trust through independent verification
• Market differentiation for certified products

A 2026 proposal aims to simplify procedures, establishing a default 12-month timeline for developing new certification schemes. This accelerates the framework's responsiveness to emerging technologies and threats.

Industry-specific compliance requirements

Different sectors face tailored compliance obligations reflecting their unique risk profiles and societal importance.

Financial services: DORA applies alongside GDPR and NIS2. Financial institutions must maintain high operational resilience given their systemic importance. Payment systems, trading platforms, and banking infrastructure face particularly strict requirements.

Healthcare: Medical data represents special category data under GDPR, requiring enhanced protection. Healthcare providers must secure patient records, medical devices, and telemedicine platforms while maintaining service availability. NIS2 classifies healthcare as a critical sector with mandatory security measures.

Energy and utilities: Power generation, transmission networks, and water systems fall under NIS2 as essential services. The EE-ISACs coordinate sector-specific threat intelligence. Supply chain security receives special attention due to reliance on industrial control systems.

Transportation: Aviation, maritime, rail, and road transport infrastructure must comply with NIS2. Connected vehicles and traffic management systems introduce new attack surfaces requiring specialized security measures.

Digital infrastructure: Cloud service providers, data centers, content delivery networks, and internet exchange points face strict requirements under NIS2. These organizations enable other sectors' digital operations, making their security fundamental to the broader economy.

Public administration: Government services, including digital government platforms, must meet NIS2 standards. Citizen data protection under GDPR creates additional obligations.

Each sector requires specialized knowledge of relevant threats, operational constraints, and regulatory nuances. Organizations often engage sector-specific consultants and compliance experts to address industry requirements.

Implementation roadmap for EU cybersecurity compliance

Organizations should follow a structured approach to achieve and maintain compliance:

Phase 1: Scoping and assessment (Months 1-2)

Determine which regulations apply based on your industry, company size, geographic presence, and data processing activities. Conduct gap assessments comparing current security posture against regulatory requirements. Identify critical vulnerabilities and compliance gaps requiring immediate attention.

Phase 2: Governance and documentation (Months 2-4)

Establish a compliance governance structure with clear roles and responsibilities. Appoint a Data Protection Officer (if required) and cybersecurity officers. Document policies, procedures, and security controls. Create Records of Processing Activities (RoPA) for GDPR. Develop incident response plans meeting NIS2 reporting timelines.

Phase 3: Technical implementation (Months 4-8)

Deploy security controls addressing identified gaps. Implement encryption, access management, network segmentation, and monitoring systems. Configure security information and event management (SIEM) tools for threat detection. Establish secure backup and recovery procedures.

Phase 4: Third-party risk management (Months 6-9)

Assess vendor security practices and contractual obligations. Map data flows to third parties. Implement ongoing vendor monitoring and periodic reviews. Ensure contracts include appropriate security clauses and liability provisions.

Phase 5: Training and awareness (Ongoing)

Train employees on security policies, data protection requirements, and incident reporting procedures. Conduct regular awareness campaigns. Test phishing resilience and social engineering defenses. Build a security-conscious culture.

Phase 6: Testing and validation (Months 9-12)

Perform vulnerability assessments and penetration testing. Conduct tabletop exercises for incident response. Review and update security controls based on test results. Prepare for regulatory audits or inspections.

Phase 7: Certification (Months 12-18)

Pursue relevant certifications like ISO 27001, SOC 2, or EU Cybersecurity Certification Framework schemes. Engage accredited certification bodies. Undergo formal audits and address findings.

Phase 8: Continuous improvement (Ongoing)

Monitor regulatory changes and emerging threats. Update policies and controls as needed. Conduct regular risk assessments. Maintain evidence of compliance activities for regulatory requests.

This roadmap should be adapted based on organizational size, complexity, and risk profile. Smaller organizations might compress timelines, while large enterprises with complex infrastructures require longer implementation periods.

Common compliance challenges and solutions

Organizations face predictable obstacles when implementing EU cybersecurity compliance programs:

Challenge: Resource constraints

Small and medium enterprises struggle to allocate sufficient budget and personnel to compliance efforts. Security expertise is expensive and scarce.

Solution: Prioritize high-risk areas first. Use automation tools to reduce manual effort. Consider managed security service providers (MSSPs) for specialized capabilities. Many compliance platforms offer affordable options tailored for SMEs.

Challenge: Regulatory complexity

Understanding which regulations apply and how they interact creates confusion. Requirements span multiple documents with overlapping obligations.

Solution: Start with a compliance matrix mapping requirements to your organization's activities. Engage legal and compliance experts for interpretation. Join industry associations that provide guidance and best practices.

Challenge: Legacy systems

Older infrastructure lacks modern security features. Updating or replacing legacy systems is costly and disruptive.

Solution: Implement compensating controls like network segmentation, enhanced monitoring, and privileged access management. Develop a phased modernization plan prioritizing highest-risk systems.

Challenge: Third-party dependencies

Organizations rely on numerous vendors, each introducing potential vulnerabilities. Assessing and monitoring third-party security practices is labor-intensive.

Solution: Use vendor risk management platforms to automate assessments. Standardize vendor security questionnaires. Include security requirements in procurement processes from the outset.

Challenge: Incident reporting timelines

NIS2's 24-hour reporting requirement is aggressive, especially for organizations lacking 24/7 security operations.

Solution: Implement automated detection and alerting systems. Establish clear escalation procedures. Consider security operations center (SOC) services for continuous monitoring.

Challenge: Evidence collection for audits

Gathering documentation proving compliance is time-consuming. Organizations often lack centralized evidence repositories.

Solution: Use compliance management platforms that automatically collect and organize evidence. Implement continuous controls monitoring rather than point-in-time assessments.

Challenge: Cross-border operations

Companies operating in multiple countries must reconcile EU requirements with other jurisdictions' laws, sometimes creating conflicts.

Solution: Design data governance frameworks that meet the most stringent requirements. Use data localization strategies where needed. Engage legal experts familiar with international data transfer mechanisms.

Proactive planning and appropriate tooling can overcome most compliance challenges. The investment in proper systems pays dividends through reduced audit costs, faster certification, and lower breach risk.

Future of EU cybersecurity regulations

The regulatory landscape will continue evolving as technology advances and threats proliferate.

Artificial intelligence governance: The EU AI Act, adopted in 2024, introduces requirements for AI systems based on risk levels. Cybersecurity for AI systems (protecting models from attacks) and AI for cybersecurity (using AI for threat detection) will receive increased attention. Expect ENISA to develop AI-specific certification schemes.

Quantum computing preparedness: Quantum computers threaten current encryption standards. The EU will likely mandate quantum-resistant cryptography timelines and post-quantum cryptographic migration plans.

IoT and connected device security: The Cyber Resilience Act already addresses IoT security. Future regulations will expand requirements as connected devices proliferate in homes, vehicles, and industrial settings. Expect mandatory security updates and end-of-life support obligations.

Supply chain transparency: Recent geopolitical tensions highlight supply chain vulnerabilities. The EU will strengthen requirements for ICT supply chain security, potentially restricting certain high-risk suppliers in critical infrastructure.

Simplified compliance for SMEs: Recognizing the burden on small businesses, the EU proposed simplifications in January 2026. Expect more proportionate requirements and standardized templates that reduce compliance costs for smaller entities.

Enhanced cross-border cooperation: As cyber threats ignore borders, the EU will strengthen operational cooperation mechanisms. The Joint Cyber Unit will expand capabilities. Real-time threat intelligence sharing will become standard practice.

Integration with sectoral regulations: Cybersecurity requirements will be increasingly embedded in sector-specific regulations rather than handled separately. This creates more tailored obligations reflecting industry realities.

Increased enforcement: Member states are building cybersecurity enforcement capacity. Expect more frequent audits, larger fines, and public disclosure of violations. Authorities will target egregious cases to establish deterrence.

Organizations should monitor regulatory developments through ENISA publications, industry associations, and legal advisors. Building flexible compliance programs that adapt to regulatory changes reduces future implementation costs.

Streamline compliance with automation

Manual compliance management doesn't scale. Organizations waste countless hours collecting evidence, tracking policy changes, and preparing for audits. Automation transforms compliance from a burden into a strategic advantage.

Modern compliance platforms offer several capabilities:

Continuous controls monitoring: Automated systems check security controls constantly rather than at audit time. This identifies gaps immediately, reducing risk windows.

Evidence collection: Integration with cloud services, identity providers, and security tools automatically gathers proof of compliance. No more scrambling before audits.

Policy management: Centralized policy repositories with version control, approval workflows, and automated distribution ensure everyone works from current policies.

Risk assessments: Automated questionnaires, scoring, and risk heat maps identify high-priority areas needing attention.

Vendor management: Platforms streamline vendor assessments, contract reviews, and ongoing monitoring. Automated alerts flag when vendor certifications expire.

Reporting and dashboards: Real-time compliance status visibility helps executives understand risk posture and make informed decisions.

Multi-framework support: Leading platforms map controls across GDPR, ISO 27001, SOC 2, and other frameworks, eliminating duplicate work.

ComplyDog provides these capabilities specifically designed for GDPR and EU cybersecurity compliance. The platform reduces compliance workload by automating evidence collection, maintaining continuous compliance monitoring, and preparing audit-ready documentation.

Organizations using ComplyDog achieve GDPR compliance faster while spending less time on administrative tasks. The platform's automation capabilities free security teams to focus on strategic initiatives rather than manual documentation.

And let's be honest: compliance automation isn't just about efficiency. It's about accuracy. Humans make mistakes when manually tracking hundreds of controls across multiple frameworks. Software doesn't forget to collect evidence or miss policy updates.

For organizations serious about EU cybersecurity compliance, automation has moved from nice-to-have to necessary. The regulatory burden will only increase. Tools that streamline compliance provide competitive advantages while protecting against the costly consequences of non-compliance.

The EU's cybersecurity framework represents some of the world's most comprehensive protection standards. Compliance requires investment, but the alternative carries unacceptable risks. Organizations that approach compliance strategically, with proper tooling and expert guidance, turn regulatory obligations into market differentiators.

When a machine learning model trains on terabytes of information, sensitive details can slip through unnoticed. Customer records, financial data, proprietary business intelligence - all potentially woven into neural networks where they become difficult to detect and nearly impossible to remove. And that's just one problem.

The regulatory landscape has shifted dramatically. GDPR enforcement actions now regularly target AI deployments, with fines reaching tens of millions of euros for companies that fail to protect training datasets properly. Recent cases demonstrate that regulators view AI systems as extensions of data processing infrastructure, subject to the same strict requirements.

But governance for AI training data extends beyond avoiding penalties. Organizations need frameworks that address data quality, lineage tracking, bias prevention, and ethical use while still enabling innovation. Getting this balance right separates companies that successfully scale AI from those that stumble into compliance disasters.

Table of contents

• What makes AI training data governance different
• Core components of training data governance
• Security risks in training datasets
• Data lineage and transparency requirements
• Quality assurance for machine learning inputs
• Regulatory compliance across jurisdictions
• Ethical considerations and bias mitigation
• Roles and responsibilities framework
• Building a governance implementation roadmap
• Monitoring and continuous improvement
• Common implementation failures
• Integration with existing data governance

What makes AI training data governance different

Traditional data governance focuses on structured databases and predictable data flows. You know what information goes where, who accesses it, and how it gets used. AI training changes that equation completely.

Training datasets often contain hundreds of millions of records pulled from disparate sources. Data scientists might combine customer interactions, sensor readings, text documents, images, and third-party feeds into a single training pipeline. Each source introduces its own governance challenges.

Once information trains into a model, it doesn't simply get stored in a queryable format. Neural networks encode patterns and relationships in ways that make it extremely difficult to identify what specific data influenced which outputs. A model might have learned from someone's personal information without any obvious way to trace that connection.

The flexible nature of AI interfaces creates new attack vectors. Users interact through natural language rather than structured forms. This openness means carefully crafted prompts can potentially extract training data or manipulate outputs in unexpected ways. Prompt injection attacks represent just one example of risks that didn't exist with traditional software.

Model behavior can also drift over time. A system that performed accurately during testing might generate biased or incorrect results months later as data distributions shift. Continuous monitoring becomes necessary rather than optional.

Testing AI systems presents unique challenges too. With traditional applications, you can write test cases covering all major functionality paths. AI outputs depend on probabilistic calculations across billions of parameters. Comprehensive testing becomes prohibitively expensive, if not impossible.

Core components of training data governance

Effective governance for AI training data requires multiple interconnected capabilities working together. Organizations need clear frameworks addressing each component.

Data classification and labeling

Every dataset entering a training pipeline needs proper classification. This includes identifying personal information, financial records, health data, and any other regulated content. Automated classification tools help scale this process, but human oversight remains critical for edge cases.

Metadata tagging should capture data sensitivity levels, usage restrictions, retention requirements, and legal obligations. These labels need to propagate through transformation pipelines so downstream processes inherit appropriate controls.

Access controls and permissions

Not everyone building AI systems should access all training data. Role-based permissions need to reflect both job functions and data sensitivity. Data scientists working on customer segmentation models might need different access than those developing fraud detection systems.

Access logs should capture who viewed or modified training datasets, when they did so, and what operations they performed. Audit trails become critical for investigating potential breaches or demonstrating compliance during regulatory reviews.

Data minimization practices

AI teams often request more data than models actually need. Governance frameworks should enforce data minimization principles, limiting collection and retention to what's necessary for specific use cases. This reduces exposure if security incidents occur.

Anonymization and pseudonymization techniques can reduce risks when full datasets aren't required. Differential privacy methods add noise to training data in ways that protect individual privacy while maintaining statistical utility. These approaches require careful implementation to avoid introducing bias.

Validation and quality controls

Training data quality directly impacts model performance. Validation processes should check for accuracy, completeness, consistency, and timeliness. Automated quality checks can flag missing values, outliers, duplicate records, and format inconsistencies.

Data profiling helps identify potential quality issues before training begins. Understanding distributions, correlations, and anomalies in source data prevents surprises later. Quality metrics should be tracked over time to detect degradation.

Documentation requirements

Comprehensive documentation creates accountability and enables troubleshooting. Teams should maintain records describing data sources, collection methods, transformation logic, and intended uses. This documentation supports both operational needs and regulatory obligations.

Model cards or data sheets provide standardized formats for documenting AI systems. These documents describe training data characteristics, known limitations, intended use cases, and performance across different populations. Creating them forces teams to think critically about their models.

Security risks in training datasets

Sensitive information embedded in training data creates vulnerabilities that persist throughout a model's lifecycle. Organizations face several distinct security threats.

Data poisoning attacks

Adversaries can inject malicious data into training sets to compromise model behavior. A small percentage of corrupted records can cause models to misclassify specific inputs or behave unpredictably. These attacks are particularly concerning when training data comes from public sources or user-generated content.

Defenses include validating data sources, implementing anomaly detection during ingestion, and monitoring for unexpected model behavior changes. Isolation of training environments from production systems limits potential damage.

Model inversion and extraction

Attackers can query trained models to reconstruct sensitive training data. Techniques like membership inference determine whether specific records were included in training datasets. Model extraction attacks attempt to replicate proprietary models by analyzing their outputs.

Protections include rate limiting queries, adding noise to outputs, and monitoring for suspicious access patterns. Differential privacy techniques during training can mathematically bound information leakage about individual records.

Prompt injection vulnerabilities

Natural language interfaces enable users to craft inputs that manipulate model behavior. Prompt injection can cause models to ignore safety constraints, leak training data, or execute unintended operations. These attacks exploit the flexible reasoning capabilities that make large language models valuable.

Input validation and output filtering provide partial defenses. Separating user prompts from system instructions using special tokens or architectural constraints helps. Organizations should assume determined attackers will find new injection techniques and plan accordingly.

Insider threats

Employees with authorized access to training data pose significant risks. Whether through malice or negligence, insiders can exfiltrate sensitive information, introduce backdoors, or misuse data for unauthorized purposes. Technical controls alone cannot fully mitigate these threats.

Least privilege access principles limit what each person can view or modify. Separation of duties ensures no single individual controls entire pipelines. Regular access reviews identify and revoke unnecessary permissions. Security awareness training helps employees recognize risks.

Data lineage and transparency requirements

Understanding where data originates and how it flows through AI systems enables troubleshooting, compliance demonstrations, and impact assessments. Lineage tracking becomes more complex with AI than traditional analytics.

Training pipelines often chain together dozens of transformation steps. Raw data gets cleaned, normalized, augmented, and sampled before model training. Intermediate datasets might be cached or stored temporarily. Tracking these operations requires specialized tooling.

Lineage documentation should capture source systems, extraction methods, transformation logic, and dependencies between datasets. Visual representations help teams understand complex data flows. Automated lineage tools can discover relationships by analyzing code and metadata.

When issues arise, lineage information accelerates root cause analysis. If a model generates incorrect predictions, tracing back through training data helps identify whether source data, transformations, or model architecture caused the problem. Without lineage visibility, debugging becomes guesswork.

Regulatory requirements increasingly mandate transparency about data processing. GDPR gives individuals rights to understand how their information gets used. Demonstrating compliance requires showing what data trained which models and how those models make decisions. Incomplete lineage documentation creates legal exposure.

Third-party data introduces additional complexity. Organizations using external datasets for training need clear documentation of licensing terms, usage restrictions, and data provider responsibilities. Lineage should capture these contractual obligations so teams know what limitations apply.

Quality assurance for machine learning inputs

Poor quality training data leads directly to unreliable models. Organizations need systematic approaches for validating data before it enters pipelines.

Completeness checks

Missing values can cause training failures or introduce bias. Validation should identify fields with high percentages of nulls and assess whether missingness correlates with sensitive attributes. Imputation strategies need documentation justifying why specific approaches were chosen.

Incomplete records might need exclusion from training sets if they would compromise model quality. Thresholds for acceptable missingness should reflect use case requirements and potential bias implications.

Accuracy verification

Training data should represent ground truth as closely as possible. For supervised learning, labels must correctly identify what models should predict. Incorrect labels directly teach models wrong patterns.

Spot checks and statistical sampling help assess accuracy at scale. Cross-referencing with authoritative sources validates key fields. Crowdsourcing or expert review can verify labels for ambiguous cases. Accuracy metrics should be tracked over time.

Consistency validation

Data from multiple sources might conflict or use different formats. Inconsistencies in units, encodings, or definitions cause confusion during training. Standardization processes should enforce consistent representations.

Referential integrity checks ensure related records align properly. Duplicate detection prevents overrepresenting certain patterns. Format validation confirms data types and structures match expectations.

Timeliness assessment

Stale data might not reflect current patterns. Training on outdated information can cause models to make decisions based on obsolete relationships. Temporal validation confirms data freshness matches requirements.

For time-series data, gaps or irregular sampling intervals require attention. Training data should span appropriate timeframes for intended use cases. Seasonal patterns might necessitate data from multiple periods.

Bias detection

Training data can contain historical biases that models will learn and perpetuate. Statistical analysis should examine distributions across demographic groups and sensitive attributes. Underrepresentation of certain populations can cause poor performance for those groups.

Bias mitigation might involve resampling, reweighting, or collecting additional data. Documentation should explain what biases were identified and what steps addressed them. Some bias might be impossible to fully eliminate given available data.

Regulatory compliance across jurisdictions

AI systems must satisfy data protection requirements in every jurisdiction where they operate or process data. Regulations increasingly address AI specifically while existing frameworks apply to training data.

GDPR obligations

European data protection law treats AI training as processing subject to its full requirements. Organizations need lawful bases for collecting and using personal information. Consent, legitimate interests, or contractual necessity might justify training data processing depending on circumstances.

Data minimization principles require limiting collection to what's necessary. Retention periods should reflect legitimate needs rather than indefinite storage. Purpose limitation means data collected for one reason cannot automatically be repurposed for AI training without additional legal basis.

Transparency obligations require explaining to individuals how their data trains AI systems. Privacy policies should describe model types, intended uses, and decision-making logic. When AI makes solely automated decisions with legal or significant effects, additional protections apply.

Data subject rights create ongoing obligations. Individuals can request access to their data, corrections to inaccuracies, or deletion. Honoring deletion requests becomes complicated when information has trained deployed models. Organizations need strategies for addressing these situations.

California Consumer Privacy Act

CCPA grants California residents rights over their personal information. Businesses collecting data from California consumers must provide notice about AI training uses. Consumers can opt out of sales or sharing that includes training data.

Organizations need processes for verifying identity when consumers exercise rights. Deletion requests require removing data from training datasets and potentially retraining models. Documentation demonstrating compliance becomes important if regulators investigate.

Industry-specific regulations

Healthcare organizations training AI on protected health information must satisfy HIPAA requirements. Financial institutions face obligations under regulations like GLBA. These sector-specific rules layer on top of general data protection frameworks.

Some jurisdictions have enacted AI-specific regulations. The EU AI Act classifies systems by risk level and imposes requirements accordingly. High-risk applications face stringent obligations around training data, documentation, and human oversight.

Cross-border data transfers

Training data often flows across international boundaries. Organizations need mechanisms like Standard Contractual Clauses or adequacy decisions to legitimize transfers out of the EU. Transfer impact assessments evaluate whether recipient countries provide adequate protection.

Some countries restrict data localization, requiring certain information to remain within their borders. These requirements can complicate global AI deployments. Understanding applicable rules for each jurisdiction where data originates becomes necessary.

Ethical considerations and bias mitigation

Technical compliance with regulations represents a floor, not a ceiling. Organizations should consider broader ethical implications of their AI training practices.

Fairness across populations

Models can perform differently for various demographic groups even when trained on representative data. Protected characteristics like race, gender, or age should not inappropriately influence predictions. Testing should measure performance disparities.

Defining fairness proves challenging because mathematical definitions often conflict. A model optimized for demographic parity might sacrifice individual fairness or equality of opportunity. Organizations need to decide which fairness criteria matter for their use cases.

Mitigation strategies include reweighting training examples, adjusting decision thresholds for different groups, or adding fairness constraints during optimization. Each approach involves tradeoffs that require careful consideration.

Transparency and explainability

Individuals affected by AI decisions deserve to understand how those decisions were made. Complex models make this challenging. Techniques like LIME or SHAP provide post-hoc explanations by identifying influential features.

Documentation should explain model logic in accessible language. Technical accuracy matters less than helping stakeholders understand general decision processes. Transparency builds trust and enables meaningful oversight.

Some use cases might require simpler, more interpretable models even if complex approaches achieve slightly better accuracy. The ability to explain and audit decisions can outweigh marginal performance gains.

Purpose limitation

Just because data could train a model doesn't mean it should. Organizations should carefully consider whether proposed AI uses align with why information was originally collected. Repurposing data for unrelated training applications raises ethical questions.

Seeking input from affected communities before deploying AI systems demonstrates respect and can surface concerns early. Stakeholder engagement helps organizations understand potential harms they might have overlooked.

Human oversight

Fully automated decision-making with no human involvement carries risks. Many organizations implement human-in-the-loop approaches where AI assists but doesn't replace human judgment. This becomes especially important for consequential decisions.

Clear escalation paths should exist when AI systems behave unexpectedly or stakeholders contest outputs. Flagging mechanisms let users report concerning behavior. Output overrides allow experts to correct mistakes.

Roles and responsibilities framework

Effective AI training data governance requires clear accountability. Organizations should define roles that address both technical and policy dimensions.

Data stewards

Stewards take responsibility for specific datasets used in AI training. They understand data lineage, quality requirements, and usage restrictions. Stewards make day-to-day decisions about data access and serve as points of contact for questions.

Data scientists should consult stewards before incorporating new data sources into training pipelines. Stewards can explain limitations, suggest alternatives, or flag compliance concerns. This partnership prevents problems before they occur.

AI ethics committee

A cross-functional group reviewing proposed AI applications ensures diverse perspectives inform decisions. Committee members might include legal counsel, security experts, business leaders, and ethicists. Their mandate covers evaluating use cases for potential harms.

The committee reviews training data sources, model architectures, and deployment plans. They can require additional safeguards, testing, or documentation before approving projects. Having a formal review process demonstrates governance maturity.

Compliance officers

Specialists focused on regulatory requirements help teams satisfy legal obligations. They interpret how regulations apply to specific AI use cases and training practices. Compliance teams also manage regulatory communications and respond to data subject requests.

Officers should participate in project planning rather than reviewing work after completion. Early involvement prevents costly redesigns when compliance gaps emerge late in development.

Security teams

Information security professionals assess and mitigate risks throughout AI lifecycles. They design access controls, monitor for threats, and respond to incidents. Security teams need sufficient AI literacy to understand risks specific to machine learning systems.

Collaboration between security and data science teams prevents conflicts. Security shouldn't blindly block all data access, while data scientists shouldn't circumvent necessary protections. Finding balanced approaches requires ongoing dialogue.

Business owners

Every AI system needs an executive sponsor accountable for its outcomes. Business owners make final decisions about accepting risks, allocating resources, and prioritizing competing requirements. They represent organizational leadership in governance discussions.

Owners should understand key risks and limitations even if they lack technical expertise. Regular briefings keep them informed as projects evolve. When issues arise, owners decide on appropriate responses.

Building a governance implementation roadmap

Organizations need structured approaches for establishing AI training data governance. A phased implementation reduces overwhelm and builds capabilities over time.

Phase one: Assessment and planning

Start by inventorying existing AI systems and training data sources. Document what models are deployed, what data trains them, and what governance controls currently exist. Gap analysis identifies areas needing attention.

Prioritize based on risk. High-sensitivity applications or those processing large volumes of personal information warrant immediate focus. Lower-risk projects can follow later. Resource constraints make prioritization necessary.

Engage stakeholders across functions to understand their needs and concerns. Data scientists might prioritize access and speed while compliance teams emphasize controls. Finding common ground shapes realistic roadmaps.

Define success metrics. Quantifiable goals might include percentage of training datasets classified, number of models with documented lineage, or time to respond to data subject requests. Metrics provide accountability and measure progress.

Phase two: Foundation building

Implement core infrastructure enabling governance at scale. This includes metadata repositories, lineage tracking tools, and access management systems. Technical foundations support policy enforcement.

Develop and communicate policies addressing AI training data. Policies should define requirements for data classification, access controls, quality validation, and documentation. Written standards create consistency.

Train teams on new requirements and available tools. Data scientists need to understand why governance matters and how to comply efficiently. Change management prevents resistance.

Phase three: Process integration

Incorporate governance checkpoints into existing workflows. Data validation should happen automatically during ingestion. Model review processes should require documentation before deployment. Making governance invisible to the extent possible reduces friction.

Automate compliance checks where feasible. Automated scanning for sensitive data prevents manual oversight gaps. Continuous monitoring detects drift or anomalies without manual effort. Automation scales governance to match AI initiatives.

Phase four: Monitoring and improvement

Establish ongoing measurement of governance effectiveness. Regular audits assess compliance with policies. Metrics track key indicators like data quality, access patterns, and incident response times. Reviews identify opportunities for improvement.

Collect feedback from teams subject to governance requirements. Are processes too burdensome? Do tools meet needs? Iterative refinement based on practical experience makes governance more effective and sustainable.

Monitoring and continuous improvement

Governance programs need mechanisms for detecting issues and adapting to changing conditions. Static approaches become obsolete quickly.

Key performance indicators

Organizations should track metrics reflecting governance health:

• Percentage of training datasets with complete metadata and classification
• Average time to respond to data subject requests affecting training data
• Number of quality issues detected before model training vs. after deployment
• Percentage of models with documented lineage and approved use cases
• Access review completion rates and number of inappropriate permissions identified
• Security incidents related to training data and mean time to resolution

Trends matter more than point-in-time measurements. Improvements or degradations over time indicate whether governance capabilities are strengthening.

Audit procedures

Periodic reviews assess compliance with policies and identify gaps. Internal audits might occur quarterly or annually depending on risk profiles. External audits provide independent validation for stakeholders.

Sample-based testing checks whether controls function as designed. Auditors might review access logs, test data classification accuracy, or verify documentation completeness. Findings inform remediation priorities.

Incident response

Despite best efforts, incidents will occur. Organizations need playbooks for responding when training data gets exposed, models behave unexpectedly, or compliance violations happen. Clear procedures accelerate effective responses.

Post-incident reviews identify root causes and preventive measures. Learning from failures improves future governance. Blame-free cultures encourage reporting problems early.

Regulatory tracking

Data protection and AI regulations evolve constantly. Dedicated effort to monitor regulatory developments prevents surprises. Changes might require updating policies, implementing new controls, or modifying training practices.

Industry groups and professional associations provide helpful regulatory intelligence. Legal counsel should interpret how new requirements apply to specific organizational circumstances.

Common implementation failures

Several patterns derail AI training data governance efforts. Recognizing these pitfalls helps organizations avoid them.

Treating governance as purely technical

Technology alone cannot solve governance challenges. Tools enable policy enforcement but don't substitute for clear requirements and accountable ownership. Organizations over-investing in platforms while neglecting processes often struggle.

Governance requires cultural change as much as technical implementation. Teams need to understand why requirements exist and feel empowered to raise concerns. Check-box compliance without genuine commitment proves fragile.

Excessive centralization or fragmentation

Some organizations create governance bottlenecks by routing all decisions through small central teams. Overburdened gatekeepers slow innovation while missing important details. Scaling requires distributed responsibility.

Conversely, fully decentralized approaches where every team creates their own policies lead to inconsistency. Shared standards and central oversight of key risks need to balance with empowered teams making day-to-day decisions.

Ignoring data science workflows

Governance requirements that don't account for how data scientists actually work face resistance and evasion. Controls should integrate naturally into existing tools and processes. Forcing teams into clunky workarounds breeds resentment.

Involving practitioners in designing governance approaches surfaces practical constraints early. Data scientists often suggest creative solutions balancing control needs with efficiency.

Inadequate resources

Governance programs need sufficient staffing, budget, and executive sponsorship to succeed. Expecting teams to absorb significant new responsibilities without additional resources sets up failure. Underfunded initiatives accomplish little.

Leadership commitment matters. When executives clearly prioritize governance and allocate resources accordingly, organizations make progress. When governance gets treated as optional overhead, it withers.

One-size-fits-all requirements

Different AI use cases carry different risk profiles. Chatbots providing general information warrant different controls than systems making credit decisions. Proportionate governance matching actual risk enables both protection and innovation.

Overly rigid standards that ignore context create unnecessary burdens for low-risk projects. Risk-based approaches concentrate effort where it matters most.

Integration with existing data governance

Most organizations already have data governance programs. AI training data governance should build on rather than replace existing capabilities.

Traditional data governance addresses cataloging, quality, security, and compliance for analytics and operational systems. These foundations support AI initiatives too. Training datasets likely come from sources already governed under existing frameworks.

Extending current policies to cover AI training represents a natural evolution. The same data classification schemes can apply. Access control principles remain relevant. Quality processes need adaptation but not wholesale replacement.

Some organizations create separate "AI governance" programs that duplicate existing data governance functions. This wastes resources and creates confusion about accountability. Better to expand the scope of unified governance encompassing all data uses including AI.

Areas requiring AI-specific attention include model risk management, bias testing, and explainability. These capabilities might not exist in traditional data governance. Building them as extensions of core governance creates coherence.

Governance tools supporting AI should integrate with existing infrastructure. Metadata repositories, data catalogs, and access management systems need to accommodate AI-specific requirements without becoming entirely separate systems.

Cross-functional collaboration between traditional data governance teams and AI practitioners strengthens both. Data stewards bring expertise about data quality and compliance. Data scientists contribute understanding of technical constraints and opportunities. Partnership produces better outcomes than either group working in isolation.

Maintaining governance frameworks that address both traditional and AI use cases positions organizations to adapt as technology evolves. The lines between analytics, AI, and operational systems continue to blur. Flexible governance approaches remain relevant despite technical changes.

How compliance software helps

Managing AI training data governance manually becomes overwhelming as organizations scale their AI initiatives. Compliance platforms provide centralized capabilities that reduce burden and improve effectiveness.

Modern compliance software helps organizations maintain visibility across training datasets, automatically classify sensitive information, and enforce access controls. These platforms track data lineage through complex AI pipelines, making it easier to demonstrate regulatory compliance and troubleshoot issues when they arise.

ComplyDog offers integrated capabilities specifically designed for GDPR requirements affecting AI systems. The platform helps organizations document processing activities, respond to data subject requests, and maintain the detailed records regulators expect. Automated workflows reduce time spent on manual compliance tasks while providing audit trails that demonstrate accountability.

Rather than building custom tooling or juggling spreadsheets, teams can rely on purpose-built software that understands both data protection regulations and AI governance needs. This allows organizations to focus resources on innovation while maintaining the governance foundations that enable responsible AI deployment.

For companies serious about scaling AI while satisfying regulatory obligations, compliance platforms like ComplyDog provide the infrastructure that makes governance practical rather than theoretical.

This isn't just another regulatory box-ticking exercise. The DGA represents a fundamental shift in how Europe thinks about data sharing, trust, and economic growth. While GDPR told us what we can't do with personal data (and boy, did it make that clear), the Data Governance Act takes a different approach. It's about what we can do, under the right conditions, with both personal and non-personal data.

And here's the thing: the DGA doesn't exist in isolation. It's part of a bigger picture called the European Strategy for Data, which aims to create a genuine single market for data across all 27 EU member states. Think of it as the infrastructure layer that makes data sharing practical, trustworthy, and legally sound.

But let's be honest. Most businesses are still wrapping their heads around what this means for daily operations. Data intermediaries, data altruism organizations, public sector data reuse… these aren't exactly terms that roll off the tongue at Monday morning meetings.

Table of contents

• What the Data Governance Act actually does
• The four pillars of the DGA
• Data intermediation services explained
• Data altruism and why it matters
• Public sector data reuse mechanisms
• Common European data spaces
• Who needs to comply and when
• How the DGA differs from GDPR
• Recent enforcement actions and what they tell us
• The Digital Omnibus proposal and what comes next
• Practical compliance requirements
• Implementing DGA compliance with ComplyDog

What the Data Governance Act actually does

The DGA creates a framework for data sharing that didn't exist before. Yes, we had data protection rules. Yes, we had open data directives. But we didn't have a coherent system for trustworthy data intermediation or mechanisms to encourage voluntary data sharing for societal benefit.

The regulation tackles three main scenarios:

First, it establishes conditions for reusing certain categories of protected public sector data. This is data that can't be released as open data because it contains commercial secrets, personal information, or intellectual property rights. Think health records that could advance medical research or transport data that might improve traffic management.

Second, it creates a notification and supervision framework for data sharing services. These are the intermediaries that connect data holders with data users. The DGA sets rules to ensure these intermediaries operate fairly and transparently.

Third, it builds a voluntary registration system for data altruism organizations. These are entities that collect data from individuals or companies who want to make it available for the common good, like scientific research or public policy development.

The scope is broad but specific. Article 1 makes clear that the DGA applies throughout the Union and covers both personal and non-personal data. But it doesn't override sector-specific legislation. If you're in a regulated industry with existing data sharing rules, those still apply.

The four pillars of the DGA

The regulation stands on four distinct structural elements. Each addresses a different barrier to data sharing that existed before September 2023.

Pillar 1: Public sector data reuse

Not all government data can be open data. Some of it is too sensitive, too commercially valuable, or too personal. But that doesn't mean it shouldn't be accessible under controlled conditions.

The DGA requires public sector bodies to publish the conditions under which they'll allow data reuse. They must establish transparent procedures for requesting access. And they need to ensure that these conditions are fair and non-discriminatory.

This matters for research institutions, policy analysts, and businesses that could derive value from government datasets. The barriers to access get lowered, but protections remain in place.

Pillar 2: Data intermediation services

This pillar creates a new category of trusted data broker. These intermediaries must remain neutral. They can't use the data they handle for purposes beyond facilitating its exchange. The DGA requires them to operate in a separate legal entity to avoid conflicts of interest.

Article 11 lays out eleven specific conditions these service providers must meet. They range from ensuring fair access procedures to maintaining high security standards to implementing competition compliance programs.

Pillar 3: Data altruism

Here's where the DGA gets interesting from a societal perspective. Data altruism means making data available voluntarily for purposes that serve the general interest. Climate research. Public health studies. Urban planning initiatives.

The regulation creates an EU register of recognized data altruism organizations. These entities get a special logo (adopted through an implementing regulation in August 2023) that identifies them as trustworthy. The QR code on the logo links directly to the public register.

Pillar 4: Cross-sector data sharing facilitation

The fourth pillar addresses technical and legal barriers to moving data across sectors and borders. It's about making sure the right data reaches the right purpose at the right time. Standardization. Interoperability. Findability.

This pillar connects directly to the Common European Data Spaces initiative, which we'll get to in a moment.

Data intermediation services explained

Let's get practical about what a data intermediation service actually looks like.

These aren't cloud storage providers. They're not data brokers in the traditional sense. They're not content platforms. The DGA specifically excludes several types of services from its definition:

• Providers focused on copyright-protected content
• Platforms used exclusively by one data holder
• IoT platforms primarily ensuring device functionality
• Data consultancies that aggregate and enrich data before selling it

What they are: entities that establish relationships between data holders and data users. They facilitate transactions without becoming data users themselves.

The notification requirement means these providers must register with their national competent authority before starting operations. The authority has 14 days to acknowledge receipt and 12 weeks to assess whether the provider meets all Article 11 conditions.

If a provider operates across multiple member states, they designate one as their main establishment. That country's authority becomes the lead supervisor, coordinating with other relevant authorities.

The table below shows the key obligations for data intermediation service providers:

Data altruism and why it matters

Data altruism sounds idealistic. And maybe it is. But it's also pragmatic.

We generate data constantly. Every connected device, every transaction, every interaction creates digital traces. Most of that data gets used commercially or sits unused. The DGA creates a pathway for people and companies to donate data for public benefit.

The recognized data altruism organization model provides structure. These entities must operate on a not-for-profit basis. They must have transparent governance. They need to maintain separation from commercial activities.

The European Commission maintains the EU register of these organizations. As of September 2023, any qualified entity can seek recognition. The process involves demonstrating compliance with specific requirements around purpose, transparency, and data handling.

Why would anyone donate data? Several reasons. Scientific advancement. Policy improvement. Social good. The DGA protects these motivations by ensuring recognized organizations can't repurpose donated data for commercial gain.

The logo system creates visibility. When you see that distinctive mark with its QR code, you know the organization has met European standards for trustworthy data altruism. It's a signal that reduces friction in the donation decision.

Public sector data reuse mechanisms

Governments collect massive amounts of data. Administrative records. Geographic information. Transport statistics. Economic indicators. Health data. Environmental measurements.

Some of this gets released as open data under the Open Data Directive. But a significant portion can't be freely published due to legitimate constraints: business confidentiality, personal privacy, intellectual property, statistical confidentiality, or security concerns.

The DGA recognizes that this protected public sector data still has value. Making it available under controlled conditions can accelerate innovation, improve research, and strengthen policy making.

Articles 3 through 5 establish the framework. Public sector bodies must publish their conditions for data reuse. They need clear procedures for submitting access requests. They should process requests in reasonable timeframes.

Competent authorities at the national level oversee these arrangements. They ensure public bodies don't discriminate in granting access. They verify that fees (if charged) are reasonable and cost-based. They handle complaints about access denials or unfair conditions.

This creates a middle ground between completely open data and completely closed data. It acknowledges legitimate protection needs while maximizing social and economic value from public sector information assets.

Common European data spaces

The DGA serves as foundational infrastructure for sector-specific data spaces. These are domains where data sharing can unlock significant value but requires trusted frameworks and common standards.

The European Commission has identified priority sectors:

Health data space: Improving treatments, advancing rare disease research, enabling precision medicine. The potential savings in the EU health sector could reach €120 billion annually. Better data sharing means faster diagnosis, more personalized care, and accelerated drug development.

Mobility data space: Real-time navigation, public transport optimization, autonomous vehicle development. Estimates suggest saving 27 million hours annually for public transport users and €20 billion in reduced labor costs for drivers.

Environmental data space: Climate change monitoring, CO2 emission tracking, emergency response for floods and wildfires. Data sharing enables better predictive models and faster intervention.

Agricultural data space: Precision farming, supply chain optimization, rural service development. Combining production data with earth observation and weather information improves sustainability and productivity.

Energy data space: Smart grid management, renewable energy integration, consumption optimization. Cross-sector data sharing supports decarbonization goals and grid stability.

Financial data space: Risk assessment, fraud detection, regulatory compliance, open banking expansion. Data sharing drives innovation while maintaining security and consumer protection.

Industrial manufacturing data space: Predictive maintenance, supply chain resilience, quality control, AI training for industrial processes. IoT data from connected machinery creates enormous optimization potential.

Public administration data space: Better statistics, evidence-based policy making, reduced administrative burden. Includes specialized spaces for public procurement data and legal information.

Skills data space: Matching education with labor market needs, recognizing qualifications across borders, enabling lifelong learning. The Europass Digital Credentials framework facilitates secure, interoperable skill verification.

Each space operates according to sector-specific rules while building on DGA principles of trust, transparency, and fair access. The spaces aren't isolated. Interoperability between them amplifies the benefits.

Who needs to comply and when

The DGA has been fully applicable since September 24, 2023. If you're operating a data intermediation service, you need to be compliant now.

Public sector bodies holding protected data must have their reuse procedures in place and published. Member states needed to designate competent authorities by the application date.

But here's what happened: ten member states missed the deadline. In December 2024, the Commission sent reasoned opinions to Czechia, Germany, Estonia, Greece, Cyprus, Luxembourg, Austria, Poland, Portugal, and Slovenia. These countries either hadn't designated authorities or hadn't given them proper powers.

This enforcement action signals that the Commission takes DGA implementation seriously. It's not optional. It's not a soft recommendation. It's binding EU law with real consequences for non-compliance.

For businesses, the compliance question depends on what you do. Are you connecting data holders with data users as your main business activity? You might be a data intermediation service provider requiring notification.

Are you collecting data donations for public interest purposes? You might benefit from recognition as a data altruism organization.

Are you trying to access protected public sector data? You need to understand the conditions and procedures the relevant authority has established.

The DGA intersects with other regulations. GDPR still applies to personal data. The Data Act (which became applicable in September 2025) creates additional rights and obligations around data access. The AI Act affects how data can be used for training AI systems.

How the DGA differs from GDPR

People often confuse these two regulations. They both deal with data, they're both EU regulations, and they both affect how businesses operate. But they serve different purposes.

GDPR protects individual rights over personal data. It restricts processing. It requires consent or another legal basis. It gives people control over their information. It's fundamentally about privacy and data protection.

The DGA facilitates data sharing under trustworthy conditions. It creates frameworks for making more data available. It applies to both personal and non-personal data. It's about unlocking value while maintaining safeguards.

Where they overlap: both require security measures, both demand transparency, both impose obligations on entities handling data. A data intermediation service dealing with personal data must comply with both regulations.

But they're not redundant. GDPR doesn't tell you how to set up a data altruism organization or how public sector bodies should handle reuse requests for commercial data. The DGA doesn't override GDPR rights like access, rectification, or erasure.

Think of GDPR as the rules of the road: speed limits, traffic signals, right of way. The DGA builds infrastructure: highways, interchanges, service stations. You need both for the system to function.

Recent enforcement actions and what they tell us

Beyond the December 2024 reasoned opinions about missing designations, enforcement activity has been relatively quiet. The regulation is still young. Many provisions require implementation through national law or administrative procedures.

The Commission published practical guidance in September 2024 titled "Implementing the Data Governance Act – guidance document." This living document provides stakeholder interpretations and clarifications. It's not legally binding but indicates official thinking about ambiguous provisions.

Several member states have launched consultation processes about their national implementation measures. Others are still working through designation procedures for competent authorities.

The real test will come as data intermediation services begin operating at scale and as data altruism organizations seek recognition. Will supervision be consistent across member states? Will notification procedures work smoothly? Will the neutral intermediary model prove viable commercially?

Early signs suggest enthusiasm mixed with confusion. The common logos introduced in August 2023 provide clear visual identification. But market uptake of data intermediation services has been gradual. The business model challenges are real. How do you monetize pure intermediation without using or enriching the data yourself?

The Digital Omnibus proposal and what comes next

Here's where things get complicated. And maybe controversial.

On November 19, 2025, the Commission proposed the Digital Omnibus regulation. This massive simplification initiative aims to streamline digital legislation, reduce compliance burdens, and boost competitiveness.

The proposal doesn't just amend regulations. It repeals several, including the Data Governance Act itself. Under the Digital Omnibus, the DGA would be absorbed into a simplified framework alongside changes to GDPR, the Data Act, NIS2, and other digital regulations.

The stated goal: reduce red tape without weakening protections. Eliminate duplicative requirements. Make compliance more manageable, especially for smaller businesses.

Critics worry this might be premature. The DGA has only been applicable since September 2023. We haven't seen how data intermediation markets will develop or what lessons emerge from data altruism registrations. Repealing it before proper evaluation seems hasty.

Supporters argue the DGA created unnecessary complexity. They point to overlapping obligations between the DGA and Data Act, confusion about which regulation applies when, and administrative burdens for authorities supervising multiple similar schemes.

The Digital Omnibus is still a proposal. It will go through the full EU legislative process: Commission proposal, Parliament amendments, Council negotiations, trilogue discussions. This takes time. Probably years.

What does this mean for businesses trying to plan compliance strategies? Stay informed but don't freeze. The DGA remains binding law until (and unless) the Digital Omnibus passes and enters into force. Compliance obligations exist now. Speculative future changes shouldn't prevent meeting current requirements.

But it does highlight regulatory uncertainty. The EU digital policy landscape continues shifting. What seems settled today might change tomorrow. Adaptive compliance frameworks that can accommodate regulatory evolution become more valuable than rigid, single-regulation approaches.

Practical compliance requirements

If you're running a data intermediation service, here's your checklist:

Before starting operations:

1. Determine your main establishment if operating across multiple member states
2. Prepare documentation demonstrating compliance with all Article 11 conditions
3. Submit notification to the relevant competent authority
4. Wait for acknowledgment (14 days) and completion of assessment (12 weeks)
5. Establish separate legal entity for data intermediation activities
6. Implement technical and organizational security measures
7. Create transparent, non-discriminatory access procedures
8. Develop fraud prevention protocols
9. Set up business continuity guarantees

Ongoing obligations:

• Maintain neutrality, never using data beyond facilitation purposes
• Keep metadata usage strictly limited to service development
• Ensure competition compliance procedures function properly
• Update competent authority about material changes
• Display any applicable logos correctly
• Maintain records of data transactions and access requests
• Cooperate with supervisory inquiries
• Stay current on guidance documents and implementation developments

If you're seeking recognition as a data altruism organization:

1. Establish not-for-profit legal status
2. Develop transparent governance structures
3. Separate data altruism activities from any commercial operations
4. Define clear public interest purposes
5. Create safeguards ensuring data isn't repurposed
6. Submit recognition application to competent authority
7. Once recognized, use the official logo with QR code correctly
8. Maintain registration information accuracy
9. Report to competent authority as required

If you're a public sector body with protected data:

1. Publish conditions for data reuse clearly
2. Establish transparent request procedures
3. Set reasonable processing timeframes
4. Ensure fees (if any) are cost-based and justified
5. Apply conditions non-discriminatorily
6. Coordinate with your competent authority
7. Keep records of reuse agreements
8. Review and update procedures regularly

The Commission's September 2024 guidance document provides detailed examples and interpretations. It's worth reading carefully if you're implementing any DGA requirements.

Implementing DGA compliance with ComplyDog

Data governance regulations like the DGA create obligations that intersect with existing privacy and security requirements. Managing compliance across multiple frameworks becomes exponentially more complex as regulations accumulate.

This is where integrated compliance platforms become valuable. Rather than maintaining separate systems for GDPR, DGA, Data Act, and other regulations, businesses need unified approaches that address common requirements once while meeting specific obligations for each framework.

ComplyDog provides comprehensive GDPR compliance tools that extend naturally to data governance requirements. The platform's record of processing activities functionality, consent management systems, and data mapping capabilities support both privacy protection and data sharing governance.

For data intermediation services, maintaining detailed records of data flows, access requests, and compliance measures is crucial. ComplyDog's documentation features help meet Article 11 obligations while demonstrating regulatory compliance to supervisory authorities.

For organizations participating in data altruism or accessing public sector data, managing consents, documenting purposes, and ensuring transparent governance requires systematic approaches. Compliance software creates audit trails, maintains version histories, and generates reports that satisfy both internal governance needs and external accountability requirements.

The interconnection between GDPR and DGA means compliance with one often supports compliance with the other. Personal data involved in data sharing must meet privacy requirements. Documentation created for GDPR purposes often satisfies DGA transparency obligations. Security measures implemented for data protection serve data governance goals.

Rather than treating each regulation as a separate project, businesses benefit from viewing them as components of an overall data governance framework. ComplyDog helps organizations build that framework systematically, reducing duplication while ensuring nothing falls through gaps between regulatory requirements.

As the Digital Omnibus proposal demonstrates, the regulatory landscape will continue changing. Compliance solutions that adapt to regulatory evolution without requiring complete rebuilding provide long-term value beyond immediate checkbox compliance. The goal isn't just meeting today's requirements but building sustainable governance practices that accommodate tomorrow's changes.

Data governance isn't just about avoiding fines. Done properly, it enables innovation, builds trust with stakeholders, and creates competitive advantages. The DGA reflects this reality by facilitating valuable data sharing rather than simply restricting it. Compliance tools that support both protection and productive use align with this balanced approach to data governance in the modern economy.

Article 30 of the GDPR imposes this obligation on both controllers and processors. The requirement exists whether you're a multinational corporation or a three-person startup (with some limited exceptions that rarely apply in practice). And if you fail to maintain these records or can't produce them when regulators come knocking? You're looking at potential fines of up to €10 million or 2% of annual global turnover.

But here's the thing. These records shouldn't feel like a compliance burden you begrudgingly maintain. When done properly, they become your organization's data processing blueprint. They help you spot risks before they become breaches, identify redundant data you no longer need, and answer subject access requests without turning your office upside down looking for information.

What are records of processing activities?

Think of records of processing activities (often abbreviated as ROPA) as a comprehensive inventory of how your organisation handles personal data. They document the who, what, where, when, and why of data processing across your entire operation.

The GDPR doesn't prescribe a specific format. You could maintain them in a spreadsheet, a database, specialist compliance software, or even on paper (though that last option gets impractical fast). What matters is that the information is complete, accurate, and readily accessible.

Each record entry should tell a complete story about a specific processing activity. Not just "we process customer data" but the full picture: what types of customer data, for which specific purposes, where it's stored, who can access it, how long you keep it, whether you share it with third parties, and what security measures protect it.

The granularity matters. A vague, high-level list won't cut it. You need meaningful connections between data categories, purposes, and recipients.

Table of contents

• Who needs to maintain these records?
• The small business exemption (that barely exists)
• What controllers must document
• What processors must document
• Getting started with documentation
• Structuring your records properly
• Common documentation mistakes
• Keeping records current
• Using records beyond compliance
• Penalties for non-compliance
• Tools and templates

Who needs to maintain these records?

Article 30 creates obligations for four categories of entities:

1. Controllers (the organisations that determine why and how personal data is processed)
2. Processors (organisations that process data on behalf of controllers)
3. Representatives of controllers or processors not established in the EU but subject to GDPR
4. Representatives appointed by controllers or processors based outside the EU

If you're a controller, you maintain records of your processing activities. If you're a processor providing services to other organisations, you maintain separate records of the processing you perform for each client. And if you're both (which many organisations are), you maintain records for each distinct role.

The obligation sits with the legal entity, not individuals. But someone needs to be responsible for creating and maintaining these records. Many organisations assign this to their Data Protection Officer if they have one, or to compliance, legal, or IT teams.

Representatives have the same documentation obligations as the entities they represent. This ensures that regulators can access records even when the actual controller or processor operates outside EU jurisdiction.

The small business exemption (that barely exists)

Article 30(5) contains an exemption for organisations with fewer than 250 employees. At first glance, this looks like a huge relief for small businesses.

But read the fine print. The exemption only applies if all three of these conditions are met:

• The processing is unlikely to result in a risk to the rights and freedoms of data subjects
• The processing is only occasional
• The processing doesn't include special categories of data or criminal conviction data

In practice, almost no businesses meet all three criteria.

Running a website with cookies? That's regular processing, not occasional. Maintaining employee records with health information for sick leave? That's special category data. Operating a customer database for marketing? That likely poses some risk to rights and freedoms.

Even if some of your processing activities qualify for the exemption, you still need to document the ones that don't. So you're maintaining records anyway. You might as well document everything and have a complete picture.

Regulators know this. The exemption exists on paper but rarely provides meaningful relief. (Though recital 13 does encourage regulators to take the needs of small and medium enterprises into account when applying the regulation, which might influence enforcement priorities if not the legal requirements themselves.)

What controllers must document

Controllers have seven specific documentation requirements under Article 30(1). Each processing activity should include:

1. Name and contact details of the controller

This includes the contact information for the controller, any joint controllers, the controller's representative (if applicable), and the Data Protection Officer if one has been appointed.

2. Purposes of the processing

Why are you processing this data? Each purpose should be specific and clearly defined. "Business operations" is too vague. "Processing job applications to evaluate candidates for open positions" tells the actual story.

You'll likely have multiple distinct purposes, each potentially involving different data categories and different legal bases. Document them separately rather than lumping everything together.

3. Categories of data subjects

Who do you hold information about? Common categories include:

• Employees
• Job applicants
• Customers
• Website visitors
• Suppliers and vendors
• Business contacts
• Newsletter subscribers

But get more specific where appropriate. An online retailer might distinguish between registered customers, guest checkout users, and abandoned cart browsers if these groups involve different processing activities.

4. Categories of personal data

What specific types of information do you process about each category of data subject? Break this down meaningfully:

• Contact information (name, email, phone, address)
• Financial data (payment card details, bank account information, transaction history)
• Account credentials (username, password, security questions)
• Device and usage data (IP addresses, cookies, browsing behaviour)
• Demographic information (age, gender, location)
• Professional information (job title, employer, work history)

Special categories of personal data deserve particular attention. These include racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, biometric data for identification purposes, health data, and data about sex life or sexual orientation. If you process any of these, flag them clearly.

5. Categories of recipients

Who do you share personal data with? This could include:

• Service providers and processors (cloud hosting, email services, payment processors)
• Business partners (co-marketing arrangements, referral programs)
• Professional advisors (lawyers, accountants, auditors)
• Group companies and affiliates
• Public authorities (when required by law)

Be specific. "Third parties" doesn't meet the requirement. Name the actual categories of recipients and, where relevant, the types of organisations involved.

If you make personal data publicly accessible (posting employee names on your website, for example), document that too.

6. Transfers to third countries

If you transfer personal data outside the European Economic Area, document:

• Which third countries receive the data
• The legal basis for the transfer (adequacy decision, standard contractual clauses, binding corporate rules, etc.)
• Documentation of appropriate safeguards where applicable

Data transfers remain a sensitive area for regulators. Your records need to show you've properly assessed and protected these flows.

7. Time limits for erasure

How long do you keep different categories of data? This should align with your retention policies.

Different data types often have different retention periods. Employee data might be kept for seven years after employment ends for tax purposes. Marketing consent might expire after two years of inactivity. Transaction records might be retained for six years to comply with accounting requirements.

Where you can't specify exact timescales, explain the criteria you use to determine retention periods. "We keep customer data until the customer requests deletion or remains inactive for three years, whichever comes first" provides clear parameters even without a fixed deadline.

8. Technical and organisational security measures (optional but recommended)

While not strictly required by Article 30, documenting your security measures alongside your processing records makes practical sense. This might include:

• Encryption methods
• Access controls and authentication
• Regular security assessments
• Staff training programs
• Incident response procedures

Having this information readily available helps demonstrate GDPR compliance across multiple requirements, not just Article 30.

What processors must document

Processors have fewer but still substantial documentation obligations under Article 30(2). For each category of processing carried out on behalf of a controller, processors must record:

1. Name and contact details

Include the name and contact details of the processor, each controller on whose behalf the processor is acting, the processor's representative (if applicable), and the Data Protection Officer if appointed.

2. Categories of processing

What types of processing activities do you perform for each controller? This could include:

• Data hosting and storage
• Email marketing services
• Payment processing
• Customer support ticketing
• Analytics and reporting
• Backup and disaster recovery

Be clear about what you're doing with the data, even if you don't know all the details about why (that's the controller's concern).

3. Transfers to third countries

Same as for controllers. Document where data goes and what safeguards apply.

4. Technical and organisational security measures

Unlike controllers, processors must document their security measures as part of their Article 30 records, not just as an optional extra.

This makes sense. Clients need assurance that their data is protected. Your processing records should demonstrate the security arrangements you've implemented.

Getting started with documentation

Beginning this process can feel overwhelming. Where do you even start when you don't know what data you have?

Here's a practical approach:

Step 1: Map your data flows

Before documenting anything, understand what's actually happening in your organisation. This means conducting an information audit or data mapping exercise.

Walk through each department and business function:

• What systems do you use?
• What personal data do those systems contain?
• Where does the data come from?
• What happens to it?
• Where does it go?

Create visual maps if that helps. Flow diagrams showing how data moves through your organisation reveal connections you might otherwise miss.

Step 2: Engage across the organisation

No single person knows every processing activity across an entire organisation. You need input from different teams:

• IT staff understand technical systems and infrastructure
• HR knows about employee data and recruitment processes
• Marketing handles customer communications and analytics
• Sales maintains prospect and client databases
• Finance processes payment information
• Legal and compliance may have data sharing agreements on file

Get senior management buy-in early. This exercise requires time and resources. It works better when leadership explicitly supports it.

Step 3: Develop a questionnaire

Create a standardized set of questions you can distribute to different departments. Keep the language simple and jargon-free. You're not trying to test people's legal knowledge. You want accurate information about what they actually do.

Sample questions might include:

• What personal information do you work with in your role?
• Why does your team need this information?
• Where is it stored?
• Who outside your team has access to it?
• Do you share it with anyone outside the organisation?
• How long do you keep it?
• What happens to it when you no longer need it?

Step 4: Review existing documentation

Don't start from scratch if you don't have to. Examine:

• Privacy policies and notices
• Data protection policies
• Information security policies
• Retention and deletion schedules
• Processor agreements and data sharing contracts
• System documentation and user manuals

These documents often contain information that feeds directly into your processing records. They also reveal gaps between policy and practice (which happens more often than anyone likes to admit).

Step 5: Conduct interviews

Questionnaires only get you so far. Schedule meetings with key people in each business function.

These conversations often uncover shadow IT systems and informal processes that wouldn't show up in official documentation. Someone might mention, "Oh, and we also keep a shared spreadsheet where we track…" Exactly the sort of thing you need to know about.

Structuring your records properly

How you organize these records matters almost as much as what you include.

A granular, meaningful structure links related pieces of information together. Each processing activity should be a coherent unit with all relevant details clearly connected.

Bad structure looks like this:

Purposes: Employee management, customer service, marketing, supplier management, website operation

Data categories: Names, addresses, email addresses, phone numbers, financial details, IP addresses, employment details, health information

Recipients: Cloud hosting providers, email service providers, payment processors, professional advisors, marketing platforms

See the problem? Everything's listed, but nothing's connected. You can't tell which data categories relate to which purposes or which recipients receive which types of data.

Better structure looks like this:

Each row tells a complete story about a specific processing activity. You can see exactly what data supports which purpose and who has access to it.

Start broad and narrow down. If you're a controller, begin with business functions (HR, sales, marketing, customer service). Each function likely has multiple purposes. Each purpose involves specific categories of data subjects. Each category of data subject has associated personal data. Build out from there.

If you're a processor, start with your clients. For each client, identify the categories of processing you perform. For each category, document the details Article 30 requires.

Common documentation mistakes

Several patterns emerge when records fail to meet GDPR requirements:

Mistake 1: Too generic

"We process personal data for business purposes" doesn't tell anyone anything useful. Neither does "We process data about customers, employees, and suppliers."

Get specific. What business purposes? Which types of customers? What do you actually do with supplier data?

Mistake 2: Not keeping records updated

Processing activities change constantly. New systems get implemented. Old databases get decommissioned. Marketing campaigns launch and end. Vendor relationships start and stop.

If your records don't reflect current reality, they're worse than useless. They're misleading.

Mistake 3: Confusing records with privacy policies

These serve different purposes. Privacy policies inform data subjects about processing. Processing records document that same information for internal accountability and regulatory oversight.

You can't just copy your privacy policy into a spreadsheet and call it done. The audience and level of detail differ.

Mistake 4: Forgetting about processors

Many organisations focus on their role as controller and forget they also act as processor for clients. Both roles require separate documentation.

Mistake 5: No ownership or governance

Creating records once isn't enough. Someone needs to own this documentation, maintain it, update it, and ensure it remains accurate.

Without clear responsibility, records decay into inaccuracy within months.

Mistake 6: Treating it as a one-time project

This isn't like getting your house rewired. It's more like keeping your garden maintained. Regular attention prevents it from becoming overgrown and unmanageable.

Keeping records current

Processing records are living documents. They should evolve as your organisation's data processing activities evolve.

Set up review cycles. Many organisations review their complete records annually, with more frequent spot checks for high-risk processing or rapidly changing areas.

Trigger updates when:

• You implement new systems or services
• You enter new contracts with processors or data sharing partners
• You launch new products or services
• You change business processes that affect data handling
• You identify errors or gaps in existing documentation
• Regulations change or new guidance emerges

Integrate documentation into your change management processes. When IT implements a new CRM system, updating processing records should be part of the deployment checklist. When marketing signs up for a new email platform, documenting that processor relationship should be mandatory.

Make it someone's job. Whether that's your DPO, a compliance officer, or someone in legal or IT, explicit ownership prevents documentation from falling through the cracks.

Consider version control. Keep track of what changed when and why. This helps demonstrate accountability if regulators question your historical processing practices.

Using records beyond compliance

Here's where these records become genuinely useful rather than just a regulatory checkbox.

Responding to data subject requests

When someone submits a subject access request, your processing records tell you exactly where to look for their data. Instead of frantically searching through systems hoping you find everything, you have a roadmap.

The same applies to deletion requests, portability requests, and objections to processing. Your records guide your response.

Managing data breaches

If you suffer a breach, you need to quickly assess what data was affected and who might be at risk. Processing records provide that information immediately.

They also help you notify the right people. Your records show which processors have access to affected data and which data subjects might be impacted.

Vendor management and due diligence

When evaluating new processors, your existing records help you articulate exactly what processing you need them to perform and what safeguards you require.

When auditing current processors, your records provide a baseline for assessing whether they're meeting their obligations.

Data minimisation and retention

Review your records periodically and you'll spot data you no longer need. That customer list from a 2019 trade show? If you're not actively using it and your retention period has passed, delete it.

Processing records force you to articulate why you're keeping data and for how long. That discipline reduces accumulation of unnecessary information.

Security risk assessment

Your documentation reveals your attack surface. What data is most sensitive? Where is it stored? Who can access it? Which transfers pose the highest risk?

This information feeds directly into security planning and resource allocation.

Demonstrating accountability

If regulators investigate, complete and accurate processing records show you take data protection seriously. They demonstrate you understand your obligations and have systems in place to meet them.

That won't necessarily prevent enforcement action if you've violated the GDPR in other ways. But it helps establish that you're trying to comply, which influences how regulators exercise their discretion.

Penalties for non-compliance

Article 83(4)(a) specifically lists failure to maintain processing records as an infringement subject to administrative fines.

The maximum penalty is €10 million or 2% of total worldwide annual turnover from the preceding financial year, whichever is higher.

Regulators don't hand out maximum fines for first-time documentation failures. But they're increasingly focusing on Article 30 during audits and investigations. Missing or inadequate records make everything else harder to assess and often indicate broader compliance problems.

Even if you avoid fines, the disruption of scrambling to create records after a regulator requests them is significant. You'll divert staff from their normal work, potentially delay other business activities, and damage your relationship with the regulator.

And if you can't document your processing activities, how can you demonstrate you're processing lawfully? How can you show you're meeting principles like data minimisation and storage limitation? Documentation failures often lead investigators to look more closely at substantive compliance issues.

Tools and templates

You don't need expensive software to maintain compliant processing records. A well-organised spreadsheet works fine for many organisations.

Both the ICO and other regulatory authorities provide free templates that meet Article 30 requirements. These offer a solid starting point, particularly for smaller organisations with straightforward processing activities.

The ICO offers separate templates for controllers and processors. Each template includes:

• Sections for all required information under Article 30
• Additional sections for recommended information that supports broader GDPR compliance
• Guidance notes explaining what to include in each section
• Examples to illustrate expected detail levels

As your organisation grows or your processing becomes more complex, you might outgrow spreadsheets. At that point, specialised privacy management software can help. These platforms typically offer:

• Structured data entry that ensures you capture all required information
• Automated workflows for reviews and updates
• Integration with other compliance processes like data protection impact assessments
• Reporting and analytics capabilities
• Multi-user access with permissions and version control

The right tool depends on your organisation's size, complexity, budget, and technical capabilities. What matters is that your chosen method allows you to create complete, accurate, accessible records that you can actually maintain.

Don't let perfect be the enemy of good. Starting with a basic spreadsheet beats waiting to implement the ideal solution. You can always migrate to something more sophisticated later.

Why compliance software matters

Managing GDPR compliance across all its requirements becomes exponentially harder as organisations grow. Processing records under Article 30 are just one piece. Add data protection impact assessments, consent management, subject rights requests, breach notifications, and vendor assessments, and you're juggling multiple interconnected compliance obligations.

Compliance platforms like ComplyDog bring these elements together in one place. Rather than maintaining scattered spreadsheets and documents, organisations can manage their entire GDPR compliance program through integrated workflows.

For processing records specifically, ComplyDog helps organisations:

• Create structured records that capture all Article 30 requirements
• Link related compliance activities (connecting processing records to relevant DPIAs, for example)
• Track changes and maintain audit trails
• Set up automatic review reminders so records don't become stale
• Generate reports for internal stakeholders and regulators
• Collaborate across teams while maintaining clear ownership

More broadly, ComplyDog supports the full spectrum of GDPR compliance requirements, from initial risk assessments through ongoing monitoring and improvement. This integrated approach ensures that maintaining processing records doesn't become an isolated compliance exercise disconnected from your broader data protection program.

Organisations serious about sustainable GDPR compliance find that purpose-built tools transform compliance from a burden into a manageable, systematic process. Learn how ComplyDog can help your organisation meet its GDPR obligations.

This regulation contains 99 articles spread across 11 chapters. That's a lot to digest. And while every article serves a purpose, six stand out as particularly critical for businesses processing personal data of EU citizens. These articles form the backbone of data protection compliance and directly affect how companies collect, store, and use personal information.

What makes these six articles so important? They define the legal framework for processing activities, establish individual rights, and set expectations for organizational accountability. Get these wrong, and you're looking at potential fines reaching into the millions of euros.

Let's break down what actually matters.

Table of contents

• Article 6: Lawfulness of processing
• Article 13 and 14: Information obligations
• Article 15: Right of access
• Article 17: Right to erasure
• Article 28: Processor obligations
• Article 35: Data protection impact assessments
• Why these articles work together
• Implementing compliance across all six areas

Article 6: Lawfulness of processing

Article 6 answers the most fundamental question in GDPR compliance: when can you actually process someone's personal data?

The regulation identifies six lawful bases for processing. You need at least one of these to justify any processing activity:

Consent: The data subject gives clear permission for processing their personal data for a specific purpose. This needs to be freely given, specific, informed, and unambiguous. Pre-ticked boxes don't count. Neither does silence or inactivity.

Contract performance: Processing is necessary to fulfill a contract with the individual, or to take steps before entering into a contract at their request. If someone orders a product from your website, you can process their delivery address to ship that product.

Legal obligation: You must process the data to comply with a law. Tax records fall into this category. So do certain employment records.

Vital interests: Processing is necessary to protect someone's life. This applies in medical emergencies and similar situations where someone's physical safety is at risk.

Public task: The processing is necessary for a task carried out in the public interest or in the exercise of official authority. This mostly applies to public bodies and government organizations.

Legitimate interests: Processing is necessary for your legitimate interests or those of a third party, unless those interests are overridden by the individual's rights and freedoms. This is the most flexible basis but requires careful balancing of interests.

Choosing the right lawful basis matters tremendously. You can't just pick whichever one seems convenient. Each basis comes with specific requirements and limitations. If you rely on consent, individuals can withdraw it at any time. If you use legitimate interests, you need to conduct a balancing test and document your reasoning.

Public authorities can't use legitimate interests as a basis when processing data for their official tasks. That's explicitly ruled out.

Many organizations make the mistake of relying on consent when another basis would be more appropriate. Consent sounds simple, but it's actually one of the harder bases to implement correctly. The bar for valid consent is high. Really high.

Article 6 also addresses repurposing data. If you collected personal data for one purpose and now want to use it for something else, you need to check whether that new purpose is compatible with the original one. The regulation provides factors to consider: the link between purposes, the context of collection, the nature of the data, possible consequences for individuals, and whether appropriate safeguards exist.

Article 13 and 14: Information obligations

Transparency sits at the heart of GDPR. Articles 13 and 14 spell out exactly what information you must provide to individuals when collecting their personal data.

Article 13 applies when you collect data directly from the individual. Think contact forms, account registrations, newsletter signups. Article 14 covers situations where you obtain personal data from another source instead of directly from the person.

Both articles require you to provide specific information at the point of collection (or within a reasonable period afterward if obtained indirectly). This isn't optional disclosure buried in a privacy policy. This is upfront, clear communication about what you're doing with someone's data.

The required information includes:

• Your identity and contact details
• Your data protection officer's contact details (if you have one)
• The purposes of processing and the lawful basis
• Legitimate interests (if you're relying on that basis)
• Categories of personal data (for Article 14 situations)
• Recipients or categories of recipients of the data
• Details about international transfers
• Retention periods or criteria for determining them
• Individual rights (access, rectification, erasure, restriction, objection, data portability)
• The right to withdraw consent (if applicable)
• The right to lodge a complaint with a supervisory authority
• Whether providing data is a statutory, contractual, or necessary requirement
• Information about automated decision-making and profiling

That's a substantial list. And you need to provide all of this in a concise, transparent, intelligible, and easily accessible form. Use clear and plain language. No legal jargon that requires a law degree to decipher.

Privacy policies serve as the primary vehicle for meeting these transparency obligations. But a privacy policy alone isn't always enough. If you're collecting data through a specific form or interaction, you might need additional notices at that collection point.

Layered notices work well for many organizations. Provide key information upfront where the data is collected, then link to your full privacy policy for additional details. This approach balances completeness with usability.

The timing requirements differ slightly between Articles 13 and 14. For directly collected data (Article 13), you must provide the information at the time you obtain the data. For indirectly collected data (Article 14), you have up to one month, or you must provide it when you first contact the individual or disclose the data to another recipient, whichever comes first.

Some exceptions exist for Article 14. You don't need to provide the information if the individual already has it, providing it would be impossible or require disproportionate effort, obtaining or disclosure is expressly laid down by law, or the data must remain confidential due to professional secrecy obligations.

Article 15: Right of access

Data subjects have the right to know whether you're processing their personal data. If you are, they can request access to that data and obtain a copy.

This right, established in Article 15, gives individuals significant insight into how organizations use their information. When someone submits an access request (often called a subject access request or SAR), you must respond within one month. That deadline can be extended by two more months for complex requests, but you need to inform the requester within the first month and explain why the extension is needed.

The response must include:

• Confirmation that you're processing their personal data
• The purposes of processing
• The categories of personal data involved
• The recipients or categories of recipients
• The retention period or criteria for determining it
• Information about their rights (rectification, erasure, restriction, objection)
• The right to lodge a complaint with a supervisory authority
• Information about the source of the data (if not collected directly from them)
• Details about automated decision-making or profiling
• Safeguards for international transfers

You also need to provide a copy of the personal data being processed. The first copy must be free. If the individual requests additional copies, you can charge a reasonable fee based on administrative costs.

The format for providing information deserves consideration. The regulation states that information should generally be provided in writing or by electronic means. If the request was made electronically, provide the information in a commonly used electronic format unless the person requests otherwise.

Verifying identity becomes critical with access requests. You need to ensure you're disclosing personal data to the right person. But you can't demand excessive information for verification. The approach should be proportionate. If you already have a relationship with the requester and they're submitting the request through an authenticated account, that might suffice. For requests from unknown individuals, you may need additional identification.

Manifestly unfounded or excessive requests (particularly repetitive ones) allow you to charge a reasonable fee or refuse to act. But that's an exception, not the rule. You need to demonstrate why a request falls into this category.

Some organizations struggle with the scope of access requests. Do you need to search every email account, every system, every backup? The regulation requires you to provide information about personal data being processed. Backup copies kept solely for disaster recovery purposes, where the data isn't actively processed, might not need to be searched. But actively used systems certainly do.

Article 17: Right to erasure

The right to erasure, often called the "right to be forgotten," allows individuals to request deletion of their personal data under specific circumstances.

This right isn't absolute. Data subjects can request erasure when:

• The personal data is no longer necessary for the purposes it was collected
• They withdraw consent and there's no other legal ground for processing
• They object to processing and there are no overriding legitimate grounds
• The personal data was unlawfully processed
• Erasure is required for compliance with a legal obligation
• The personal data was collected in relation to information society services offered to children

You must respond to erasure requests within one month, the same timeline as access requests. But here's where it gets interesting: you don't have to comply with every erasure request.

Several grounds allow you to refuse:

• Exercising the right to freedom of expression and information
• Compliance with a legal obligation requiring processing
• Performance of a task carried out in the public interest or exercise of official authority
• Public health purposes
• Archiving, research, or statistical purposes (with appropriate safeguards)
• Establishment, exercise, or defense of legal claims

Legal obligations often provide grounds to retain data despite an erasure request. Tax authorities require businesses to keep financial records for specified periods. Employment laws mandate retention of certain employee records. You can refuse erasure when these obligations apply.

The regulation also requires reasonable steps to inform other controllers about erasure requests if you've disclosed the personal data to them. This creates a ripple effect. If you shared someone's data with third parties and that person exercises their right to erasure, you need to tell those third parties about the request so they can also erase the data (unless that's impossible or requires disproportionate effort).

Backup systems present challenges for erasure. You don't need to delete data from backups immediately if those backups are isolated and not used for active processing. But when you restore from a backup, the erased data should not be restored into active systems.

Documentation matters tremendously with erasure requests. Record the request, your decision, and your reasoning. If you refuse erasure, explain which exemption applies and why.

Article 28: Processor obligations

Article 28 governs the relationship between data controllers and data processors. If you use third-party services that process personal data on your behalf, this article applies to you.

Controllers maintain overall responsibility for processing activities. Processors act on the controller's instructions. But processors aren't off the hook. They have direct obligations under GDPR.

The regulation requires a written contract (or other legal act) between controllers and processors. This contract must include specific terms:

Processing instructions: The processor can only process data on documented instructions from the controller, including transfers to third countries.

Confidentiality: People authorized to process the data must be under confidentiality obligations.

Security measures: The processor must implement appropriate technical and organizational measures.

Sub-processor conditions: The processor needs the controller's authorization (general or specific) before engaging sub-processors. The processor remains liable to the controller for the sub-processor's performance.

Assistance obligations: The processor must assist the controller in responding to data subject rights requests and meeting security, breach notification, and impact assessment obligations.

Data handling at contract end: The processor must delete or return all personal data after services end, unless law requires storage.

Audit rights: The processor must make information available to demonstrate compliance and allow audits.

These requirements create a framework that allocates responsibilities and ensures accountability throughout the processing chain. Controllers can't just hand off data to a processor and wash their hands of compliance. They must choose processors that provide sufficient guarantees of GDPR compliance and monitor that compliance throughout the relationship.

Processors face potential liability for GDPR violations. If a processor processes data outside the controller's instructions or fails to meet its obligations, it can be held directly liable. The regulation treats the processor as a controller for that processing activity.

Many cloud service providers, SaaS platforms, and outsourced service providers function as processors. If they process personal data as part of their service but don't determine the purposes and means of processing, they're processors. Understanding this distinction affects contractual relationships and compliance obligations.

One area that trips up many organizations: sub-processors. If your processor uses another company to provide part of the service (and that company will process personal data), you need visibility into that relationship. The processor needs your permission before engaging sub-processors. Many controllers provide general authorization subject to notification requirements, allowing processors to change sub-processors if they notify the controller and give them an opportunity to object.

Article 35: Data protection impact assessments

When processing operations are likely to result in high risk to individuals' rights and freedoms, Article 35 requires a data protection impact assessment (DPIA) before processing begins.

This isn't a compliance checklist exercise. A proper DPIA involves systematic assessment of risks, evaluation of measures to address those risks, and consideration of whether the processing should proceed at all.

The regulation identifies scenarios where a DPIA is required:

• Systematic and extensive evaluation of personal aspects based on automated processing (including profiling) that produces legal or similarly significant effects
• Large-scale processing of special categories of data or data relating to criminal convictions
• Systematic monitoring of publicly accessible areas on a large scale

Supervisory authorities publish lists of processing operations requiring DPIAs. They can also publish lists of operations that don't require DPIAs. Check your relevant supervisory authority's guidance.

"High risk" depends on various factors. The Article 29 Working Party (now the European Data Protection Board) identified nine criteria, any two of which typically indicate high risk:

• Evaluation or scoring
• Automated decision-making with legal or similar significant effect
• Systematic monitoring
• Sensitive data or data of a highly personal nature
• Data processed on a large scale
• Matching or combining datasets
• Data concerning vulnerable data subjects
• Innovative use of new technological or organizational solutions
• Processing that prevents data subjects from exercising a right or using a service or contract

A DPIA must contain:

• A systematic description of the processing operations and purposes
• An assessment of necessity and proportionality
• An assessment of risks to individuals' rights and freedoms
• Measures to address those risks and demonstrate compliance

The assessment needs to be meaningful. Template DPIAs that organizations fill out without genuine analysis don't meet the requirement. You need to actually think through what could go wrong, who might be affected, and how to prevent or mitigate those outcomes.

Data protection officers (when appointed) must be consulted during DPIA preparation. Data subjects or their representatives should be consulted when appropriate.

If the DPIA indicates high risk that you can't adequately mitigate, you must consult the supervisory authority before processing. The authority will provide written advice within eight weeks (extendable to 14 weeks for complex cases).

DPIAs aren't one-time exercises. You should review and update them when there are changes to the risk or nature of processing operations. Regular reviews ensure your risk assessment remains current.

Many organizations find DPIAs valuable beyond compliance. The process of systematically examining processing activities, identifying risks, and determining mitigation measures improves data protection practices. It forces consideration of privacy implications before deployment rather than retrofitting protections after problems emerge.

Why these articles work together

These six articles don't exist in isolation. They form an interconnected framework that governs different aspects of data protection.

Article 6 provides the foundation by establishing when processing is lawful. Without a lawful basis, you can't process personal data at all. Articles 13 and 14 build on this by requiring transparency about that processing. Individuals need to understand what you're doing with their data and why.

Articles 15 and 17 give individuals mechanisms to exercise control. Access requests let people see what data you hold. Erasure requests let them demand deletion under appropriate circumstances. These rights only make sense in the context of Articles 6, 13, and 14. You can only access or delete data that's being lawfully processed, and you need transparency information to understand whether to exercise these rights.

Article 28 extends accountability beyond single organizations. Most modern businesses rely on third-party processors. This article ensures that responsibility doesn't disappear when data moves to a processor.

Article 35 requires proactive risk assessment for high-risk processing. This connects back to all the other articles. The lawful basis you choose under Article 6 affects risk assessment. The information you provide under Articles 13 and 14 can mitigate certain risks. Individual rights under Articles 15 and 17 might be risk mitigation measures. Processor arrangements under Article 28 introduce additional risks that need assessment.

Consider a practical example. An e-commerce business wants to implement a new recommendation engine using customer purchase history and browsing behavior. Here's how these articles interact:

Article 6 comes first. The business needs a lawful basis. Consent might work, but legitimate interests could be more appropriate if recommendations improve customer experience and aren't intrusive.

Articles 13 and 14 require updating the privacy policy to explain the recommendation system, what data it uses, and the lawful basis. Customers need this information to understand how their data is being used.

If the recommendation engine involves automated decision-making with significant effects, Article 35 requires a DPIA. The business needs to assess risks like filter bubbles, discriminatory outcomes, or privacy intrusion from profiling.

Article 28 becomes relevant if a third-party provider hosts or operates the recommendation engine. The business needs appropriate processor contracts in place.

Articles 15 and 17 affect operational processes. The business must be able to retrieve recommendation data for access requests and delete it for valid erasure requests.

Implementing compliance across all six areas

Theory is one thing. Implementation is another. Organizations need practical systems and processes to comply with these articles.

Start with Article 6. Document your lawful basis for each processing activity. Create a processing register that maps data types, purposes, lawful bases, and retention periods. This becomes your roadmap for compliance across other articles.

For Articles 13 and 14, develop a comprehensive but readable privacy policy. But don't stop there. Create point-of-collection notices for forms, apps, and other data collection points. Make transparency layered and contextual.

Build request handling procedures for Articles 15 and 17. Who receives requests? How do you verify identity? What systems need to be searched? How do you compile responses? What's the escalation process for edge cases? Document all of this before you receive your first request.

Article 28 compliance requires contract management. Review existing processor contracts. Do they include required terms? If not, negotiate amendments. For new processors, use contract templates that include all mandatory clauses. Maintain a register of processors and sub-processors.

Establish a DPIA process for Article 35. Create templates, but ensure they encourage genuine analysis rather than box-checking. Define triggers that indicate when a DPIA is needed. Involve appropriate stakeholders, including your data protection officer if you have one.

Training matters across all six articles. Staff need to understand lawful bases, transparency obligations, individual rights, processor requirements, and when DPIAs are needed. Different roles need different levels of knowledge, but everyone who handles personal data needs baseline awareness.

Technology can help, but it's not a complete solution. Privacy management platforms can track processing activities, manage consent, handle requests, and document DPIAs. But these tools require proper configuration, accurate data, and human judgment. (More on that in a moment.)

Regular audits catch compliance gaps. Review your Article 6 documentation annually. Check whether privacy notices accurately reflect current processing. Test request handling procedures. Examine processor contracts when renewals approach. Update DPIAs when processing changes.

One pattern that emerges: documentation is everything. The regulation explicitly requires documentation in many places, but even where it doesn't, documentation proves compliance. If a supervisory authority investigates, you need evidence that you've met your obligations. Verbal assurances don't cut it.

Achieving comprehensive compliance across these six articles requires dedicated resources. Many organizations appoint data protection officers to coordinate these efforts. Even when not legally required to appoint a DPO, having someone responsible for data protection makes practical sense.

Compliance software like ComplyDog helps companies meet GDPR requirements across all six of these critical articles. These platforms centralize documentation, automate routine tasks, and provide workflows for handling requests and conducting assessments. By bringing together Article 6 lawful basis tracking, Article 13/14 privacy notice management, Article 15/17 request handling, Article 28 processor documentation, and Article 35 DPIA tools, compliance platforms give organizations a systematic approach to data protection that reduces risk and administrative burden while ensuring nothing falls through the cracks.

The GDPR restructured how companies collect, process, and store personal data. Passed in 2016 and enforced since May 2018, it affects any organization offering goods or services to EU residents or monitoring their behavior. That includes businesses based outside Europe.

This breakdown covers what each chapter means for your operations. You'll learn which articles demand immediate attention and which ones might not apply to your situation at all.

Table of contents

• Chapter 1: General provisions (Articles 1-4)
• Chapter 2: Principles (Articles 5-11)
• Chapter 3: Rights of data subjects (Articles 12-23)
• Chapter 4: Controller and processor (Articles 24-43)
• Chapter 5: Transfers of personal data (Articles 44-50)
• Chapter 6: Independent supervisory authorities (Articles 51-59)
• Chapter 7: Cooperation and consistency (Articles 60-76)
• Chapter 8: Remedies, liability and penalties (Articles 77-84)
• Chapter 9: Specific processing situations (Articles 85-91)
• Chapter 10: Delegated acts (Articles 92-93)
• Chapter 11: Final provisions (Articles 94-99)
• Building compliance into operations

Chapter 1: General provisions (Articles 1-4)

These opening articles set the stage. They define what the GDPR covers and who needs to follow it.

Article 1 establishes that the regulation protects people's fundamental rights regarding their personal data. It aims to balance data protection with the free movement of information across EU borders.

Article 2 clarifies the material scope. The GDPR applies to automated processing and filing systems. It excludes purely personal activities (like your home address book) and certain law enforcement contexts.

Article 3 addresses territorial scope. This article catches many businesses off guard. You don't need a physical presence in Europe to fall under GDPR rules. Processing data of EU residents while offering them goods or services? You're covered. Monitoring behavior of people in the EU? Same deal.

Article 4 contains 26 definitions. Personal data means information relating to an identified or identifiable person. Processing covers any operation performed on data. Controllers decide why and how to process data. Processors handle data on behalf of controllers. Consent must be freely given, specific, informed and unambiguous.

These definitions matter because they determine your obligations throughout the regulation.

Chapter 2: Principles (Articles 5-11)

Data processing principles form the backbone of GDPR compliance. Violating these draws serious penalties.

Article 5 lists six core principles. Lawfulness, fairness and transparency mean being upfront with people about what you're doing with their data. Purpose limitation requires using data only for specified, explicit purposes. Data minimization demands collecting only what you need. Accuracy means keeping data correct and current. Storage limitation prevents holding data longer than necessary. Integrity and confidentiality require appropriate security measures.

The seventh principle, accountability, makes controllers responsible for demonstrating compliance with all other principles.

Article 6 establishes six lawful bases for processing. You need at least one:

• Consent from the data subject
• Performance of a contract
• Compliance with a legal obligation
• Protection of vital interests (life or death situations)
• Performance of a task in the public interest
• Legitimate interests (balanced against individual rights)

Picking the wrong legal basis causes compliance headaches later. You can't just switch from one to another if someone withdraws consent.

Article 7 sets conditions for valid consent. Pre-ticked boxes don't work. Requests must be clear and separate from other terms. Withdrawing consent must be as easy as giving it. You need to document how and when someone consented.

Article 8 protects children. For information society services (online services), children under 16 need parental consent. Member states can lower this to 13. Verifying age and parental authority creates practical challenges.

Article 9 addresses special categories of personal data. This includes racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, biometric data, health data, and data about sex life or sexual orientation. Processing this information is generally prohibited unless specific conditions apply. Medical treatment, employment law obligations, and explicit consent provide exceptions.

Article 10 covers criminal conviction data. Only official authorities or entities authorized by member state law can process this information.

Article 11 says if you don't need to identify individuals for your processing purposes, you're not required to maintain or obtain identification information just to comply with GDPR. But if someone makes a rights request and can't be identified, you can ask for additional information.

Chapter 3: Rights of data subjects (Articles 12-23)

People have expansive rights over their personal data. Organizations must facilitate these rights without creating unnecessary barriers.

Article 12 mandates transparent communication. Responses to rights requests must be concise, accessible, and in plain language. You have one month to respond (extendable to three months for complex requests). Information must be provided free of charge unless requests are manifestly unfounded or excessive.

Article 13 requires transparency at collection. When collecting data directly from individuals, you must provide information about your identity, contact details, processing purposes, legal basis, recipients, storage periods, and rights available to them. This information typically goes in a privacy policy.

Article 14 extends transparency requirements to situations where you obtain data from third parties. You have one month to provide required information to affected individuals. This creates challenges for businesses purchasing data lists or receiving data from partners.

Article 15 gives people the right to access their data. They can request confirmation that you're processing their information, along with details about processing purposes, categories of data, recipients, storage periods, and their available rights. You must provide a copy of the data free of charge.

Article 16 establishes the right to rectification. People can request correction of inaccurate data or completion of incomplete data.

Article 17 creates the right to erasure (right to be forgotten). Individuals can request deletion when data is no longer needed for its original purpose, when consent is withdrawn, when they object to processing, when processing is unlawful, or when legal obligations require erasure. Exceptions exist for legal claims, public interest, and freedom of expression.

Article 18 allows restriction of processing. Instead of deleting data, individuals can ask you to limit what you do with it under certain circumstances.

Article 19 requires notifying others. When you rectify, erase, or restrict processing, you must inform recipients of the data unless this proves impossible or requires disproportionate effort.

Article 20 grants data portability. People can receive their data in a structured, commonly used, machine-readable format. They can transmit this data to another controller. This right only applies when processing is based on consent or contract and carried out by automated means.

Article 21 covers the right to object. Individuals can object to processing based on legitimate interests or for direct marketing. You must stop processing unless you demonstrate compelling legitimate grounds that override individual rights. There are no exceptions for marketing objections.

Article 22 addresses automated decision-making and profiling. People have the right not to be subject to decisions based solely on automated processing that produce legal or similarly significant effects. Exceptions exist for contractual necessity, legal authorization, or explicit consent. Even when automated decisions are permitted, you must provide meaningful information about the logic involved and implement measures to safeguard rights.

Article 23 allows member states or EU law to restrict certain rights through legislative measures. Restrictions can apply for national security, defense, public safety, criminal investigations, or protection of judicial independence. Any such restriction must respect the essence of fundamental rights.

Chapter 4: Controller and processor (Articles 24-43)

This chapter outlines obligations for organizations handling personal data. Controllers carry most responsibilities, but processors face requirements too.

Article 24 makes controllers responsible for demonstrating compliance. This isn't just about being compliant - you must prove it through documentation and appropriate measures.

Article 25 requires data protection by design and by default. You must implement technical and organizational measures at the design phase. By default, only necessary data should be processed. Privacy can't be an afterthought bolted on after launch.

Article 26 addresses joint controllers. When two or more entities jointly determine purposes and means of processing, they must define their respective responsibilities through an arrangement. Individuals can exercise rights against any joint controller.

Article 27 requires non-EU controllers and processors to designate an EU representative in most cases. Exceptions exist for occasional processing of non-sensitive data and public authorities.

Article 28 regulates processor relationships. Controllers can only use processors who provide sufficient guarantees. Written contracts must specify the subject matter, duration, nature and purpose of processing, type of personal data, categories of data subjects, and obligations and rights of the controller. Processors need written authorization before engaging subprocessors.

Article 29 prohibits processors from processing data without controller instructions unless required by law.

Article 30 mandates record-keeping. Controllers and processors must maintain records of processing activities. This includes purposes of processing, categories of data subjects and personal data, recipients, transfers to third countries, storage periods, and security measures. Organizations with fewer than 250 employees get limited exemptions unless processing creates risks, occurs regularly, or involves special categories of data.

Article 31 requires cooperation with supervisory authorities. You must assist authorities upon request.

Article 32 establishes security obligations. Controllers and processors must implement appropriate technical and organizational measures considering the state of the art, implementation costs, and risks. This includes encryption, pseudonymization, ensuring confidentiality and integrity, regular testing, and documented processes for restoring availability after incidents.

Article 33 sets breach notification requirements. Controllers must notify supervisory authorities within 72 hours of becoming aware of a breach unless the breach is unlikely to create risks for individuals. Notifications must describe the nature of the breach, likely consequences, and measures taken to address it.

Article 34 requires notifying affected individuals of high-risk breaches. Notifications must be in clear language and explain the likely consequences and measures taken. Exceptions apply when data was encrypted, measures mitigated risks, or individual notification requires disproportionate effort (in which case public communication suffices).

Article 35 introduces data protection impact assessments. When processing operations present high risks, controllers must assess impacts before processing begins. This applies to systematic monitoring of public areas on a large scale, large-scale processing of special categories, and automated decision-making with significant effects. Assessments should describe processing operations, necessity and proportionality, risks to rights and freedoms, and measures to address risks.

Article 36 requires prior consultation with supervisory authorities when impact assessments show high residual risk. Authorities must provide written advice within eight weeks (or fourteen for complex cases).

Articles 37-39 cover data protection officers. Public authorities (except courts), organizations conducting large-scale systematic monitoring, and organizations conducting large-scale processing of special categories must appoint DPOs. DPOs must have expert knowledge, independence, and adequate resources. Their tasks include monitoring compliance, advising on obligations, cooperating with authorities, and serving as contact points.

Articles 40-43 promote codes of conduct and certification mechanisms. Industry associations can develop codes to specify GDPR application. Certification schemes allow organizations to demonstrate compliance. Both mechanisms aim to enhance transparency and accountability.

Chapter 5: Transfers of personal data (Articles 44-50)

Moving data outside the EU requires meeting specific conditions. These articles govern international transfers.

Article 44 establishes that transfers to third countries or international organizations must comply with Chapter 5 provisions while respecting other GDPR requirements.

Article 45 allows transfers to countries with adequacy decisions. The European Commission assesses whether third countries provide adequate data protection. Approved countries include Canada (commercial organizations), Japan, South Korea, Switzerland, and others. The Commission maintains and reviews this list.

Article 46 permits transfers with appropriate safeguards even without adequacy decisions. Standard contractual clauses provide the most common mechanism. Binding corporate rules allow multinational companies to transfer data within their organizations. Other options include codes of conduct with binding commitments and approved certification mechanisms.

Article 47 details binding corporate rules requirements. These legally binding internal rules must be approved by the lead supervisory authority. They must specify structure, data subject rights, complaint procedures, and enforcement mechanisms.

Article 48 prevents transfers solely because foreign court or authority requests them. Transfers must be based on international agreements or satisfy one of the GDPR's permitted transfer mechanisms.

Article 49 lists derogations for specific situations. Transfers can occur with explicit consent after information about risks, for contract performance, for important public interest reasons, to protect vital interests, from public registers, or for compelling legitimate interests (subject to strict conditions). These derogations apply only when adequacy decisions or safeguards aren't available and transfers aren't repetitive.

Article 50 encourages international cooperation. The Commission and supervisory authorities engage with third countries to develop adequate data protection frameworks.

Chapter 6: Independent supervisory authorities (Articles 51-59)

Each member state operates an independent supervisory authority responsible for enforcing GDPR.

Article 51 requires each member state to establish one or more supervisory authorities. These authorities cooperate to ensure consistent GDPR application.

Article 52 guarantees independence. Supervisory authorities act independently, free from external influence. Members serve fixed terms and can only be removed for serious misconduct.

Article 53 sets membership qualifications. Members must be appointed through democratic procedures. They need appropriate qualifications, experience, and skills.

Article 54 requires member states to establish rules for supervisory authority creation, including appointment procedures, qualifications, duties, powers, financial resources, and staff. Members are bound by confidentiality obligations.

Article 55 defines competence. Supervisory authorities monitor and enforce GDPR application in their territory. They don't supervise processing by courts acting in their judicial capacity.

Article 56 establishes lead supervisory authority rules. For cross-border processing, the authority in the member state where the controller's main establishment is located serves as lead authority. This mechanism aims to create one-stop-shop supervision.

Article 57 lists supervisory authority tasks. These include monitoring GDPR enforcement, promoting public awareness, advising national parliaments and governments, handling complaints, conducting investigations, and cooperating with other authorities.

Article 58 grants supervisory authorities extensive powers. Investigative powers include ordering information, accessing premises, and obtaining access to data. Corrective powers include issuing warnings and reprimands, ordering compliance, imposing temporary or permanent processing bans, and levying administrative fines. Advisory powers include providing opinions and authorizing contractual clauses.

Article 59 requires annual activity reports. These reports must be made public and transmitted to relevant institutions. They provide transparency about supervisory authority activities and enforcement actions.

Chapter 7: Cooperation and consistency (Articles 60-76)

These articles establish how supervisory authorities work together to ensure consistent GDPR application across Europe.

Articles 60-62 create cooperation mechanisms. The lead supervisory authority cooperates with other concerned authorities to reach consensus. Authorities provide mutual assistance and can conduct joint operations, allowing staff from one member state to operate in another.

Article 63 introduces the consistency mechanism to ensure uniform GDPR application.

Articles 64-66 govern the European Data Protection Board's role in maintaining consistency. The Board issues opinions on draft decisions concerning codes of conduct, certification criteria, standard contractual clauses, binding corporate rules, and adequacy decisions. The Board can make binding decisions to resolve disputes between supervisory authorities. Urgent procedures allow immediate protective measures when necessary.

Article 67 authorizes the Commission to specify information exchange formats through implementing acts.

Articles 68-76 establish the European Data Protection Board structure and operations. The Board consists of the head of each supervisory authority plus the European Data Protection Supervisor. It operates independently. The Board elects a chair and two deputy chairs for five-year terms. Decisions require simple majority votes. The Board adopts rules of procedure and maintains a secretariat. Discussions remain confidential where appropriate. The Board issues annual reports on data protection in Europe.

Chapter 8: Remedies, liability and penalties (Articles 77-84)

Enforcement mechanisms give the GDPR teeth. These articles outline how violations get addressed.

Article 77 grants individuals the right to lodge complaints with supervisory authorities. Authorities must inform complainants about progress and outcomes.

Article 78 allows individuals to bring judicial proceedings against supervisory authority decisions concerning them. Proceedings take place in the member state where the authority is established.

Article 79 gives individuals the right to effective judicial remedy against controllers or processors. Actions can be brought where the controller or processor has an establishment or where the individual resides.

Article 80 permits not-for-profit organizations to represent individuals in lodging complaints and exercising rights. Member states may also allow such organizations to lodge complaints independently.

Article 81 allows courts to suspend proceedings when related cases are pending in other member states.

Article 82 establishes liability and compensation rights. Anyone suffering material or non-material damage from GDPR infringements has the right to compensation. Controllers are liable for damage caused by processing infringing GDPR. Processors are liable for damage caused by violating processor-specific obligations or acting outside lawful controller instructions. Controllers and processors can escape liability by proving they weren't responsible for the damage.

Article 83 sets administrative fines. Two tiers exist. Lower-tier violations (like inadequate security measures, failing to notify breaches, or insufficient record-keeping) incur fines up to €10 million or 2% of annual global turnover, whichever is higher. Higher-tier violations (like processing without lawful basis, violating core principles, or infringing data subject rights) face fines up to €20 million or 4% of annual global turnover, whichever is higher.

Authorities consider multiple factors when imposing fines: nature, gravity, and duration of the infringement; intentional or negligent character; actions taken to mitigate damage; degree of responsibility; previous infringements; cooperation with authorities; categories of data affected; and whether the infringement was reported. The goal is proportionate, dissuasive, and effective penalties.

Article 84 allows member states to establish additional penalties through national law.

Chapter 9: Specific processing situations (Articles 85-91)

Certain contexts require special considerations. This chapter addresses specific scenarios.

Article 85 balances data protection with freedom of expression and information. Member states must provide exemptions or derogations for processing in the context of journalism, academic expression, artistic expression, or literary expression.

Article 86 addresses public access to official documents. Personal data in official documents can be disclosed when member state law reconciles access rights with data protection.

Article 87 allows member states to determine conditions for processing national identification numbers.

Article 88 permits member states to adopt more specific rules for employment contexts. These can address recruitment, performance of contracts, equality and diversity, health and safety, and exercise of rights.

Article 89 provides safeguards for archiving, research, and statistics. Processing for these purposes benefits from certain derogations to data subject rights, provided appropriate safeguards exist. Member states can introduce further derogations for these purposes.

Article 90 recognizes professional secrecy obligations. Member states may adopt rules regarding supervisory authority powers to access data held by professionals bound by confidentiality.

Article 91 allows churches and religious associations to maintain existing data protection rules if aligned with GDPR requirements.

Chapter 10: Delegated acts (Articles 92-93)

Article 92 grants the European Commission power to adopt delegated acts. These are legislative instruments that amend non-essential elements of the GDPR. The Parliament or Council can revoke this delegation or object to delegated acts.

Article 93 establishes a committee procedure to assist the Commission in adopting implementing acts.

Chapter 11: Final provisions (Articles 94-99)

These closing articles handle transitional matters and future reviews.

Article 94 repeals Directive 95/46/EC, the previous data protection directive. References to the old directive are now read as references to the GDPR.

Article 95 clarifies the relationship with the ePrivacy Directive (2002/58/EC). The GDPR doesn't impose additional obligations beyond those in the ePrivacy Directive. Both instruments apply together.

Article 96 addresses international agreements concluded before May 2016. These agreements remain in force until amended, replaced, or revoked.

Article 97 requires the Commission to submit evaluation reports every four years. These reports assess GDPR application and may propose amendments. The first report was due in 2020.

Article 98 directs the Commission to review other EU legal acts on data protection after GDPR evaluation.

Article 99 establishes that the GDPR entered into force on May 24, 2016, but applied from May 25, 2018. This gave organizations two years to achieve compliance.

Building compliance into operations

The GDPR contains detailed requirements affecting nearly every aspect of data handling. Organizations need systematic approaches to meet obligations across all 99 articles.

Modern compliance requires more than reading the regulation. You need processes for responding to rights requests within one-month deadlines. You need documentation demonstrating accountability. You need security measures appropriate to your risk profile. You need vendor contracts with proper data processing clauses. And you need mechanisms to track all of this.

Compliance software like ComplyDog helps organizations manage GDPR requirements systematically. These platforms provide templates for required documentation, workflows for rights requests, automated breach notification processes, and vendor risk assessments. Rather than building compliance infrastructure from scratch, businesses can implement proven frameworks that address articles across all chapters.

The regulation isn't getting simpler. But the tools for meeting its requirements continue to improve. Organizations that treat compliance as an operational capability rather than a legal checkbox put themselves in the best position to handle evolving data protection requirements.

The journey to ISO 27001 certification requires careful preparation, systematic planning, and a realistic understanding of where your organization stands today versus where it needs to be.

Table of contents

• Understanding ISO 27001 readiness
• Why readiness matters more than you think
• Core elements of ISO 27001 readiness
• Defining your organizational context
• Establishing scope and objectives
• Building your information security policy
• Risk management foundations
• Implementing Annex A controls
• Creating a culture of security awareness
• Documentation requirements
• Conducting internal audits
• Management review process
• Common readiness gaps
• Assessing your current readiness level
• Building your readiness roadmap
• How compliance software accelerates readiness

Understanding ISO 27001 readiness

ISO 27001 readiness refers to your organization's current state of preparedness for implementing an Information Security Management System (ISMS) that meets the standard's requirements. Think of it as a gap analysis between your current security posture and what the standard actually demands.

But it's more than just having the right security controls in place. Readiness means your organization has the structure, documentation, processes, and cultural buy-in needed to pass a certification audit. And trust me, auditors can smell unpreparedness from a mile away.

Many organizations make the mistake of thinking they're ready simply because they have firewalls, antivirus software, and some security policies sitting in a shared drive somewhere. That's like saying you're ready to run a marathon because you own running shoes.

True readiness involves systematic preparation across multiple dimensions: governance, risk management, operational controls, documentation, training, and continuous improvement mechanisms. Each piece matters.

Why readiness matters more than you think

Here's a scenario that plays out more often than it should: A company decides to pursue ISO 27001 certification because a major client demands it. They hire a consultant, schedule an audit, and assume they'll figure things out along the way. The audit happens. They fail spectacularly. Money wasted, time lost, and now they need to start over.

External auditors won't give you partial credit. They won't pat you on the back for "good effort." If you're not ready, you fail. Period.

Proper readiness assessment prevents this expensive mistake. It helps you understand exactly what needs to be done, how long it will realistically take, and what resources you'll need to allocate. You can't rush certification, but you can approach it intelligently.

There's also the internal benefit. Going through a readiness assessment forces your organization to take an honest look at how information security is actually managed (versus how leadership thinks it's managed). These are often two very different things.

Core elements of ISO 27001 readiness

The standard organizes requirements into several key areas. Let's break down what readiness looks like for each.

Information asset inventory

You need to know what you're protecting before you can protect it. This sounds obvious, but many organizations struggle with basic asset inventory.

Your asset inventory should include:

• Cloud services and platforms (Office 365, Google Workspace, AWS, etc.)
• Customer relationship management systems
• Financial systems and databases
• Collaboration tools (Slack, Teams, Zoom)
• Development and testing environments
• Physical servers and network equipment
• Mobile devices and endpoints
• Information stored with third-party vendors
• Paper records (yes, those still exist)

For each asset, document where it's located, who owns it, who has access to it, and what type of information it contains. This becomes the foundation for everything else.

Defining your organizational context

ISO 27001 requires you to understand both internal and external factors that influence your ISMS. This isn't busywork. It's about making sure your security program actually aligns with business reality.

Internal issues might include your organizational structure, company culture, existing policies and procedures, available resources, and strategic objectives. External issues cover regulatory requirements, customer expectations, competitive pressures, technological changes, and threat landscape.

You also need to identify interested parties (stakeholders) and document their requirements. This includes employees, customers, regulators, partners, suppliers, and shareholders. What do they expect from your information security program? Write it down.

This context analysis shapes how you design your ISMS. A startup with 20 employees working remotely needs a very different approach than a manufacturing company with 5,000 employees spread across multiple facilities.

Establishing scope and objectives

Scope definition is where many organizations trip themselves up. They either make the scope too broad (trying to cover everything) or too narrow (excluding critical systems to make certification easier).

Your ISMS scope should clearly define:

• Which parts of the organization are included
• Which locations are covered
• Which information assets fall within scope
• Which business processes are included
• Any exclusions and why they're excluded

The scope needs to be realistic and defensible. Auditors will challenge exclusions that seem arbitrary or that leave out obvious security risks.

Once scope is defined, establish security objectives that align with business goals. These should be specific, measurable, achievable, relevant, and time-bound. "Improve security" isn't an objective. "Reduce security incidents by 30% within 12 months" is.

Building your information security policy

Your information security policy is the high-level statement that sets the direction for your entire ISMS. It needs approval from top management, and it needs to be communicated across the organization.

A good policy includes:

• Purpose and scope of the ISMS
• Management commitment to information security
• Security objectives and principles
• Approach to risk management
• Roles and responsibilities framework
• Requirements for compliance
• Commitment to continual improvement
• Consequences for policy violations

The policy should be written in language that everyone can understand, not just the IT department. If your CEO can't explain what the policy says, it's not written correctly.

And here's something important: the policy needs to be more than a document gathering digital dust. People need to know it exists, understand what it means, and see it reflected in actual decisions and priorities.

Risk management foundations

Risk management sits at the heart of ISO 27001. The entire standard is built around identifying information security risks and implementing appropriate controls to address them.

Your risk assessment process should:

1. Identify information assets and their value
2. Identify threats to those assets
3. Identify vulnerabilities that threats could exploit
4. Assess the likelihood of each risk scenario
5. Assess the potential impact if risks materialize
6. Calculate risk levels based on likelihood and impact
7. Determine which risks are acceptable and which aren't

For risks that exceed acceptable levels, you need a risk treatment plan. Options include:

• Applying controls to reduce the risk
• Avoiding the risk by changing processes
• Transferring the risk (insurance, outsourcing)
• Accepting the risk with management approval

Document everything. Auditors will want to see how you identified risks, how you assessed them, what treatment decisions you made, and who approved those decisions.

The Statement of Applicability (SoA) is a critical document that lists all Annex A controls and indicates which ones apply to your organization. For each control, you need to justify why it's included or excluded based on your risk assessment.

Implementing Annex A controls

Annex A contains 93 security controls organized into four themes: organizational, people, physical, and technological. Not every control applies to every organization, but you need to consciously decide which ones are relevant based on your risk assessment.

Here's a breakdown of the control categories:

For controls you decide to implement, you need to show actual evidence of implementation. Saying you have access controls isn't enough. Auditors want to see access control lists, provisioning procedures, review logs, and termination processes.

Start with high-priority controls that address your most significant risks. You don't need to implement everything perfectly before pursuing certification, but you need to demonstrate meaningful progress and have plans for ongoing improvement.

Creating a culture of security awareness

Technology and policies mean nothing if people don't understand or follow them. Security awareness training is mandatory under ISO 27001, and for good reason.

Your training program should cover:

• Why information security matters to the organization
• Individual responsibilities for protecting information
• How to recognize common threats (phishing, social engineering)
• Password management and authentication requirements
• Acceptable use of company systems and data
• How to report security incidents
• Consequences of policy violations

Training can't be a one-time checkbox exercise. New employees need onboarding training, and all staff need regular refreshers. The threat landscape changes constantly, and so should your awareness efforts.

Consider different delivery methods for different audiences. Executives might need briefings on governance and risk. Developers need secure coding training. Sales teams need to understand data protection obligations. One-size-fits-all rarely works.

Documentation requirements

ISO 27001 requires specific documented information. You can't talk your way through an audit. Auditors need evidence.

Required documents include:

• Scope of the ISMS
• Information security policy and objectives
• Risk assessment methodology and results
• Risk treatment plan
• Statement of Applicability
• Operational planning and control procedures
• Information security incident management procedures
• Business continuity procedures
• Internal audit procedures
• Management review records

You'll also need operational procedures for how various controls are implemented. Access control procedures, change management processes, backup and recovery procedures, vendor management protocols, and incident response playbooks all need to be documented.

But documentation for documentation's sake is pointless. Focus on creating documents that people will actually use. If a procedure doesn't reflect how work really happens, either fix the procedure or fix the process.

Conducting internal audits

Before facing an external certification audit, you need to audit yourself. ISO 27001 requires at least one complete internal audit of your ISMS.

Internal audits serve multiple purposes:

• Verify that controls are implemented as intended
• Identify nonconformities before external auditors find them
• Gather evidence of ISMS effectiveness
• Identify opportunities for improvement
• Prepare staff for the certification audit experience

Your auditors should be competent and independent from the areas they're auditing. Someone from IT can audit HR processes, and vice versa. You can also bring in external resources if you lack internal audit skills.

Document audit findings, including both conformities and nonconformities. For any issues discovered, implement corrective actions and track them to closure. Auditors love seeing that you found problems yourself and fixed them proactively.

Management review process

Top management must review the ISMS at planned intervals. This isn't optional, and it can't be delegated entirely.

The management review should consider:

• Status of actions from previous reviews
• Changes in external and internal issues affecting the ISMS
• Feedback on information security performance
• Results from internal audits
• Nonconformities and corrective actions
• Monitoring and measurement results
• Opportunities for continual improvement
• Resource adequacy

The output should include decisions about improvement opportunities and any need for changes to the ISMS. Document everything in meeting minutes that demonstrate management engagement and decision-making.

Here's the reality: if executives treat the management review as a rubber-stamp exercise, auditors will notice. They ask questions. They probe decision rationale. Leadership needs to actually be involved.

Common readiness gaps

After working with dozens of organizations pursuing certification, certain gaps appear repeatedly:

Incomplete asset inventory. Companies know about their major systems but miss shadow IT, personal devices, and information held by contractors.

Weak access controls. User provisioning happens inconsistently, nobody reviews access rights regularly, and terminated employees still have system access.

Missing documentation. Processes exist in people's heads but aren't written down anywhere. When that person leaves or goes on vacation, knowledge walks out the door.

No incident response capability. Organizations assume they'll figure out what to do when something bad happens. That's not a plan.

Inadequate vendor management. Third parties have access to sensitive data, but nobody has reviewed their security practices or documented those relationships.

Poor change management. Systems get updated, configurations change, and nobody tracks the security implications.

Training that doesn't happen. A training program exists on paper, but actual delivery is sporadic and ineffective.

Identifying these gaps early gives you time to address them properly rather than scrambling right before the audit.

Assessing your current readiness level

So how do you actually determine if you're ready? Start by asking yourself these questions:

Does management understand what ISO 27001 compliance requires and why it matters? Can you produce a complete inventory of information assets and where they're located? Have you identified and documented information security risks? Do you have a risk treatment plan addressing unacceptable risks? Are relevant Annex A controls actually implemented (not just planned)? Can you demonstrate that people have received security awareness training?

If you answered "no" to multiple questions, you have work to do. That's fine. Knowing where you stand is the first step.

A structured readiness assessment can be more formal. Review each requirement in the standard against your current state. Rate your compliance as full, partial, or none. Calculate an overall readiness score.

Remember that these timelines assume dedicated effort and adequate resources. If this is a side project for already-busy staff, everything takes longer.

Building your readiness roadmap

Once you know where you stand, create a realistic plan for getting ready. Break the work into phases with clear milestones.

A typical roadmap might look like this:

Phase 1: Foundation (Months 1-3)

• Secure management commitment and resources
• Define scope and objectives
• Complete asset inventory
• Assign roles and responsibilities
• Develop core policies

Phase 2: Risk and controls (Months 4-6)

• Conduct risk assessment
• Create risk treatment plan
• Finalize Statement of Applicability
• Begin implementing priority controls
• Develop required procedures

Phase 3: Implementation (Months 7-9)

• Complete control implementation
• Deliver awareness training
• Document everything
• Establish monitoring and measurement

Phase 4: Testing (Months 10-11)

• Conduct internal audit
• Address nonconformities
• Perform management review
• Implement corrective actions

Phase 5: Certification (Month 12)

• Final readiness check
• Certification audit Stage 1
• Address any findings
• Certification audit Stage 2
• Receive certificate (hopefully)

Your timeline will vary based on organizational size, complexity, existing security maturity, and available resources. Be realistic. Rushing leads to mistakes and failed audits.

How compliance software accelerates readiness

Trying to manage ISO 27001 readiness using spreadsheets and shared drives is technically possible but incredibly inefficient. The documentation requirements alone can quickly become overwhelming.

Purpose-built compliance platforms transform the readiness process by centralizing everything in one system. Asset inventories, risk assessments, control implementations, policy documents, training records, audit findings, and management reviews all live in a single source of truth.

This matters because:

• Information stays current instead of becoming outdated the moment someone saves it
• Evidence collection for audits happens automatically through the platform
• Tasks and responsibilities are tracked systematically rather than falling through the cracks
• Progress visibility helps leadership understand where things stand
• Audit preparation becomes dramatically simpler

ComplyDog helps organizations prepare for ISO 27001 certification by streamlining the entire readiness process. The platform guides you through each requirement, helps identify gaps, tracks remediation efforts, and maintains the documentation auditors need to see.

Instead of wondering if you're ready, you can see exactly where you stand at any moment. The system tracks which controls are implemented, which risks are addressed, who completed training, and what still needs attention. When audit time comes, generating evidence takes minutes instead of weeks.

Getting ISO 27001 certified doesn't have to be a chaotic scramble. With proper readiness assessment, systematic preparation, and the right tools supporting your efforts, certification becomes an achievable milestone rather than an impossible dream.

Visit ComplyDog.com to see how compliance software can help your organization get ready for ISO 27001 certification faster and with far less stress.

The original Network and Information Security Directive (NIS1) tried to address these challenges when it came into force in 2016. But digital threats evolved faster than the legislation could keep pace with. Supply chains became more complex. Remote work expanded attack surfaces. Critical infrastructure grew increasingly interconnected (and vulnerable).

NIS2 represents the European Union's response to this escalating threat landscape. This updated directive doesn't just patch a few holes in the old framework. It completely overhauls how Member States approach cybersecurity for organizations that keep society running.

Table of contents

• Understanding the NIS2 Directive
• Why NIS2 replaced NIS1
• Who must comply with NIS2
• Essential vs important entities
• Cybersecurity requirements under NIS2
• Risk management measures
• Incident reporting obligations
• Supply chain security requirements
• Penalties for non-compliance
• National implementation and enforcement
• Cooperation mechanisms and networks
• NIS2 and other regulations
• Recent amendments and future changes
• Preparing for NIS2 compliance