The expensive misconception about GDPR is that it is something you "do once", a 2018 project that ends with a privacy policy, a cookie banner, and a binder somewhere. The directive itself is much sharper: data protection is a continuous obligation, and every meaningful product change can trigger a new round of work.
For an SMB without a full-time DPO, that creates a familiar pattern. The project finishes. Six months pass. A new feature ships. A new sub-processor is added. A new market is entered. And nobody checks any of those against the original assessment. The next time anyone looks, the documentation no longer matches reality, and the only person who notices is the one investigating the breach.
The fines are not theoretical anymore
For the first three years after the regulation came into force, enforcement was concentrated on the largest tech companies. That pattern has reversed. SMBs now make up the majority of fines by count, even if the largest names still take the headlines.
| Company | Sector | Year | Fine |
|---|---|---|---|
| Meta (Ireland) | Social | 2023 | €1.2B |
| Amazon (Luxembourg) | Retail | 2021 | €746M |
| TikTok (Ireland) | Social | 2023 | €345M |
| Uber (Netherlands) | Mobility | 2024 | €290M |
| Mid-size German publisher | Media | 2024 | €8.2M |
| Spanish online retailer (Cat-A) | Retail | 2025 | €2.4M |
| French B2B SaaS | Software | 2025 | €640k |
| Italian booking platform | Travel | 2025 | €420k |
| Median SMB enforcement action | Various | 2025 | €340k |
The pattern in the lower half of the table is consistent: the underlying violation is rarely sophisticated. Failure to obtain valid consent, processing without a legal basis, missing or stale sub-processor documentation, unencrypted personal data, missed breach-notification windows. These are documentation failures, not technical ones.
Why the workflow drifts
The structural issue for SMBs is that the work to "stay compliant" is split between three people who do not talk to each other:
- The engineers who add a new feature and integrate a new vendor.
- The operations or legal lead who maintains the records of processing activities (Article 30).
- The founder or executive who signed the original DPAs.
Without a workflow that connects them, every feature ship becomes a quiet drift away from documented compliance. By the time an auditor or a regulator asks, the gap is months wide.
"The regulator did not ask us if we had GDPR. They asked us to produce the DPIA we updated when we added Stripe in March. We did not have one." CTO, German B2B SaaS, settled €640k in 2025
How we rebuilt the workflow
The GDPR Companion inside CyberDebunk is built around three observations.
First, every meaningful compliance event is triggered by a change in the codebase or the infrastructure. A new feature flag, a new STRIPE_KEY, a new container pulling a new image, a new column in a database. The system that already watches your dependencies is also the system that can flag a compliance impact.
Second, the documents that auditors and regulators actually look at are predictable. Record of processing activities (Article 30), Data Protection Impact Assessment (Article 35), sub-processor list, breach register, technical and organizational measures (Article 32). Six artifacts. Generating them from live system state is more reliable than maintaining them by hand.
Third, the part nobody wants to do is the writing. A six-question intake plus the existing inventory is enough to produce a serviceable first draft for any of those documents. Iteration with a human reviewer is faster than starting from a blank page.
From feature ship to documented DPIA, in one workflow
What the six questions are
- What new data is being processed? Personal? Special-category? Children?
- What is the legal basis? Consent, contract, legitimate interest, legal obligation, vital interests, public task.
- Who has access? Internal roles, external processors, third-country recipients.
- How long is it retained? Specific period, or until what trigger.
- What are the security measures? Encryption, access control, audit logging.
- What is the rights workflow? Access, rectification, erasure, portability, objection.
Most of these are answered automatically from the scanner's existing knowledge of the codebase. The DPO or founder confirms or corrects. The output is a versioned, audit-trail-backed document that updates every time the underlying system changes.
The Article 30 register, regenerated continuously
Most SMBs we work with have an Article 30 register that was last touched in 2019. The version control is "the file in someone's Dropbox". When asked to produce it for an audit, they produce something that does not match their stack.
The Companion keeps the register live. Every processing activity is a row. Each row maps to (a) the data category, (b) the legal basis, (c) the sub-processors involved, (d) the retention policy, (e) the technical measures. When any of those change in the codebase, the row updates. When an auditor asks, you export the current state, including a diff against any prior date.
Adding Stripe is no longer a compliance event you have to remember.
The scanner already inventories every third-party API your code calls. When a new external service appears, a payment provider, an analytics tool, a transactional email service, the Companion flags it as a candidate sub-processor, prompts you for the data categories it sees, and updates your sub-processor schedule. You sign the DPA from inside the dashboard. The audit log records that you did, and when.
Reasonable defaults are pre-filled for the ~200 most common services. The first time you add resend.com, the Companion knows it is a transactional email provider hosted in the US, requires SCCs, and proposes the appropriate documentation.
What this costs you
For an SMB with under 50 employees and a single product, our customers report spending under 90 minutes per month on the actual GDPR maintenance work, reviewing what the Companion has drafted, confirming sub-processor changes, signing off on DPIA updates. The rest is automation. Compare that to the typical "GDPR project" cost of €20-40k for the initial setup and €4-8k per quarter for external audits.
This is not a sales pitch for the GDPR product. The point is structural: compliance is a workflow problem more than a legal one, and SMBs lose because they treat it as a legal one. Embed it into the existing engineering workflow, and the cost drops by an order of magnitude. The fines drop by more.
What to do this week, even if you do not use us
- Find your Article 30 register. Open it. Check the last-modified date. If it is older than your most recent feature ship, it is wrong.
- List every external API your codebase calls. Compare against your signed DPA list. Any gap is a sub-processor you are using without documented authority.
- Set a 72-hour reminder for breach notification. The regulation gives you 72 hours from awareness. Most SMBs we have audited cannot actually meet it, because the chain of escalation is undefined. Define it now, in writing.
- Designate someone. You do not need a certified DPO unless you process at scale or sensitive categories. But you need one named person who owns the workflow. Without ownership, this all drifts.
The European framing of GDPR is not adversarial. The regulators we have spoken to are blunt: they want documentation that proves you tried. The fines fall on the companies that cannot produce one. Make production of that document a side-effect of your engineering workflow, and the bar becomes trivial to clear.