How to operationalize data trust

The five pillars for AI readiness, governance, and GDPR/NIS2 compliance in Sweden and Finland

Find → Classify → Protect → Govern → Facilitate 

In our previous blog, we made Data Trust accessible to leaders by asking four hard questions: 

Do we know what data we have, who owns it, what to protect, and whether we do this consistently across the organization? 

If any answer was “not sure,” the point was not to assign blame — it was to create clarity, accountability, and ownership. This post is the practical continuation: a concrete Data Trust operating model that leaders can sponsor and oversee, and that teams can run, so Data Trust becomes repeatable and sustainable rather than purely aspirational. 

Data Trust needs an operating model — not five disconnected projects 

Epical defines Data Trust as confidence in the integrity, security, and ethical use of data. It extends beyond compliance checklists or encryption into the culture and infrastructure required to treat data as a secure asset. That framing is consistent across your internal blog drafts and related five-pillar material. 

Building that capability requires a structured approach. Your internal material repeatedly groups the work into discovery and classification, protection and governance, compliance and risk management, and change enablement. GDPR Article 5 also reinforces the need for purpose limitation, accuracy, storage limitation, integrity and confidentiality, and accountability, all of which depend on repeatable operational practices rather than one-off projects. 

This structure can be expressed as five connected pillars: 

• Find: create visibility into what data exists and where it lives. 
• Classify: attach meaning and handling rules so downstream controls scale. 
• Protect: apply controls proportionate to risk and intended use. 
• Govern: define decision rights and lifecycle practices that remain auditable over time. 
• Facilitate: enable adoption so people follow the model in real work, not just in policy. 

Pillar 1 — Find: make the data estate visible 

What it is: A systematic way to discover, inventory, and understand data across repositories, platforms, and domains. This aligns directly with your internal five-pillar draft, which emphasizes discovery campaigns, active cataloging, and visibility into the data estate. 

Why leaders should care: Trust cannot be built on assumptions. If you cannot see what data you have, you cannot apply consistent protection, lifecycle management, or responsible use. This is also consistent with official AI/data-protection guidance from Finland’s AI systems and data protection, which emphasizes assessing risks, processing data securely, and demonstrating compliance. 

What “good” looks like 

• A living data inventory that supports decisions, not a one-time snapshot. 
• Visibility into what data exists, where it resides, and what needs further action. 

Practical moves 

• Start with what matters most: prioritize repositories feeding customer experience, financial reporting, core operations, or AI initiatives. 
• Design for verifiability as well as visibility: can you show what changed and when? 
• Use logging or traceability as supporting evidence when you need to validate changes across the data estate. This is an editorial operational recommendation aligned with the blog’s practical intent. 

Outputs you should expect 

• Inventory coverage, plus a prioritized backlog showing what should be classified next based on value, risk, or exposure. 

Pillar 2 — Classify: attach meaning for consistent handling Pillar 1 — Find: make the data estate visible 

What it is: Classification turns “data” into data with rules by attaching sensitivity, purpose, and lifecycle so the organization can scale consistent decisions. Your internal five-pillar material explicitly states that classification should encode sensitivity, purpose, and lifecycle and then inform downstream access, retention, and protection decisions. 

Why leaders should care: Without shared meaning, protection and lifecycle decisions become inconsistent, exceptions multiply, and Data Trust depends on tribal knowledge instead of repeatable practice. That is fully aligned with the internal drafts and with GDPR’s principles around purpose limitation, data minimisation, accuracy, and accountability. 

What “good” looks like 

• A small, usable classification model that people can apply without constant debate. 
• Clear accountability for decisions and exceptions, aligned with transparency and accountability. 

Practical moves 

Keep classification decision-driven: 

• Sensitivity — the impact if the data is exposed. 
• Purpose — why the data exists and what acceptable use looks like. 
• Lifecycle — how long the data should exist and what happens next. 

Automate where appropriate, but validate with owners so classification decisions remain defensible. 

Outputs you should expect 

• A classification framework that directly informs access, retention, and protection decisions. 

Pillar 3 — Protect: apply controls proportional to risk 

What it is: Protection operationalizes classification by applying access control, encryption, anonymization or masking, monitoring, and auditability aligned to risk and intended use. This wording is directly consistent with your internal source material. 

Why leaders should care: Data Trust goes beyond encryption. Responsible handling is needed to safeguard privacy, security, and ethical use, and to reduce weak-trust foundations that can undermine analytics and AI initiatives. This is consistent with your internal content and with Finland’s AI systems and data protection, which explicitly says personal data must be processed securely and that organizations must demonstrate compliance. 

What “good” looks like 

• Sensitive data is protected through repeatable patterns rather than ad hoc decisions. 
• Protection decisions can be traced back to risk and intended use. 

Practical moves 

Tie controls to classification: 

• least privilege and strong authentication for sensitive classes, 
• encryption and anonymization or masking where appropriate, 
• and evidence capture that supports audit and incident response. NIS2 requires appropriate cybersecurity risk-management measures and reporting obligations, which supports a structured protection baseline. 

Outputs you should expect 

• A prioritized protection baseline: what is protected, how it is protected, and what evidence supports audit and incident response. 

Pillar 4 — Govern: make decision rights and lifecycle auditable — and durable 

What it is: Governance defines who can decide what about data, how access is granted and reviewed, and how lifecycle rules are enforced over time. A practical definition is that data governance establishes roles, responsibilities, and processes so there is accountability and authority over how data is managed and used across the enterprise. This is strongly aligned with the wording already present in your draft. 

Why leaders should care: When decision rights are unclear, organizations either slow down through friction and indecision or speed up unsafely through unmanaged access, unmanaged retention, and unmanaged risk. GDPR’s accountability and storage-limitation principles, along with NIS2 governance obligations, directly support the importance of auditable decision-making and lifecycle control. 

What “good” looks like 

• Named owners per domain or data product with visible decision rights. 
• Auditable lifecycle and access decisions that persist over time. 

Practical moves 

Build a minimal governance backbone that scales: 

• ownership and decision rights,
• access approvals and periodic access reviews, 
• lifecycle rules linked to classification, such as retain, archive, or dispose. 

Outputs you should expect 

• Governance routines that persist after the initial push, because Data Trust must be continuous rather than episodic. 

Pillar 5 — Facilitate: make adoption the default 

What it is: Change enablement — training, guidance, and practical support so people can follow the model without unnecessary friction. Your internal draft explicitly identifies change enablement as a core part of Data Trust. 

Why leaders should care: If governance is hard to follow, people bypass it and trust erodes quietly. The The Nordic AI trust model emphasizes that trust is built on transparency, accountability, and competence, and that competence must be embedded in daily operations. That supports the message that culture and infrastructure must work together. 

What “good” looks like 

• Role-based guidance that is short, practical, and embedded in day-to-day work. 
• A feedback loop that removes friction and reinforces adoption. 

Practical moves 

• Translate policy into “what I do differently tomorrow” for each role. 
• Run clinics and onboarding for owners and key teams so Data Trust becomes a habit rather than a reminder. 

Outputs you should expect 

• Adoption assets such as guides and training, plus a support model that keeps the operating model alive.