A data-sharing project can begin with a simple request: send the customer list, give the supplier access, collect the files from the consultant, or provide a dataset to another department. The difficult questions often arrive later. Who approved the exchange? What was the recipient allowed to do with the information? How long should they retain it? What happens when the relationship ends?
Reliable collaboration needs three things working together: a suitable data-sharing service, a clear agreement between the parties and an operating process that people can follow without inventing workarounds.
Collaboration control desk
Put the purpose, people, platform and proof on the same page.
A signed document cannot secure an uncontrolled transfer. A capable platform cannot decide whether the sharing is lawful or appropriate. Confidence comes from joining governance and delivery.
SHARE-04
Purpose
Defined
Parties
Named
Access
Limited
Retention
Agreed
Evidence
Recorded
Starting point / Define the sharing relationship
Not every external data exchange has the same legal or operational shape
One organisation may instruct a service provider to process personal data on its behalf. Two businesses may each decide how they will use a shared dataset. Partners may jointly design a project and make decisions together. Those distinctions affect contracts, responsibilities, transparency and the way incidents should be handled.
Sharing relationship selector
Choose the arrangement that most closely matches the work.
Governance before transfer
Controller to controller Controller to processor Joint working- C2C
- Independent decisions
Each organisation decides its own purpose
A data-sharing agreement can set out why information is shared, what each party may do with it, how individuals are informed and how requests or incidents will be coordinated.
Typical examples
Professional advisers, research partners, public bodies or businesses sharing customer information for separate purposes.
- C2P
- Processing on instruction
A supplier handles information for the controller
The written contract should define the processing, confidentiality, security, support, deletion or return of data, use of sub-processors and other required responsibilities.
Typical examples
Payroll providers, hosted service providers, outsourced support teams or specialist data-processing services.
- JOINT
- Shared decisions
Two or more parties determine the work together
The arrangement should explain their respective responsibilities, the contact route for individuals and how the shared purpose will be governed in practice.
Typical examples
Consortia, joint programmes, pooled services or projects where partners collectively decide how personal data is used.
Titles in a contract do not settle the position by themselves. Teams should examine who actually decides the purpose and means of processing. Where personal data is involved, legal or data-protection specialists may need to confirm the parties’ roles before the exchange begins.
The agreement / Write down the decisions that matter
A useful data-sharing agreement reads like an operating manual
The Information Commissioner’s Office describes data-sharing agreements as good practice. Its guidance says an agreement can clarify the purpose, what happens to information at each stage, the standards expected and the responsibilities of each party. The ICO’s data-sharing agreement guidance is a practical reference for UK organisations.
- AGREEMENT
- Operational clauses
01
- Purpose and benefit
- State why the sharing is necessary and what outcome it supports.
02
- Data and people
- Describe the information, affected individuals and any sensitive categories.
03
- Roles and contacts
- Name decision-makers, operational owners and escalation contacts.
04
- Access and security
- Define authorised recipients, authentication, transfer and storage expectations.
05
- Retention and deletion
- Set periods, review points and evidence required when information is removed.
06
- Rights and incidents
- Agree how requests, complaints, errors and suspected breaches will be handled.
07
- International access
- Record relevant locations, onward transfers and contractual safeguards.
08
- Review and exit
- Set renewal, change control, termination and return arrangements.
A processor relationship needs particular care. UK GDPR requirements for controller-processor contracts are more prescriptive than an informal collaboration note. The ICO’s controller and processor contract guidance explains the required clauses and why they matter.
Keep the agreement specific enough to guide behaviour. Phrases such as “appropriate security” are weak when nobody has agreed what authentication, access approval, encryption, logging or incident notification should look like.
Service selection / Match the platform to the exchange
A data-sharing service should enforce the decisions already made
General cloud workspaces are useful for storage, synchronisation and live collaboration. Email can suit low-risk, occasional communication. A secure B2B exchange platform becomes more relevant when the sender needs named recipients, controlled availability and evidence of activity across an organisational boundary.
- SERVICE
- Fit for purpose
Identity
Who can enter?
Capacity
Can it handle the full package?
Control
Can access expire?
Evidence
What activity is recorded?
Experience
Can partners use it consistently?
Evaluate the recipient’s experience as well as the administrator’s controls. A cumbersome process encourages staff and suppliers to return to personal drives, public links or oversized email chains. The approved route needs to accommodate real file sizes, ordinary external users and predictable support needs.
For sensitive external delivery, a controlled B2B file-exchange platform can provide a clearer boundary than an open link. Inbound collection deserves the same attention. A secure upload portal can give customers or suppliers a defined route for submitting information without using a shared inbox or consumer transfer service.
Daily operation / Make the agreement visible in the workflow
Confidence is lost when written rules and actual sharing drift apart
- Exchange ledger
- What the team should be able to answer
Before
What is being shared, for which purpose, with which approved recipient?
Decision recordedDuring
How is identity checked, how long is access available, and are comments kept with the exchange?
Controls appliedAfter
Was the package accessed, downloaded, superseded, returned or deleted as expected?
Evidence retainedReview
Have the purpose, parties, data or risks changed since the agreement was approved?
Agreement refreshedAssign an operational owner on each side. That person does not need to approve every routine transfer, but somebody should monitor exceptions, stale access, failed deliveries and changes to recipient teams. Agreements also need a review trigger when a project expands, a new supplier joins or the type of data changes.
Training should use realistic examples. Staff need to know which service to use for a large CAD package, where a customer should upload identity documents, who can approve a new external recipient and how to report a mistaken send. A policy that only says “share securely” leaves too much room for interpretation.
Platform support / Connect governance with traceable delivery
How My MX Data supports controlled collaboration
My MX Data is a secure B2B file-exchange platform. MX helps organisations send and receive information through named-recipient access rather than unrestricted public links. Multi-factor authentication adds another identity check, while configurable expiry helps prevent temporary access remaining open indefinitely.
AES-256 encryption forms part of the wider security model. Detailed transaction records can show uploads, access, downloads, comments and recipient activity. This provides operational evidence that can support internal reviews and wider compliance objectives.
MX Conversations keeps delivery notes and questions beside the relevant transaction. Linked Transactions connect follow-up exchanges without merging their histories. Recipient groups reduce repetitive setup, and MX Distribute can publish a current package to several parties while showing who has downloaded it and who remains pending.
Relevant arrangements may also support secure upload portals, single sign-on, custom domains, whitelabelling and data-location requirements. These options should be matched to the organisation’s agreement, security architecture and contractual responsibilities.
A platform cannot make the sharing decision on your behalf.
MX can provide controls, administration and evidence. Your organisation remains responsible for the lawful basis, transparency, data minimisation, supplier assessment, retention, staff behaviour, endpoint security and incident response.
Confident collaboration is quite practical. Decide why the information should move. Define the responsibilities. Select a service that can apply the agreed conditions. Then keep enough evidence to show that the real exchange followed the plan.