What do organisations get wrong when they treat a data catalog as a marketplace?

Why This Matters for Security Teams

When organisations describe a data catalog as a marketplace, they often expect it to solve discovery, trust, and access all at once. That expectation blurs three different controls: metadata inventory, governed reuse, and controlled entitlement delivery. A catalog can tell users what exists, but it cannot by itself prove fitness for purpose, manage approvals, or reduce the manual friction that security teams inherit.

This is where governance usually gets overstated. NIST’s NIST Cybersecurity Framework 2.0 treats access, oversight, and accountability as distinct capabilities, not a single feature. NHI Management Group’s Ultimate Guide to NHIs — Key Research and Survey Results shows why that matters in practice: only 5.7% of organisations have full visibility into service accounts, while 97% of NHIs carry excessive privileges. If the same mindset is applied to data, the catalog becomes a shelf, not a governed distribution channel.

Security teams also get pulled into exceptions because “marketplace” language implies self-service while the underlying controls still depend on manual review. In practice, many security teams discover access sprawl only after a data product has already been reused in production, rather than through intentional governance design.

How It Works in Practice

A true data marketplace layers workflow and policy on top of catalog entries. The catalog provides discovery, ownership, classification, and lineage. The marketplace layer adds business context, request routing, approvals, usage terms, and auditing. That distinction matters because users do not just need to find data, they need to know whether it is approved for a specific purpose and how to obtain it without opening a ticket maze.

Practitioners usually need four operational pieces:

• Business metadata that explains meaning, sensitivity, and intended use, not just technical schema.
• Controlled request flows that connect requesters to approvers, data owners, and policy checks.
• Entitlement enforcement that issues access only after review, ideally through automated policy.
• Reuse signals such as certified datasets, versioning, and usage history so users can trust what they select.

This is where current guidance suggests a policy-first model is stronger than a catalog-first one. NIST CSF 2.0 supports governance as a measurable function, while teams often borrow from access-management patterns used for NHIs because data products increasingly depend on service accounts, API keys, and machine-to-machine delivery paths. The NHI Mgmt Group’s Ultimate Guide to NHIs — The NHI Market is useful here because it highlights how governed distribution depends on visibility, lifecycle control, and privilege reduction, not just an inventory of assets. The same logic applies to data: discoverability is only the first step, while safe reuse depends on context, workflow, and enforcement.

Teams that build only a searchable catalog usually create a second help desk inside the product, because users still need someone to interpret sensitivity, approve access, and reconcile exceptions. These controls tend to break down when catalog entries are treated as authoritative without a separate workflow for ownership changes, dataset certification, and time-bound access.

Common Variations and Edge Cases

Tighter marketplace controls often increase operational overhead, requiring organisations to balance faster self-service against stronger approval and audit requirements. That tradeoff is real, especially for analytics teams that want broad reuse while security teams need defensible access boundaries.

One common variation is the “certified dataset” model, where only approved assets are promoted into the marketplace layer. That can work well, but best practice is evolving on how often certification should be refreshed and who owns stale metadata. Another edge case is cross-functional reuse in regulated environments. In those settings, the marketplace may need explicit purpose limitation, retention controls, and export restrictions rather than a simple request button.

There is also a practical distinction between internal marketplaces and external data-sharing portals. Internal users may tolerate lighter friction if policy is embedded, but third-party sharing usually demands stronger contract terms, monitoring, and revocation procedures. Organisations should also avoid assuming that a good UX replaces governance. A polished interface can improve adoption, but it cannot compensate for missing lineage, undefined ownership, or unclear approval authority. In short, the marketplace metaphor works only when the underlying control plane is real.

Related resources from NHI Mgmt Group

• What do organisations get wrong about data observability and data quality?
• What do organisations get wrong when they treat identity verification as a pilot project?
• What do organisations get wrong when they treat human, machine, and AI identities the same?
• What do organisations get wrong when they treat compliance frameworks as the same thing?