One person is enough for most B2B SaaS companies, provided that person is genuinely accountable and the work is written down. The GDPR never mentions a privacy team. It requires a controller to be responsible for compliance and able to demonstrate it, and a single named owner with a decision record satisfies that far better than a committee with no minutes.
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.
