Why does differing digital maturity create risk when NHS organisations try to work more collaboratively?

Why digital maturity gaps make collaborative NHS working harder

Collaborative working only functions smoothly when organisations can rely on each other’s processes, controls, and governance decisions. If one Trust has mature access governance, auditability, and change control while another is still standardising basic practices, the partnership inherits the weakest operational assumptions. That creates friction at the seams, where data sharing, joint working, and service handoffs depend on comparable standards.

In practice, the risk is not simply that one organisation is “less advanced”, but that differences in maturity change what each side can safely assume. A mature partner may expect structured approvals, traceability, and timely incident handling, while a less mature partner may still be operating with inconsistent ownership or uneven control coverage. Collaboration then becomes slower, more exception-driven, and more dependent on manual compensating controls.

The problem grows when teams try to scale the collaboration beyond a pilot. What is manageable between a few named individuals can become fragile when shared pathways, joint workflows, and common datasets are used routinely across multiple organisations. At that point, maturity gaps stop being an administrative annoyance and start affecting security, compliance, resilience, and service delivery.

Where the risk shows up in real collaboration

Different levels of maturity usually surface in four places: governance, access control, operational discipline, and assurance. Governance gaps appear when organisations do not agree who owns decisions, exceptions, or remediation. Access-control gaps appear when each party interprets least privilege, approvals, or account lifecycle differently. Operational gaps appear when incident response, logging, and change management are not equally reliable. Assurance gaps appear when one side cannot evidence control performance to the same standard as the other.

That mismatch matters because collaboration usually creates shared dependencies. If a shared service, joint record, or inter-organisational workflow fails, both organisations may be affected, but not in the same way. The more uneven the maturity, the more likely one side must absorb the operational burden for the other, which can create hidden workload, delayed decisions, and unresolved risk ownership.

This is why a maturity assessment is useful before deep collaboration begins. It identifies whether the partnership can move at the speed of the most capable organisation or whether it needs a staged model with interim controls, extra oversight, or limited scope. In effect, maturity assessment is not a bureaucracy exercise, it is a way to avoid building a joint service on assumptions that only hold for one participant.

What leaders should do before scaling collaboration

Leaders should treat maturity differences as a design constraint, not a temporary inconvenience. When the gap is large, the safest approach is often to narrow the first use case, define explicit control expectations, and agree what evidence is required before expanding scope. That is especially important where collaboration depends on OWASP SAMM-style maturity thinking, because the question is not just whether a control exists, but whether it is repeatable, evidenced, and sustainable across organisations.

In governance terms, the critical decision is whether the partnership can operate with a common baseline or whether it needs compensating controls for the weaker starting point. If access, approvals, logging, or escalation paths differ materially, then joint working should not assume equivalence. The right response is to standardise the minimum viable control set first, then expand only when both parties can show stable operation.

For organisations with digital transformation or cross-boundary service goals, it is useful to compare the collaboration model with broader control expectations such as NIST SP 800-53 Rev 5 Security and Privacy Controls, NIST Cybersecurity Framework 2.0, and NIST Privacy Framework. Those references help leaders map maturity gaps to control coverage, governance, and privacy responsibilities without assuming both organisations are starting from the same point.

Risk and Threat Considerations

When maturity is uneven, the main risk is that collaboration widens the attack surface and the operational blast radius at the same time. Weak governance can allow unclear ownership, inconsistent access decisions, and delayed remediation. Weak operational discipline can make a minor misconfiguration or service failure propagate across organisations before anyone detects it.

Failure mechanism: Shared processes fail where one organisation assumes controls, evidence, or escalation paths that the other does not yet consistently operate. That creates gaps in authorisation, logging, exception handling, and service recovery, especially when data or workflows move across organisational boundaries.

Impact: The partnership can end up with avoidable security exposure, audit gaps, service interruptions, and disputes over accountability. In the worst case, a collaborative service becomes only as trustworthy as its least mature participant, which weakens confidence and slows future integration.

Practitioner Guidance

What to prioritise: Start with the controls that collaboration cannot function without, shared ownership, access governance, incident escalation, and evidence of who can approve what. If those are not aligned, broader transformation work should wait.

What to verify: Confirm that each organisation can show the same basic operational outcomes, not just the same policy language. Look for working approval flows, timely revocation, audit trails, and a clear named owner for exceptions.

Practitioner takeaway: The safest collaborative model is not the one where every organisation is equally mature, but the one where differences are made explicit and designed around before they become shared failures.

Related resources from NHI Mgmt Group

• Why does a fragmented compliance model create risk when organisations try to measure Essential Eight maturity?
• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?