A prospect’s security team just sent you a data processing agreement to sign, and you have no idea what half the clauses mean. That’s normal for a two-person Estonian SaaS - and the good news is that the real GDPR workload for a company your size is much smaller than the compliance industry wants you to believe, as long as you build the right handful of documents and skip the theatre.
The short answer
A small B2B SaaS is almost always both a controller (for its own staff, marketing leads and billing data) and a processor (for customer data it stores on their behalf) - the split matters because each role carries different duties.
The ‘fewer than 250 employees’ exemption from keeping a record of processing activities (Article 30) almost never applies to a SaaS, because ongoing, non-occasional processing of customer data disqualifies you from it regardless of headcount.
A written data processing agreement (DPA) under Article 28 is mandatory whenever you process personal data on a customer’s behalf - not optional paperwork, a legal requirement on both sides of your business.
Lawful basis in a B2B context is usually ‘necessary for performance of a contract’ (Article 6(1)(b)) for the service itself, and ‘legitimate interests’ (Article 6(1)(f)) for things like security logging or basic sales outreach.
A qualifying personal data breach must be reported to your supervisory authority within 72 hours of becoming aware of it (Article 33) - the clock starts on awareness, not on completing an investigation.
A data protection officer is rarely required for a company your size; it becomes mandatory only for public bodies, large-scale systematic monitoring, or large-scale special-category data processing (Article 37).
Are you a controller or a processor?
You are almost certainly both, and the answer changes by dataset, not by company. When you decide why and how data is processed - your own employee records, your marketing list, your billing data in your accounting system - you are the controller. When your customer decides why and how their end users’ data is processed, and you just run the infrastructure that stores or moves it, you are the processor, and your customer is the controller.
This distinction is exactly what a DPA is built around. Getting it backwards is the single most common mistake a small SaaS makes when a prospect’s legal team starts asking questions, because the obligations attached to each role are different and a generic answer (‘we take security seriously’) does not address either one.
Role | What it means | Concrete SaaS example |
|---|---|---|
Controller | You decide the purpose and means of processing; you carry the primary compliance duties toward the people whose data it is | Your own employee payroll data, your CRM of sales leads, your own marketing email list, analytics on your own website visitors |
Processor | You act only on the customer’s documented instructions; your duties run to the customer, not directly to their end users | Customer records your app stores for a client company, support tickets containing that client’s end users’ details, files a client uploads to your platform |
Both at once | Same company, different datasets, different rulebook for each | A helpdesk SaaS is the processor for the tickets it stores on behalf of a client, and the controller for the client’s own account and billing details |
What documents does a small SaaS actually need?
You need a small, specific document set, not a compliance department. Most of enterprise GDPR programmes exist to manage risk at a scale you don’t have; a two-person SaaS needs roughly six documents, each doing one job, and nothing more elaborate than that until you actually grow into needing it.
Document | What it’s for | Who needs it from you | When it’s actually used |
|---|---|---|---|
Privacy policy | Tells your own website visitors and users what you collect and why | Anyone visiting your site or signing up | Published permanently; reviewed on any product change |
Data processing agreement (template) | Governs how you process a customer’s data as their processor | Every B2B customer, standard or asked-for | Signed alongside or shortly after the main contract |
Subprocessor list | Discloses which third parties (hosting, email, analytics, support tools) touch customer data | Customers and prospects, especially during procurement | Kept current; shared proactively or on request |
Record of processing activities | Internal map of what data you process, why, where it’s stored, how long you keep it | Yourself, and the supervisory authority if it ever asks | Built once, updated when you add a new tool or data type |
Breach response checklist | A short, pre-written playbook so you’re not improvising under pressure | Yourself, your team, occasionally your customers’ contracts require notice | Only when something actually goes wrong - but written before that happens |
Data subject request procedure | A one-page process for handling access, deletion and correction requests | People whose data you hold, on request | Whenever someone actually asks - rare for most small SaaS, but must exist |
Do you need a record of processing activities?
Yes, in practice - even though the law technically offers you an exemption. Article 30 lets an organisation with fewer than 250 employees skip the record of processing activities, but only if the processing is occasional, unlikely to risk people’s rights and freedoms, and doesn’t involve special-category data. A SaaS running ongoing customer accounts, support tickets and analytics fails the ‘occasional’ test on day one, because none of that is occasional - it’s the business.
The European Data Protection Board has been explicit that normal, everyday business activity - running a website, keeping employee records, using analytics, sending marketing emails - does not count as occasional processing. That’s why this exemption is one of the most misunderstood parts of GDPR: founders read ‘250 employees’ and assume they’re covered, when the actual gate is the nature of the processing, not the headcount.
The upside is that building the record is a genuinely small task at your size. List each category of data you hold (customer account data, support content, employee data, marketing leads), why you process it, where it’s stored, how long you keep it and who else touches it. A spreadsheet with one row per data type is a legitimate, defensible record of processing activities for a company your size - it just has to exist and be kept current.
Do you need a data processing agreement with your customers?
Yes, without exception, whenever you process personal data on a customer’s behalf. Article 28 requires a written contract between controller and processor that sets out the subject matter and duration of processing, its nature and purpose, the type of data and categories of people involved, and the obligations and rights of both sides. A generic terms-of-service clause that vaguely mentions ‘data protection’ does not satisfy this - the DPA has to actually cover those points.
In practice this means you should have a standard DPA template ready before anyone asks for one, not scrambled together the day a prospect’s procurement team requests it. Keep it short, keep it accurate to what you actually do, and don’t promise controls you don’t run (SOC 2, dedicated DPO, 24/7 monitoring) just because a template you copied includes them - an inaccurate DPA is worse than a modest, honest one.
State clearly which of you is the controller and which is the processor for the data covered by that specific contract.
List the categories of data and categories of people whose data is processed (e.g. ‘end user account data of the customer’s own users’).
Commit to processing only on the customer’s documented instructions, and to confidentiality obligations for your staff.
Name your subprocessors, or link to a subprocessor list you keep updated - this is the clause procurement teams read most carefully.
Set out how you’ll assist with data subject requests, security incidents and, if relevant, audits.
Specify what happens to the data at the end of the contract - deletion or return, and within what timeframe.
What about your own subprocessors?
Every tool that touches your customers’ data on your behalf - your cloud host, your email provider, your support-ticket software, your analytics vendor - is your subprocessor, and you need your own agreements with them, just as your customers need one with you. Most reputable providers (AWS, Google Cloud, Microsoft, Stripe, Intercom-type tools) already publish a standard DPA you can accept; the practical work is making sure you’ve actually accepted it, not assuming it’s covered because you pay them.
Here’s the part that’s easy to miss: your subprocessor list is a sales document as much as a legal one. A security-conscious prospect will read it before they read your DPA, because it tells them exactly where their data will actually sit. Keep the list short, accurate and boring - fewer, well-known subprocessors read as more trustworthy than a long list of small tools, even if the long list is technically fine.
What’s your lawful basis for processing in a B2B context?
For the core service - creating an account, storing the data your product needs to function, billing the customer - your lawful basis is almost always necessity for performance of a contract (Article 6(1)(b)). You don’t need separate consent to process the data your product literally requires to work, and asking for consent for that would actually be the wrong approach.
For adjacent activities - security logging, fraud prevention, basic product analytics, cold outreach to similar B2B contacts - legitimate interests (Article 6(1)(f)) is usually the right basis, provided you can show the interest is real, the processing is proportionate, and it doesn’t override the individual’s rights. Consent (Article 6(1)(a)) matters mainly for marketing emails to people who aren’t already customers, and for any non-essential cookies or tracking on your marketing site - keep those two situations separate from your core product processing.
How do you handle a data subject request without a system?
A request from a person asking to see, correct or delete their data doesn’t require a ticketing platform - it requires a written process you actually follow, even if that process is three steps long. Confirm who’s asking and verify their identity reasonably, locate the data across the tools you actually use (your database, your email tool, your support software), and respond within the timeframe GDPR expects, generally without undue delay and within one month, extendable in complex cases.
Log the request with the date it arrived - this matters if you ever need to show you met the deadline.
Identify every system where that person’s data lives; your record of processing activities (see above) is exactly what makes this step fast instead of a scramble.
Take the requested action - export, correct or delete - and confirm to the person in writing what you did.
If you’re a processor for that data (it belongs to one of your customers, not to you), forward the request to that customer instead of acting on it yourself, unless your DPA says otherwise.
What happens if you have a data breach?
If a breach is likely to risk people’s rights and freedoms, you must notify your supervisory authority within 72 hours of becoming aware of it (Article 33). Not all breaches trigger this - a laptop stolen from a locked office with encrypted, useless-to-a-thief data may not - but the threshold for ‘likely to result in a risk’ is lower than most founders assume, and the clock starts when you have reasonable certainty something happened, not once you’ve finished investigating it.
If the risk is high enough, you may also have to notify the affected individuals directly, in plain language, describing what happened and what you’re doing about it. If you’re a processor rather than a controller for the affected data, your job is different: notify the controller (your customer) without undue delay, and let them decide on notification to the authority and to individuals, since they carry that primary duty.
Write your breach response checklist before you need it - who investigates, who decides on notification, who drafts the message.
Document every breach internally regardless of whether you notify anyone, including near-misses - GDPR requires this record even for incidents you conclude don’t need reporting.
If in doubt about the 72-hour window, notify with the information you have and flag that more will follow - a reasoned, incomplete notification on time beats a complete one that’s late.
What if your infrastructure sits outside the EU?
If any of your subprocessors - hosting, email, support tools, analytics - store or process personal data outside the EU/EEA, you need a valid transfer mechanism. The European Commission maintains adequacy decisions for a number of non-EEA countries and regions, covering data sent there without extra paperwork; for everywhere else, the standard tool is the Standard Contractual Clauses (SCCs), the European Commission’s pre-approved contract text for exactly this situation.
Most large providers (AWS, Google Cloud, Microsoft) already have SCCs baked into their standard terms, so your real job is checking that you’ve accepted them, not drafting your own. The remaining honest work is a light-touch transfer impact assessment: a short note confirming you’ve considered whether the destination country’s laws could undermine the protections SCCs are supposed to provide, kept on file rather than published anywhere.
Do you genuinely need a data protection officer?
For almost every small SaaS, no. A DPO is mandatory under Article 37 only for public authorities, organisations whose core activity involves large-scale systematic monitoring of individuals, or those doing large-scale processing of special-category data (health, biometric, criminal-record data, and similar). A B2B SaaS selling project-management or invoicing software to European companies fits none of these categories.
You can appoint one voluntarily, but that obligates you to give them the full formal role and independence the law describes - not a title handed out informally. For most two-person teams, the better move is designating one founder as the internal contact for data protection questions, rather than manufacturing a DPO role you don’t need.
Who enforces GDPR in Estonia?
The Estonian Data Protection Inspectorate (Andmekaitse Inspektsioon, AKI), based in Tallinn, is Estonia’s supervisory authority under GDPR - the body you’d notify in a qualifying breach and the one that would investigate a complaint against your company. It also acts as Estonia’s freedom-of-information regulator, and it publishes guidance and takes questions through its advisory channels, which is a reasonable first stop if you have a specific, unusual question a generic guide like this one can’t answer.
What’s the actual enforcement risk for a company your size?
Be honest with yourself about where the real risk sits. Large, headline fines are reserved almost entirely for large processors of personal data with millions of records and systemic failures - that isn’t the risk profile of a two-person SaaS with a modest customer base. The far more common, and far more expensive, consequence of poor GDPR hygiene at your size is a lost enterprise deal: a security review that stalls indefinitely because you couldn’t produce a DPA, a subprocessor list, or a straight answer about where customer data lives.
For a small SaaS, GDPR risk rarely shows up as a fine - it shows up as a procurement team that quietly stops replying.
That reframes the exercise usefully. You’re not building this document set to avoid a regulator’s attention; you’re building it so that when a prospect’s legal team asks for a DPA, a subprocessor list and a clear answer on breach notification, you can produce all three in an afternoon instead of losing the deal to the delay. Treat the six documents above as sales infrastructure - the compliance benefit follows naturally.
Frequently asked questions
Do I need a lawyer to write my DPA?
Not necessarily for a first draft - many reputable, freely available DPA templates cover the Article 28 requirements adequately for a small SaaS, and you can adapt one to describe accurately what you actually do. It’s worth a lawyer’s review once you’re signing DPAs regularly or a customer pushes back on specific clauses, but you don’t need bespoke legal drafting to get started.
Is e-Residency or being an Estonian OÜ relevant to any of this?
Not directly - GDPR applies based on where your customers and users are and what data you process, not based on your company’s country of incorporation or the founder’s e-Residency status. An Estonian OÜ selling to customers across Europe is squarely inside GDPR’s scope regardless of where the founders live, in the same way any EU-established company would be.
What if a prospect asks for something my company genuinely doesn’t have, like SOC 2?
Say so plainly rather than implying you have it. Many procurement teams have a tiered process and will accept a smaller vendor without SOC 2 if you can show a clear, honest security and data-protection posture - a DPA, a subprocessor list, a breach process. Claiming a certification you don’t hold is a far bigger risk to the deal, and to your credibility, than admitting you’re early-stage.
Can I just use my terms of service instead of a separate DPA?
Only if those terms actually contain everything Article 28 requires - subject matter, duration, nature and purpose of processing, categories of data and people, and the specific processor obligations. Most standard terms of service don’t cover this in enough detail, which is why a dedicated DPA, even a short one, is the safer and more common approach.
How long do I have to respond to a data subject request?
Generally one month from receiving the request, extendable by up to two further months for complex or numerous requests, provided you tell the person about the extension and why within the first month. Don’t wait until the deadline to start looking - locating the data is usually the slow part, not deciding what to do with it.
Does a breach at my hosting provider count as my breach?
If your hosting provider is your subprocessor and the breach affects personal data you’re responsible for, yes - you as the processor (or controller, depending on the data) still carry the notification duty toward your own customers or the supervisory authority, even though the failure happened at your provider. Your agreement with that provider should require them to notify you promptly so your own 72-hour clock isn’t running blind.
Do I need consent banners on my marketing website?
If you use non-essential cookies or tracking (most analytics and ad-retargeting tools), yes, you generally need a consent mechanism before those load - this sits alongside GDPR under EU cookie/ePrivacy rules rather than being a separate regime, but it’s the same visitor-facing obligation founders often forget while focused on the B2B DPA side of the business.
What’s the single most common mistake small SaaS founders make here?
Treating this as either a total non-issue (‘we’re too small for GDPR’) or an enterprise-scale project needing a compliance hire. Neither is accurate. The realistic middle ground is the document set in this article, built once, kept current, and produced promptly when a customer asks - for a company your size, that’s most of what GDPR requires in practice.
This article is general information, not legal advice - for a specific contract, prospect requirement or incident, get advice from a qualified lawyer or talk to the Estonian Data Protection Inspectorate directly.
