By
Logiks Lab
Published on
August 8, 2026
Updated on
August 8, 2026

Data governance and compliance: quality, GDPR, traceability and lifecycle control

Data governance organises responsibilities, definitions, rights, quality and traceability from data collection through deletion. It is neither limited to GDPR nor reducible to a technical catalogue. This guide follows the lifecycle of a customer record, proposes a proportionate control model and incorporates recent European developments, including the Data Act applicable since September 2025.

Team working at a computer, illustrating data governance and data compliance.
Type
Practical guide
Level
Intermediate
Reading time
16
Progress0 %

In isolation, information is rarely dangerous or useful. Context determines its significance: why it was collected, who understands it, who can access it, what other information it is combined with, how long it remains available and which actions it triggers.

The same phone number can be used to deliver an order, follow up with a prospect, authenticate an account or enrich a profile. These uses do not serve the same purpose, create the same expectations or necessarily rest on the same legal basis.

This governance framework makes those differences visible and enforceable. It must answer one simple question quickly: “Show me where this data comes from, why we hold it, where it flows and how we correct or delete it.”

1. Key figures: data has become an everyday operational risk

The CNIL received 20,150 complaints in 2025, a record and a 10% increase over 2024. About 1,900 related directly to personal data breaches. These figures cover a wide range of situations, from the workplace to social networks, and show that people’s expectations translate into concrete demands.

In the same year, 6,167 personal data breaches were reported to the CNIL. Half involved hacking. The authority also highlights increasingly large-scale breaches and the frequent involvement of service providers. Mapping must therefore extend beyond internal systems.

In 2025, the CNIL conducted 323 inspections and issued 259 corrective decisions, including 83 sanctions. Fines totalled EUR 486,839,500, a figure heavily influenced by two major decisions. That aggregate cannot predict an individual sanction; 143 formal notices and 31 reminders of legal obligations demonstrate the broader range of enforcement responses.

Cybersecurity accounted for one third of inspections and almost 30 per cent of sanctions. In 2026, the CNIL announced that it would devote 50% of its inspections and enforcement actions to data security. Quality and compliance therefore cannot be managed separately from access controls, backups and service providers.

On the usage side, Eurostat estimates that 39.85% of European Union enterprises with at least ten employees performed data analysis in 2025, either internally or through a service provider. The expansion of processing, AI and data sharing inherently increases the need for provenance and reusable controls.

2. The master register of processing activities and data assets

The GDPR record of processing activities remains central, but operational governance must connect it to a broader data register.

Each entry describes:

FieldQuestion to answer
PurposeWhat legitimate result is being pursued?
PeopleWho is affected, including indirectly?
DataWhat categories are needed?
SourceIndividual, partner, device or inference?
Legal basisWhat lawful basis supports the processing?
OwnerWho decides the meaning and accepts the risk?
SystemsWhere are the data stored, including copies, caches and backups?
RecipientsWhich teams and third parties receive the data?
LocationIn which countries are the data stored and accessed?
RetentionWhat event triggers archiving and deletion?
RightsHow is a request propagated?
QualityWhat thresholds make the data usable?
SecurityWhich classification, access, encryption and logging controls apply?
EvidenceWhat documents and controls demonstrate this?

This record is not completed once and forgotten. It has an owner, a review date and links to the relevant systems. A change in purpose, provider or retention period triggers an update.

The legal register and technical catalogue are kept in sync. The first explains why the data is processed; the second shows where and how. Neither is sufficient on its own.

3. The lifecycle of a customer record

Follow one person’s email address from its collection in a form through to deletion.

Nine-stage governance lifecycle for a customer record, from design to deletion.
Compliance is not a document relegated to an appendix; it becomes an enforceable property of the data lifecycle.

3.1. Design the collection

The team defines the purpose before defining the field. If an email address is used to send a quote, a date of birth is probably unnecessary. Data minimisation prevents collection “just in case”.

The privacy information provided to the individual describes the purposes, controller, lawful basis, recipients, retention period, rights and contact details. It must reflect actual operations, including advertising tools and service providers.

The form distinguishes what is necessary to provide the service from what is optional. When consent is used, it must be specific, informed, unambiguous and as easy to withdraw as to give. It is not a universal lawful basis for all processing activities.

3.2. Validate on entry

The system checks format, domain, duplicates and source. It retains the timestamp and form version. An invalid value is corrected carefully or flagged; automatically inventing a replacement can undermine both data quality and individual rights.

Data quality starts here. An incorrect email address can prevent delivery of a service or send information to a third party. Technical validation therefore also protects the individual.

3.3. Record purpose and evidence

The address is not copied in isolation. It remains linked to its context: a quote request, customer account, subscription or contractual relationship. Where several purposes exist, they are recorded separately.

Evidence does not necessarily require storing a complete screenshot. Proportionate records are retained: text version, source, date, choice and identifier. Logs themselves also have a retention period.

3.4. Authorise access

The CRM enforces role-based access. A salesperson sees only prospects in their assigned territory. Support accesses only the customers it serves. Bulk exports are restricted and logged.

Access rights are reviewed when someone joins, changes role or leaves. An inactive account is not an archive; it is a potential point of entry.

Test environments use synthetic or properly pseudonymised data wherever possible. Copying the production database to a developer’s computer creates a new purpose and a new risk.

3.5. Share with a service provider

Before sharing data, the company determines whether the recipient is a processor, joint controller or independent recipient. The contract specifies instructions, confidentiality, security, sub-processors, assistance with rights, personal data breaches, return or deletion of data, and audit rights.

The true processing location includes support, backups and telemetry. Hosting in an EU region does not prove that nobody outside the EU can access the data.

The list of service providers is linked to the master register. When a contract ends, deletion is requested and evidenced; copies held in integrated tools must not be overlooked.

3.6. Transform and infer

The company may calculate a purchase-propensity score or customer segment. This new information is inferred data with its own definition, date, method and retention period. It is not “true” in the same way as an observed order.

Profiling is assessed according to its impact. Advertising, fraud-risk assessment and decisions with significant effects require different controls. Data subjects must be able to exercise their rights under the applicable framework.

Models and evaluation datasets are versioned. A correction to source data must be capable of propagating downstream or triggering recalculation.

3.7. Correct

A person reports an incorrect address. The system of record is corrected, then the change is propagated to downstream systems. The old value may remain in an audit log or backup for a justified period, subject to restrictions.

The lineage graph identifies every copy. Without it, the team may report the record as “corrected” while the marketing platform, data warehouse and support tool retain the error.

3.8. Retain based on triggering events

A fixed period is not always sufficient. Data may be retained during the contractual relationship and then for a further period tied to legal obligations or disputes. The triggering event must be defined: last qualified interaction, end of contract or case closure.

Dormant data is archived with more restricted access. Retention should not be extended simply because storage is inexpensive.

Backups follow a separate lifecycle. They are protected, expire and are not used for day-to-day operations. A deletion instruction may be replayed when a backup is restored to prevent deleted data from reappearing.

3.9. Delete or anonymise

Deletion covers the primary database, satellite tools, search indexes, embeddings, exports and local files. The system produces evidence of execution and reports every failure.

Anonymisation must reasonably prevent re-identification. Removing a name usually amounts only to pseudonymisation if history, location or another identifier can still reveal the person.

Truly anonymous data may fall outside the scope of the GDPR. Reaching that conclusion requires analysis of the context and the means reasonably likely to be used for re-identification.

4. Quality: define “good enough” for each decision

Governance does not seek perfection. It defines proportionate thresholds.

Data may be complete yet wrong, accurate yet too old, or consistent yet unauthorised. The main dimensions are accuracy, completeness, uniqueness, consistency, validity, freshness and traceability.

For each data product, document the rule, threshold, measurement method, frequency, owner and response. For example: 100% of transfers have a verified beneficiary; fewer than 0.5% of active customer records lack a currency; the inventory table arrives in less than twenty minutes.

Controls are placed at several levels.

Preventive. Required fields, reference lists, format constraints, controlled choices and business validation.

Detective controls. Reconciliation, duplicate detection, drift, distributions, freshness and sampling.

Corrective controls. Quarantine, return to the producer, reprocessing, recalculation and notification to consumers.

Correction must address the root cause. An analyst who repairs the same file every month is masking a process defect.

5. Traceability: four chains that must not be confused

Technical lineage maps tables, fields and transformations. It answers: “Where does this figure come from?”

Business lineage connects definitions, ownership and decisions. It answers: “What does this figure mean?”

Legal lineage links purpose, lawful basis, categories, recipients and retention. It answers: “Why may we process this data?”

Operational lineage records versions, access, incidents and actions. It answers: “Who did what, and when?”

Mature governance links these four views through common identifiers. The DPO need not read all the SQL, and the engineer need not interpret the lawful basis alone. Everyone can navigate to the evidence relevant to their role.

The access log is protected against tampering and itself subject to restricted access. It does not record sensitive content unnecessarily. Administrative access and bulk exports receive particular scrutiny.

6. GDPR: translate principles into controls

Lawfulness, fairness and transparency. The purpose and lawful basis are documented, privacy information is accessible and processing does not surprise the data subject.

Purpose limitation. A new use requires a compatibility assessment or a new lawful basis. A data lake does not confer a general right to reuse data.

Data minimisation. Schemas, forms and exports exclude unnecessary fields. Development datasets are minimised.

Accuracy. Sources of truth, corrections and quality indicators are defined.

Retention limitation. Each category has an automated trigger and procedure, with exceptions handled explicitly.

Integrity and confidentiality. Classification, least privilege, encryption, backups, testing, monitoring and incident management all apply.

Responsibility. The organisation retains evidence of decisions, assessments, contracts, tests and performance.

A data protection impact assessment is conducted when processing is likely to create a high risk to rights and freedoms. It begins early enough to influence the architecture.

7. Data Act: what changes in data strategy

The EU Data Act has applied since 12 September 2025. It complements the Data Governance Act, which has applied since September 2023.

The legislation covers access to data generated by connected products, certain sharing obligations, unfair contractual terms and switching between data-processing services. An industrial business should no longer assume that machine-generated data is inaccessible simply because it resides with the manufacturer.

The Commission explains that users of connected products can access, use and share the raw data they co-generate under the Regulation. IoT contracts and architecture must therefore identify what can be exported, in which format and at what frequency.

For cloud and edge services, the Data Act requires measures that facilitate switching. The Commission cites open interfaces and, for certain services, at least an export in a commonly used, machine-readable format. It states that switching charges, including certain data-egress charges, must be removed from 12 January 2027 after a transitional period.

Governance must integrate these rights and obligations without conflating them with the GDPR. Industrial data may contain personal data, and contractual rights of access do not remove protections for individuals.

8. Security: govern critical databases and service providers

The CNIL notes that personal data breaches often involve service providers. The company must therefore map the entire chain: collection, API, ETL, warehouse, backup, BI, AI, support and export.

Every link in the chain applies least privilege. Service accounts have a defined purpose, restricted permissions and rotating secrets. Temporary access expires, and bulk exports trigger an alert.

Large databases are segmented. Compromising a marketing tool must not expose the entire repository. Sensitive data is separated and encrypted, with independent key management.

Breach response includes detection, assessment, containment, preservation of evidence, risk analysis, notification and communication. The applicable regulatory deadline must be known before an incident occurs.

An annual exercise simulates a breach involving a processor. The team checks the list of affected data subjects, the data involved, contact details and the ability to revoke access. The contract then becomes testable in practice.

9. Operating model: federate without diluting accountability

The Chief Data Officer or data lead defines the framework, standards and platform. The DPO advises on and monitors GDPR implementation within the role defined by law. The CISO owns security policy. Domain owners decide definitions and uses. Data stewards maintain quality and metadata. Technical teams implement the controls.

A governance council resolves cross-cutting issues such as the customer definition, sensitive sharing, a new purpose, a retention exception or a critical service provider. It does not approve every column.

A federated model gives business domains clear ownership within common standards. Finance owns margin definitions; Sales owns the definition of a qualified lead. The platform provides the catalogue, lineage, access controls and quality tooling.

Decisions are dated. Every exception has an owner, justification, compensating controls and a deadline. Without an end date, an exception silently becomes the norm.

10. Governance dashboard

The dashboard tracks outcomes, not merely the documents produced.

  • share of processing activities and data products with an owner;
  • systems linked to the register and catalogue;
  • data lacking classification or retention rules;
  • quality-rule compliance by criticality;
  • incidents and time to detection and correction;
  • data-subject requests processed and propagation failures;
  • inactive accounts, privileged access and bulk exports;
  • providers without recent review;
  • deletions completed, failed or pending;
  • successful restoration and reversibility tests.

A 100% coverage rate can be misleading if the records are out of date. Freshness and the availability of supporting evidence must also be measured.

11. Case study: reconciling CRM, marketing and billing

A company has 180,000 contacts in its CRM, 240,000 in its email platform and 95,000 billing accounts. Nobody knows how many active customers have consented to communications.

The project starts with identifiers and purposes, not a wholesale merger. The contractual account becomes the system of record for customer status. The CRM maintains the commercial relationship. The email platform receives only a pseudonymous ID, the required address, an authorised segment and communication status.

Reconciliation reveals 31,000 probable duplicates, 18,000 addresses without usable provenance and 7,000 former customers still included in marketing audiences. These figures belong to this fictitious case, but the exercise illustrates the method.

The team does not automatically delete every record. It classifies them: contractual data to retain, marketing records to suppress, duplicates to merge with an audit trail, and records requiring review. A daily pipeline propagates withdrawals and corrections. An alert flags any contact selected for delivery without a compatible status.

The benefits are not limited to risk reduction. Deliverability metrics and cohort analysis become more reliable. In this case, compliance improves management decisions.

12. A hundred-and-twenty-day roadmap

Days 1 to 30 — Visibility. Identify ten critical processing activities and data products, along with their owners, systems, providers and retention periods. Map one complete data path.

Days 31 to 60 — Controls. Define classification, access controls, quality rules, data-subject rights procedures, retention and incident response. Remediate the highest-risk gaps.

Days 61 to 90 — Automation. Link the register and catalogue, instrument lineage, propagate corrections, automate deletion and track failures.

Days 91 to 120 — Evidence. Test backup restoration, a data-subject rights request, a breach involving a processor and an exit-data export. Present the dashboard to the governance council.

Prioritisation is based on the people affected, sensitivity, volume, autonomy and dependency. Trying to govern “all data” at once often produces documentation without remediation.

13. Frequently asked questions

13.1. Are data governance and GDPR the same thing?

No. The GDPR governs personal data. Data governance also covers financial, industrial, product and reference data, including quality, definitions, access and value. The two disciplines must be connected.

13.2. Do you need a catalogue tool?

A catalogue helps as sources and teams multiply. Start with critical data objects and clear ownership. A catalogue without definitions or links to pipelines soon becomes an obsolete directory.

13.3. Who is responsible for quality?

The business owner defines the required quality level. The producer corrects root causes. The data team measures and alerts. Consumers report discrepancies. Responsibility is distributed, but it must never be anonymous.

13.4. Is pseudonymisation enough to fall outside the GDPR?

No. If re-identification remains possible using separately held information, the data remains personal. Pseudonymisation is a valuable security measure, not automatic anonymisation.

13.5. How can you tell what to delete?

Connect each category to a purpose, obligation and triggering event. Define exceptions, backup handling and evidence. A single retention period is rarely suitable for an entire database.

14. What an end-to-end review can verify once purpose, lawful basis and retention are operationalised

A document-only register becomes governance when it corresponds to the real systems. For one sample processing activity, the team must link purpose, lawful basis, categories, collection, transformations, recipients, access, retention, deletion and the exercise of rights.

Verification uses a concrete case. The review traces one person from the form through the CRM, warehouse, exports and backups, then triggers a correction and observes its propagation. Legitimate copies, technical delays and exceptions are explained; forgotten copies are added to a deletion plan.

A robust close-out requires the business owner to confirm the need, the responsible DPO or legal counsel to validate the applicable reasoning, engineering to provide evidence of access and erasure, and the data steward to reconcile definitions. Every residual gap must have an assessed risk, an owner and a deadline. Without this end-to-end verification, the same data may appear consistent in the register, remain wrong in reporting and still be available in an export nobody had identified.

Retention is then translated into an enforceable, monitored rule. A monthly dashboard shows volumes due, successful deletions, errors, exceptions and maximum age. Compliance becomes observable without suggesting that an indicator can replace legal analysis.

15. Logiks recommendations

First trace a real record from end to end. Connect the legal register to the technical catalogue, then give each data product an owner, retention period, quality rules and access evidence. Automate corrections and deletion as production processes. Effective governance makes good practice easier than bypassing controls.

16. Main sources