Better start to enforce GDPR2 before final NIS2 certification

The DPO entered the boardroom with a simple warning: “Our NIS2 programme cannot become another storm checklist while the organisation has skipped the basics in the swimming pool.” Around the table, the directors expected controls, incident plans, supplier registers and reporting timelines, but the DPO pointed instead to the company’s data assets: the customer records, employee files, access logs, telemetry, contracts, identities, backups, AI datasets and forgotten archives that quietly carried the organisation’s real risk.

“If we reinvent the DPIA,” she said, “not as a privacy form but as a living compass for every critical data asset, we will finally learn where the currents are strongest: which data keeps the business alive, which systems create dependency, which suppliers extend our exposure, which incidents would harm people, and which decisions require board-level risk acceptance.” In that moment, DPIA became more than GDPR compliance; it became the first swimming lesson for NIS2. By understanding why data is processed, where it flows, who depends on it, how it can fail, and what harm follows, the company could bring balance to governance, risk management, supply chain security, incident response, business continuity, access control, monitoring, resilience and accountability. The stormy sea would not disappear, but the board finally understood that NIS2 resilience starts before the wave hits: in the disciplined ability to know the organisation’s data assets, protect them proportionately, and steer with confidence when the water rises.

When GDPR arrived, many companies treated it like a legal thunderstorm that could be survived with a binder, a privacy notice and a DPIA template. The first years were filled with nervous workshops, consent pop-ups, processing registers and consultants explaining that “accountability” meant being able to show something when the regulator knocked. And so, in many boardrooms, the DPIA became a trophy document: “If we can compose one, we must be compliant.” But ten years ago the digital sea was still deceptively calm. Cloud adoption was young, SharePoint was often just “the shared folder with better branding,” and for many executives the Google algorithm was the closest thing to artificial intelligence. Data protection by design was discussed, consent was repeated like a spell, anonymisation was treated as a magic cloak, and retention policies were written with the quiet hope that nobody would ever ask what was actually stored in the archive.

Now the same companies are strapped into a digital rollercoaster. AI is no longer a distant algorithm behind a search bar; it is crawling through weakly protected SharePoint environments, summarising forgotten HR files, connecting old sales exports with customer complaints, and turning abandoned data into operational decisions. The board asks, “Can we reuse this old privacy data for innovation?” and the DPO answers, “Only if you can prove the past gave permission to the future.” Legal boundaries blur where legacy consent, purpose limitation and new AI ambitions collide. What was once archived “just in case” has become fuel for models, dashboards and automated insight. The forgotten data lake has become a mirror, and not every reflection is lawful.

At the same time, NIS2 changes the pressure. Larger customers no longer ask politely whether suppliers “take GDPR seriously”; they demand contractual statements that personal data is handled exactly as the regulation requires. Suddenly, privacy is not only a compliance issue but a supply-chain passport. No statement, no trust. No evidence, no contract. No DPIA, no credible resilience story. The wicked lesson is this: companies that learned to write DPIAs but never learned to govern data assets are now being asked to swim in a stormy sea after skipping the basic lessons in the swimming pool. The new DPIA must therefore stop being a document of defence and become a navigation instrument: showing which data exists, why it exists, who touches it, which AI systems can reach it, which suppliers depend on it, which risks travel with it, and which board decisions are needed before the next wave hits.

And perhaps the DPO’s sharpest quote to the board is this: “GDPR taught us to ask whether we may process personal data. NIS2 now asks whether we can survive the consequences of how badly we protected it.”

A DPIA exercise should no longer be a compliance document written after the decision is already made. It must be a living risk exercise around the company’s data assets: what data exists, why it is processed, where it flows, who can access it, how long it is kept, which systems or suppliers depend on it, and what harm could occur if the data is misused, exposed, changed, combined or reused. The GDPR baseline is still clear: a DPIA describes the processing, tests necessity and proportionality, assesses risks to people’s rights and freedoms, and defines measures to address those risks and demonstrate compliance.

The renewed DPIA should therefore become the bridge between privacy, cybersecurity and NIS2 resilience. It should not only ask, “Are we allowed to process this data?” but also, “Can we still protect this data in a digital storm?” The exercise must be started before processing begins, updated during the lifecycle, and reviewed when risks change; the guideline explicitly calls DPIA an ongoing process, not a one-time exercise.

The new-era challenges to review are sharper than they were ten years ago: AI searching through weak SharePoint environments, old datasets being reused for new analytics or AI purposes, unclear consent histories, over-retention, failed anonymisation, employee monitoring, automated decision-making, supplier access, cloud dependency, cross-border transfers, and NIS2 customers demanding contractual proof that GDPR data is handled properly. These challenges require the DPIA to look beyond legal text and into real operational exposure: access rights, identity management, logging, data lineage, supplier controls, breach impact, resilience, and board-level risk acceptance.

In short: the modern DPIA must become the organisation’s data protection stress test. It identifies where personal data creates business dependency, human impact and regulatory exposure; it connects GDPR accountability with NIS2 governance; and it forces the company to prove that privacy-by-design is not a sentence in a policy, but a working capability in every system, supplier relationship and AI-driven process.

Updated insight: DPIA after almost 10 years of GDPR enforcement

The core legal DPIA standard has not radically changed: the WP29 DPIA guideline uploaded here remains the baseline and was later endorsed by the EDPB. It defines a DPIA as a process to describe processing, assess necessity and proportionality, assess risks to individuals, and define measures to address those risks; it also warns that incorrect or missing DPIAs can lead to fines up to €10 million or 2% of worldwide annual turnover. The EDPB still lists the WP29 DPIA guideline among the GDPR guidelines it endorsed on 25 May 2018.

What has changed is the risk environment. DPIAs now need to address AI, large-scale analytics, employee monitoring, biometric identification, cross-border transfers, cloud concentration, cyber resilience, data sharing ecosystems, and re-use of legacy datasets for new purposes. The EDPB Strategy 2024–2027 explicitly says the Board will continue addressing new technologies such as AI and cooperate with other regulators globally. In 2024 the EDPB also adopted an opinion on AI models, and its AI topic page shows ongoing 2025–2026 work around AI, health data, clinical trials, and digital regulatory simplification.

Actions a company should take for a DPIA

A company should treat the DPIA as a risk governance process, not a form. The minimum action set is:

1. Screen whether the processing is likely high risk. Mandatory triggers include systematic profiling with significant effects, large-scale special-category or criminal-offence data, and large-scale systematic monitoring of public areas. The WP29/EDPB criteria also include scoring, automated decisions, systematic monitoring, sensitive data, large scale processing, combining datasets, vulnerable persons, innovative technology, and processing that prevents access to a right, service or contract.
2. Conduct the DPIA before processing starts. It should be integrated into design, development, change management, procurement, AI governance, security review, and operational risk processes. The guideline stresses that DPIA is a continual process, not a one-time exercise.
3. Describe the processing completely. Include purposes, legal basis, data categories, data subjects, recipients, retention, systems, processors, transfers, assets, and operational context. Annex 2 of the guideline says an acceptable DPIA must describe the processing, including nature, scope, context, purposes, data, recipients, retention, functional description, and assets.
4. Assess necessity and proportionality. This means validating purpose limitation, lawfulness, data minimisation, storage limitation, transparency, rights handling, processor arrangements, and transfer safeguards. This is now especially important where organisations re-use historical personal data for AI training, profiling, fraud detection, marketing, or employee analytics.
5. Assess risks from the data subject’s perspective. The DPIA is not just an information-security risk assessment. It must consider risks to rights and freedoms: privacy, data protection, non-discrimination, freedom of movement, freedom of thought, liberty, and other fundamental rights.
6. Define measures and residual risk. Controls should include minimisation, purpose separation, pseudonymisation, encryption, access control, logging, retention enforcement, human review, explainability, bias testing, vendor due diligence, transfer impact measures, incident response, and rights procedures. But the guideline warns that pseudonymisation and encryption are examples only; appropriateness depends on context and risk.
7. Involve the right parties. The controller remains accountable, but the DPO must be consulted where appointed, processors should assist, and data subjects or representatives should be consulted where appropriate.
8. Consult the supervisory authority if residual risk remains high. If the organisation cannot reduce risks to an acceptable level, prior consultation is required. The guideline gives examples of unacceptable residual risks such as irreversible harm, job loss, financial jeopardy, life-threatening data exposure, obvious likelihood of occurrence, or known unpatched vulnerabilities.
9. Document decisions and review regularly. The guideline recommends periodic review, especially when the risk changes, and requires retaining and updating the DPIA.

Risks of weak data protection

Weak data protection should be expressed as risks to individuals, the organisation, and society.

Risk area	Weakness	Consequence
Lawfulness risk	No valid legal basis, poor legitimate interest balancing, weak consent, or unlawful re-use	Processing becomes unlawful; orders to stop processing; deletion of datasets
Transparency risk	Individuals do not understand how data is used	Loss of trust, complaints, inability to demonstrate fairness
Discrimination risk	Profiling, AI, scoring, or automated decisions produce biased outcomes	Exclusion from jobs, credit, insurance, services, or public benefits
Surveillance risk	Excessive monitoring of employees, customers, citizens, or public spaces	Chilling effects, power imbalance, labour-law and human-rights concerns
Security risk	Poor access control, weak encryption, unpatched systems, uncontrolled vendors	Breaches, identity theft, fraud, extortion, safety risks
Data quality risk	Outdated, inaccurate, or contextually wrong data	Wrong decisions, denial of rights, reputational harm
Purpose creep risk	Data collected for one purpose is reused for analytics, AI, marketing, or investigation	Breach of purpose limitation and reasonable expectations
Retention risk	Data kept too long or ungoverned legacy archives	Increased breach impact and inability to comply with erasure
Vendor/cloud risk	Processors or sub-processors are not controlled	Loss of accountability, transfer risk, systemic dependency
Governance risk	DPIA treated as a checkbox	No evidence of accountability, weak board oversight, poor risk acceptance

Challenges after almost 10 years of GDPR

The biggest lesson is that GDPR compliance has matured on paper but remains difficult in practice.

First, data ecosystems are more complex than the original project model assumed. Many organisations no longer process data in one system for one purpose. They use cloud platforms, SaaS chains, APIs, data lakes, AI models, analytics tools, marketing pixels, identity providers, and outsourced support. A DPIA now has to map data flows across an ecosystem, not only inside one application.

Second, AI and automated decision-making have raised the DPIA threshold. The old DPIA triggers already covered profiling, systematic evaluation, large-scale sensitive data, innovative technology, and decisions with significant effects. Those triggers now apply to many AI use cases: recruitment screening, behavioural scoring, fraud detection, productivity monitoring, customer segmentation, biometric access, and generative AI knowledge bases.

Third, legacy data is being re-used for new purposes. After years of GDPR, companies still have data collected under old notices, unclear retention rules, and historic consent models. Re-using such data for AI, cross-selling, risk scoring, or monitoring creates purpose-limitation, transparency, fairness, and data-quality risks.

Fourth, DPIAs are often performed too late. The guideline says the DPIA should start as early as practicable and be updated throughout the lifecycle. In practice, privacy review is still frequently added after procurement, after design, or just before go-live.

Fifth, organisations confuse security risk with data protection risk. Encryption, access control, and logging are necessary, but a DPIA must also assess necessity, proportionality, fairness, rights, discrimination, autonomy, and human impact.

Sixth, DPIAs are rarely public. The guideline states that publishing a DPIA is not legally required, although publishing a summary can foster trust, especially where the public is affected. This explains why many DPIAs remain invisible unless a regulator, journalist, court case, or public-sector transparency process brings them forward.

Why only a few fine examples reach the press

GDPR enforcement is substantial, but press attention is selective. DLA Piper reported about €1.2 billion in GDPR fines across Europe in 2024, and later reporting on the 2025 survey again described around €1.2 billion in fines with rising breach notifications. CMS also notes that GDPR enforcement intensified after an initial orientation phase, with total fines surpassing €4 billion by the 2024/2025 reporting period.

Only a few cases become media examples because they usually involve at least one of these factors: very large fines, Big Tech, children, biometric data, AI, illegal scraping, mass surveillance, international transfers, or a dramatic breach. The Clearview AI case, for example, attracted press because it involved facial recognition, scraped images, biometric identifiers, multiple regulators, and a Dutch fine of €30.5 million. The Meta international-transfer fine became headline news because it was record-breaking and affected the legality of large-scale EU–US data transfers.

By contrast, most DPIA failures are not newsworthy on their own. They are often buried inside broader findings such as lack of lawful basis, poor transparency, excessive retention, inadequate security, unlawful employee monitoring, or failure to respect data-subject rights. Many supervisory decisions are technical, local, published only in national languages, anonymised, delayed, settled without dramatic facts, or focused on corrective orders rather than large fines. The EDPB also publishes a register of final cross-border decisions under the One-Stop-Shop mechanism, but that does not mean every decision becomes a public press story.

Practical conclusion

A modern DPIA should be positioned as a decision file for accountable processing. It should answer five board-level questions:

1. Are we allowed to process this personal data for this purpose?
2. Is the processing necessary and proportionate?
3. Who can be harmed, how severely, and how likely is it?
4. Which controls reduce the risk, and what residual risk remains?
5. Who accepted that residual risk, and when will it be reviewed?

The updated insight is clear: after almost 10 years of GDPR, the problem is no longer lack of DPIA guidance. The problem is operationalisation. Companies need DPIAs that are embedded in change management, procurement, AI governance, cybersecurity, vendor management, and board risk acceptance.

Summarizing conclusion for the GDPR 2.0 roadmap

HarmonyQ.eu adds a new inspiration to the GDPR debate by moving the DPIA from a historic compliance exercise into a Zero Trust Data Protection assessment for 2030. The original DPIA was meant to describe processing, assess necessity and proportionality, assess risks to people’s rights and freedoms, and define safeguards that demonstrate compliance. But in the new era, that is no longer enough. AI, cloud, SharePoint sprawl, supplier dependency, old consent records, unclear retention, and NIS2 pressure have turned data protection into an operational resilience question. The DPIA must therefore become a stress test of the company’s data assets, not only asking “may we process this?” but also “can we still control, explain, protect, recover and justify this data use in 2030?”

The HarmonyQ.eu Zero Trust ZT GDPR Assessment can position itself as that next step: a structured pathway that brings GDPR, NIS2, AI governance and data asset management into one balanced view. This fits the GDPR guidance, which already allows organisations to choose a methodology suited to their context, provided it remains a genuine risk assessment and is reviewed when risks change. It also answers the AI governance challenge: modern AI increases speed, opacity, dependency on data quality and accountability complexity, meaning governance must move from simple approval to guardrails, traceability and stewardship.

In the ZT9 HarmonyQ.eu assessment, the organisation is reviewed across nine Zero Trust layers that together form a vertical data protection and resilience stack:

1. Governance & Board Accountability — who owns the data risk, who accepts residual risk, and how GDPR/NIS2 decisions are escalated.
2. Data Asset Discovery & Classification — what personal data exists, where it lives, how critical it is, and whether old archives are still lawful.
3. Identity & Access Control — who can reach data, whether access is role-based, and whether AI tools inherit excessive privileges.
4. Purpose, Consent & Legal Basis Control — whether the original reason for processing still supports today’s reuse, analytics or AI ambitions.
5. Processing & Data Flow Transparency — where data moves across systems, cloud platforms, suppliers, APIs and reporting chains.
6. Security, Monitoring & Detection — whether weak environments, logging gaps, privilege leakage and unauthorised access can be detected.
7. AI, Automation & Decision Integrity — whether AI outputs are explainable, validated, bias-tested, traceable and protected by human override.
8. Supplier, Cloud & Contract Assurance — whether processors and NIS2 supply-chain partners can prove GDPR-grade handling of personal data.
9. Continuity, Retention & Recovery — whether data is retained lawfully, deleted when needed, restored securely and protected during incidents.

The conclusion is simple: the DPIA of 2030 is no longer a form; it is the board’s map of trust in data. HarmonyQ.eu’s ZT9 approach turns data protection into a living Zero Trust assessment where privacy, cybersecurity, AI control, supplier assurance and resilience finally meet. It helps companies stop pretending they can swim in a stormy NIS2 sea while still ignoring the swimming pool basics. It teaches them to see every data asset as a risk carrier, every AI tool as a potential amplifier, every supplier as an extension of accountability, and every board decision as part of the trust architecture of the company.