They usually get partial adoption, limited trust, and poor reuse of data assets. The article shows that successful sharing depends on collaboration, user enablement, workshops, and change management, not just tooling. When data sharing is treated narrowly, teams may still move data, but they will not create the shared understanding needed for faster decisions and sustained business value.
When data sharing is treated like a software rollout
Organisations often discover that data sharing is not mainly a tooling problem. If the operating model is missing, teams may exchange datasets but still fail to agree on ownership, definitions, quality expectations, and support processes. That is why the visible output can look successful while the business outcome remains weak: the data is moved, but the collaboration model is not.
That mismatch usually shows up as partial adoption. One group builds a platform or pipeline, another group is expected to consume it, and neither side has a durable mechanism for prioritisation, issue resolution, or ongoing enablement. The result is often a technically functional service that is underused because it does not fit how people actually work.
Successful sharing depends on the Identity Security Programme Guide style of operating discipline in a broader sense, meaning clear ownership, a defined service model, and coordinated governance around the shared asset. In practice, that means data product responsibilities, stewardship, and adoption planning need to exist alongside the technology rather than after it.
Why trust and reuse break down
Reuse depends on more than access. If users do not trust the source, do not understand the definitions, or cannot see how the data was prepared, they will create shadow copies, manual workarounds, or local extracts. That fragments the data landscape and undermines the very reuse the programme was supposed to create.
This is also where workshops and user enablement matter. They are not optional “soft” activities; they are the mechanism that turns a shared asset into a usable one. Teams need a common interpretation of the data, a feedback path for defects, and enough guidance to integrate the shared data into their own decision-making.
The same pattern appears in cross-team security and governance programmes: when the shared capability is treated as a product alone, people consume it inconsistently. The CSA Cloud Controls Matrix is useful here because it reinforces that cloud and data capabilities need governance, accountability, and operational controls, not just technical implementation.
What changes when the operating model is built around sharing
A cross-functional operating model changes the question from “Can we move data?” to “Can the organisation reliably use shared data to make decisions?” That shift forces agreement on ownership, support, change control, consumer onboarding, and quality management. It also makes adoption measurable, so leaders can see whether the asset is actually being reused.
This is where the best programmes separate platform enablement from business enablement. The platform delivers transport, storage, access, and interfaces. The operating model provides the social and procedural glue: naming conventions, stewardship, escalation, communication, and a shared understanding of what good looks like. Without both, reuse tends to stall after the first enthusiastic pilot.
For practitioners who want a control lens, the most relevant external reference is the ISO/IEC 27002:2022 Information Security Controls, because it reflects the wider principle that effective programmes rely on organisational and procedural controls as much as technical ones. Data sharing is similar: execution quality depends on how the service is governed, not just on the tooling underneath it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | PM-30 — Supply Chain Risk Management | Data sharing operating models rely on governed third-party and inter-team dependencies. |
| Recommendation — Define ownership and oversight for shared data dependencies before scaling distribution. | ||
| ISO/IEC 27001:2022 | A.5.1 — Policies for information security | Shared data needs policy-backed operating rules and accountability across teams. |
| Recommendation — Set policy, ownership, and exception handling for shared data services. | ||
| CSA Cloud Controls Matrix | GRC — Governance, Risk, and Compliance | The question is about cross-functional governance, trust, and operating discipline for shared data. |
| Recommendation — Embed governance, stewardship, and control ownership into the data-sharing operating model. | ||
Practitioner Guidance
What to prioritise: Start with ownership and consumption, not with platform features. If no business owner can explain who approves definitions, resolves disputes, and supports users, the sharing model is still immature.
What to verify: Check whether users can describe the dataset in the same terms as the producers, whether onboarding is documented, and whether recurring data issues have a named escalation path. If those elements are missing, adoption problems are structural, not cosmetic.
Common mistake: Treating successful transmission as success. A file transfer, API, or shared lake can work technically while the organisation still fails to reuse the data consistently or trust the output.
Practitioner takeaway: The real unit of delivery is not the data pipeline, it is the repeatable operating model that lets multiple teams trust, interpret, and reuse the shared asset over time.
Related resources from NHI Mgmt Group
- What breaks when organisations treat the Essential Eight as a one-off project instead of an operating model?
- What happens when organisations treat trust as a communications exercise instead of a governed operating model?
- What happens when organisations try to govern data, privacy, and AI separately instead of through one integrated operating model?
- What happens when organisations treat innovation as a side project instead of a core operating discipline?
