Establish what you actually hold
A clear picture of the data in the business, where it came from and why it is still there.
Technology
Data and privacy.
Data obligations are usually described as a compliance exercise. For a growing product they arrive as something much more immediate: a customer security questionnaire that stalls a deal, a request from an individual that nobody can answer, or an incident on a Friday afternoon. What decides how those go is whether anybody knows what the business actually holds.
What this looks like when it goes wrong
The usual starting point is that nobody knows what is held. Data has accumulated across analytics, support tickets, logs, exports sitting in spreadsheets, an old customer system nobody has logged into for a long time, and a test environment quietly holding real records. There was never a decision to collect most of it. It arrived as a side effect of building.
The version that costs money first is commercial. An enterprise customer sends its security and data questions, and the answers do not exist in a form anybody can give. Data posture becomes a sales problem long before it becomes anything else.
Then there is the question of role, which almost nobody settles at the right time. Whether you hold information for your own purposes or on behalf of a customer changes what you owe and what has to be in the contract, and most products do both across different features. Agreements written as though the answer were obvious tend to be the ones that unravel first.
The worst version is an incident. Something is noticed by an engineer, escalated informally, and within an hour people are making decisions about what to say and to whom, without knowing what happened, what was affected or who is entitled to be told. The decisions that matter most get taken while the facts are still arriving.
What actually decides it
Knowing what you hold decides everything downstream. Where it came from, why you have it, where it sits, who can reach it and how long it stays. You cannot answer a request from an individual, honour a deletion, describe a system honestly in a notice, or scope an incident without it. The obligations themselves are general in shape: have a proper reason for each use, be straight with people about it, collect and keep no more than you need, keep it secure, and be able to show that you do.
Role decides the paperwork. Acting for your own purposes and acting on a customer instruction carry different duties and require different terms, and the answer is reached activity by activity rather than company by company. A product that handles customer records on instruction while also using aggregate information for its own purposes is doing both.
Your obligations do not stop at the edge of your own infrastructure. Hosting, analytics, support tooling, payment providers, subcontracted engineering and any feature built on a third party model all sit in the chain, and what those suppliers are permitted to do with what passes through them is a matter of their terms, not of your intentions. Where information moves between countries, the arrangements that support it have changed more than once and continue to move, so what matters is having a position that can be adjusted rather than one that assumes permanence.
Most of the rest is product design. Consent and choice presented honestly, defaults that do not quietly collect more than the feature needs, retention rules that something actually enforces, and the ability to export and delete an account cleanly. Building deletion into a system that was never designed for it is the expensive version of this work. Incident readiness is the same idea applied to a bad day: deciding in advance who is told, who decides, who speaks and where the records are, so that the first hour is spent on facts rather than on organisation.
What we do
Roles and contracts
Whether you act for yourself or on instruction, feature by feature, and terms that reflect the answer.
Suppliers and the chain
What the vendors and tools behind your product are permitted to do with what passes through them.
Notices and policies people follow
Documents written to describe the product as it works, rather than to describe a business in general.
Requests from individuals
A route for handling requests that does not consume engineering attention on every occasion.
Incident readiness
Decisions taken in advance about who is told, who decides and who speaks, so the first hour is not wasted.
When to spend nothing
A small product holding very little about anybody does not need a programme, a certification or a consultant. It needs an honest inventory, a notice that describes what actually happens, and terms with the handful of suppliers that touch anything. That is a short piece of work, and doing it well is worth more than buying a framework that nobody in the business will maintain.
The judgement to make is about direction of travel. If the plan is to sell to larger organisations, the security questionnaire is the moment the position gets tested, and it is much cheaper to build for it while the systems are small than to retrofit once there are customers depending on them. If that is not the plan, and the product touches little of consequence, then restraint is the right answer. Collecting less is the only measure that reduces risk and cost at the same time.
Before anything is sent
Positions harden the moment the other side takes advice, and the quiet routes stop being available once a demand has gone out. While nothing has been sent, everything is still open.