GDPR for SaaS: a compliance checklist before going live

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.

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.

GDPR compliance happens in the product, not only in documents

CNIL and France Num sources remind us of an often underestimated idea: compliance is not only a privacy policy or a register stored in a folder. In a SaaS or web application, it happens in screens, permissions, exports, logs, retention periods, forms, and the ability to concretely answer data-subject requests. A product can have correct legal wording while being poorly designed to respect GDPR day to day.

The first product requirement is minimization. If data is not necessary, it should not be collected. If it is only necessary at a given moment, it should not remain accessible indefinitely. This logic must appear in forms, databases, exports, dashboards, and admin rights. Minimization is not a legal abstraction: it is a design and architecture decision.

The second requirement is explainability. A team must be able to say why a data point exists, who accesses it, how long it is retained, which processor receives it, and how it can be deleted or corrected. If these answers require manual investigation across several tools, the product is not ready. The problem is not only regulatory; it also becomes operational, because each user request may consume too much time.

The third requirement is access limitation. Many products start with roles that are too broad because it is simpler to develop. But as the team grows, these shortcuts become risks: support sees too much data, sales export too easily, administrators lack role separation, sensitive actions are not traced. A useful GDPR checklist must therefore enter permissions, not only legal pages.

The product checklist before going live

Before launch, GDPR principles must be turned into visible controls inside the application.

• Map personal data by screen, table, form, export, integration, and provider.
• Remove fields collected “just in case,” or clearly justify their purpose and retention period.
• Define strict roles: read, modify, export, delete, administration, support.
• Plan user request workflows: access, rectification, objection, deletion, portability where applicable.
• Log sensitive actions, especially exports, permission changes, deletions, and administrator access.
• Verify that legal wording matches how the product actually works, not a theoretical intention.

How to turn this reading into a decision

To use this article properly in an executive meeting, it should be read as a decision grid, not as simple market watch content. The topic “GDPR for SaaS: a compliance checklist before going live” should lead to a visible decision: continue with the current setup, scope a short project, launch an audit, prioritize one workflow, hire, outsource, or deliberately postpone the subject. Without an explicit decision, even good analysis remains theoretical. The right format is to summarize the problem in one sentence, name the main risk, estimate the cost of inaction, then choose a dated next step.

The sources used in this article are precisely there to avoid intuition-only decisions. They provide an external frame: public best practices, maturity signals, compliance requirements, testing methods, or experience feedback. They should not be copied mechanically. They should be translated into your context: team size, workflow criticality, debt level, data handled, tool dependency, user maturity, and the real ability to maintain the solution after launch. That translation is what separates a useful SEO article from superficial content.

The right operational output is a three-level mini-plan. First, what must be checked this week: access, data, hidden cost, metrics, dependencies, responsibilities, or commercial hypothesis depending on the topic. Then, what must be scoped over thirty days: perimeter, budget, governance, owner, risks, and success criteria. Finally, what deserves deeper work: architecture, migration, compliance, industrialization, hiring, or redesigning a business workflow. This progression avoids vague large projects and turns analysis into concrete movement.