Skip to content

Governed Data Sharing for Multi-Agency Public Services

Finworks' Approach to Sharing Data Lawfully Across Organisations 

Across the public sector, the hardest part of sharing data is rarely connecting the systems. It is establishing the permission to share in the first place, lawfully, between organisations that do not share an owner, a system, or a liability. A case known to several agencies, a fraud spanning departments, a service delivered with an external provider: the information exists, but it cannot cross the boundary in time.

The barrier is permission and meaning, not plumbing. When the lawful basis is unclear, the safe default becomes "don't share", and that default carries a cost of its own whenever a fuller picture would have changed a decision. This page sets out how public bodies can share what they must, withhold what they shouldn't, and prove it, across departments and with the third-party providers who deliver alongside them.

 

Section 1:

Why Cross-Organisation Data Sharing Stalls

Ask a public-sector team why they can't share data with another department or a delivery partner, and the answer is rarely technical. It is "we're not sure we're allowed to", or "legal hasn't signed the agreement", or "their data doesn't match ours". The obstacles are permission and meaning, and they show up as a recognisable set of patterns. 

 

The Four Patterns

The pattern

Why it stops the share

 "Are we even allowed to share this?" 

The lawful basis for a specific disclosure is unclear, so teams hesitate, or share informally and hope. The safe default becomes "don't share", even when a fuller picture would change the decision. 

 

Agreements that are paperwork, not infrastructure 

The data-sharing agreement sits in a drawer, disconnected from the systems that actually move the data. What was agreed and what happens day to day drift apart, and no one can easily show they match. 

The same field means different things 

Two organisations exchange data, but their identifiers, definitions and formats don't line up. The "same" field means something different on each side, so sharing produces confusion rather than clarity.  

No defensible record of authority 

When sharing runs on email and ad-hoc requests, there is no reliable trail of what was shared, with whom, on what basis, and under which agreement. Every audit, FOI request or challenge becomes an exercise in reconstruction. 

This is the layer beneath governed casework. In our recent Expert Insight, Governance-First Case Management for Complex Public-Sector Workflows,  we looked at what it takes for partner organisations to work a shared case while each sees only what their role permits. This page goes underneath that promise, to how the permission to share is established in the first place.

 

 Two boundaries, one problem 

 Permission breaks down at two distinct boundaries in the public sector. In both cases the question is the same: can we share what we must, withhold what we shouldn't, and prove it? 


 Department to department (multi-agency) 

 Department to third-party provider 

A child known to social services, a school, the police and the NHS. A fraud spanning three agencies. A vulnerable adult whose risk is only visible when several bodies' records are combined. Multi-agency work fails when no single organisation owns the whole picture, and no one is confident they are permitted to assemble it. Each body holds a fragment, governed by its own basis and its own reading of the rules, so decisions get made on partial information. 

Public services are increasingly delivered with external providers: outsourced processing, specialist analytics, managed services, delivery partners. Each relationship means data crossing from a public body to a private organisation, under a contract and a lawful basis that must be precise about what the provider may see, for what purpose, for how long, and with what obligation to delete. Here the data leaves the organisation's direct control, so proving the permission held is everything. 

 

Section 2:

From Agreement to Enforcement: Sharing Data the Governed Way

 Ask a public-sector team why they can't share data with another department or a delivery partner, and the answer is rarely technical. It is "we're not sure we're allowed to", or "legal hasn't signed the agreement", or "their data doesn't match ours". The obstacles are permission and meaning, and they show up as a recognisable set of patterns. 

 1. Establish the lawful basis 

Every disclosure should be tied to a clear, stated lawful basis and purpose before any data moves. Making the basis explicit is what turns "we're not sure we're allowed to" into a confident, defensible share, whether the recipient is another department or a third-party provider. 

 

 2. Turn the agreement into enforced rules 

 

  •  Translate each agreement, its purpose, lawful basis, scope and retention, into enforced rules. What may be shared, with whom, and for what purpose is governed by configuration, not memory or goodwill. 
  •  Each disclosure is bound to its stated basis. Data outside that purpose simply isn't exposed, to a partner department or a third-party provider. 
  •  Because the platform is low-code, the teams who own these relationships update sharing rules as agreements change, without waiting on a development cycle and without losing governance. 

 3. Reconcile what the data means  

Map differing identifiers, definitions and schemas, so shared data means the same thing to everyone who receives it. Reconciled meaning is what turns an exchange of files into shared understanding.   

 4. Record every disclosure 

Capture what was shared, with whom, when, under which agreement and on what basis. Any disclosure can then be evidenced end to end, for audit, FOI or challenge, and the trust that future sharing depends on compounds rather than erodes. 

For the security of shared data, encryption, anonymisation and pseudonymisation, and the Five Safes, discover our complete guide: How to Protect Government Data Across Case Management Systems

What's the Difference Between Data Security and Data Privacy?  

Data privacy and data security are related but have differences in their focus and scope: 

 

Data Privacy 

Focus:

Data privacy primarily concerns the protection of individuals' personal information and their right to control how their data is collected, used, and shared. It revolves around respecting the privacy of data subjects.

Rights and Consent:

Data privacy emphasises obtaining consent from individuals before collecting their data. It also allows individuals to access their data, correct inaccuracies, and request its deletion.

Compliance:

Data privacy regulations define specific requirements for handling personal data. Compliance involves respecting these legal frameworks and ensuring that individuals' data rights are upheld.

Examples:

Data privacy concerns practices like obtaining explicit consent for marketing emails, allowing users to review and delete their online profiles, and providing data collection and usage transparency.

Data Security 

Focus:

Data security is primarily concerned with protecting data from unauthorised access, breaches, or leaks, regardless of whether the data is personal or not. It encompasses broader aspects of safeguarding data from various threats. 

Protection Measures:

Data security involves implementing various technical and organisational measures that ensure data confidentiality, integrity, and availability. This includes encryption, access controls, firewalls, and intrusion detection systems.

Risk Management:

Data security identifies potential vulnerabilities and threats, assesses risks, and implements mitigation strategies to reduce and prevent the impact of security incidents.

Examples:

Data security practices include securing databases with strong passwords, encrypting sensitive files, conducting regular security audits, and training employees on security best practices.

Section 3:

How Finworks Supports Governed Data Sharing

This is not theoretical ground for Finworks. For over 20 years we have run mission-critical systems for central government, including a UK Home Office platform that manages 1.2 million documents, creates 22,000 documents and 100,000 transactions a month, and keeps a detailed audit trail on every action, accredited to OFFICIAL SENSITIVE and delivered on G-Cloud. 

Agreement, Encoded

We translate data-sharing agreements into enforced rules inside the platform, so purpose, lawful basis, scope and retention govern every disclosure by configuration rather than by memory. 

Boundary Control

Role- and purpose-based access means each department or provider sees only what it is entitled to, for the purpose agreed, and nothing beyond it. 

Meaning, Reconciled

We map identifiers, definitions and schemas across organisations, so shared data means the same thing to everyone who receives it.

Proof, Built In

Every disclosure is recorded end to end, what was shared, with whom, when, and under which authority, so sharing stands up to audit, FOI and challenge. 

Proven in Pressure

Finworks is ISO 27001, ISO 9001 and Cyber Essentials Plus certified, and a G-Cloud 14 supplier. Our software, and our team, have been proven in situations of intense commercial and political pressure. When the data is sensitive and the scrutiny is real, that track record is the point. 

Governed sharing is one part of a wider picture. For how it fits alongside governance, case management and continuous improvement in delivering digital government, read our latest blog: Rewiring Public Services: How Finworks Delivers Digital Government That Works

Share what you must. Withhold what you shouldn't. Prove it. 

Whether you are standing up a new multi-agency arrangement or formalising how you share with a delivery partner, the place to start is a clear view of your lawful basis, your agreements, and how they are enforced today. See how Finworks turns data-sharing agreements into governed, auditable practice, across departments and with the providers who deliver alongside you.