On many products, GDPR arrives too late: once the SaaS is already live, the data is already collected, and technical choices are already fixed.
The result is almost always the same: compliance handled as catch-up work, more expensive, more defensive, and far less clean than framing it upfront. Yet the sensitive points were often visible from the design stage.
The minimal checklist before going live
Before launch, the right question is not “are we legally perfect?” It is “have we understood which data the product processes, why, with whom, and for how long?”
- Which personal data does the product actually process?
- Who can access it, under which role logic and with which logging?
- Are the vendor and subprocessors contractually framed?
- Can people be properly informed and exercise their rights?
- Have retention and deletion policies been designed?
The often underestimated point
GDPR is not only about documentation. It depends on very concrete product elements: where data appears, who sees it, how it moves, and how it gets deleted.
A product can have a correct privacy policy while still being badly designed from a compliance standpoint: permissions that are too broad, easy data export, incomplete deletion, or no clear logic for retention periods.
That is why a useful GDPR audit must also talk about roles, screens, architecture, and operations. Compliance is not only decided in a register; it is decided in how the tool actually works.
What France Num reminds us of
A solution can look simple, fast, and functional while actually processing a large amount of sensitive or structurally important data. The first task is therefore to map it properly.
That mapping must be concrete enough to inform product decisions afterward: admin screens, permissions, exports, subprocessors, retention, and the ability to answer data-subject requests.
Decisions to settle before launch
Before going live, several points need explicit decisions: which data is truly necessary, who can see it, which exports are allowed, and which traces must be kept to remain able to explain the processing.
This work may seem less spectacular than a product feature, but it prevents heavy corrective work later, commercial blockers, or improvised answers when a client, employee, or partner asks for guarantees.
The earlier compliance is integrated, the less it costs. Left too late, it turns into a heavy and defensive corrective project.
A good GDPR launch is therefore not one that merely “checks the box.” It is one where the product, the contracts, and operations finally tell the same story.
Sources
France Num - Evaluer la conformité RGPD d’une solution numérique : guide pratique
Published on April 13, 2026. The guide structures five simple questions to ask before choosing or deploying a solution.
Frequently asked questions
Who remains responsible for the data in a SaaS?
expand_more
The company choosing and using the tool remains responsible. The vendor must provide a framework, but that does not release the controller from responsibility.
Do you need to document everything before launch?
expand_more
At minimum, you need to document processing, flows, roles, legal bases, and key safeguards before real exposure of the product.