Should SAM be run centrally or as a federated model?

Why Centralised Versus Federated SAM Is Really an Ownership Question

SAM works best as a governance model, not just a tooling model. If software purchasing, renewal, and deployment are spread across business units, a federated operating model usually reflects reality better than a single central team trying to police every decision. Centralisation still matters for policy, reporting, and standard-setting, but accountability has to stay close to the people making purchasing and usage decisions.

The key design choice is not where the team sits on the org chart. It is whether one group owns the standards, data model, and reporting while local owners control demand, exceptions, and day-to-day usage evidence. That division only works when responsibilities are explicit, measurable, and enforced consistently.

Federation also reduces the common failure mode where a central SAM function becomes a bottleneck. If local units can buy software without clear intake, the central team will only ever see partial data. If local units are forced to route every decision through a single queue, they often bypass the process. The better operating model is the one that matches how software is actually consumed.

In practice, mature SAM programmes usually combine a central control plane with distributed execution. The centre defines policy, taxonomy, and reporting, while local teams supply entitlement, deployment, and usage evidence. That makes the programme more scalable and improves the chance that license position, compliance status, and reclamation decisions are based on current facts rather than stale spreadsheets.

Where Central Control Still Matters in a Federated SAM Model

Federation does not mean fragmentation. A central team should still own catalogue rules, measurement standards, reconciliation logic, and the escalation path for disputes. Without that common model, different business units will count the same software differently, which makes enterprise reporting unreliable and weakens vendor negotiations.

Central ownership is also the right place for policy exceptions and material risk decisions. For example, if a business unit wants a non-standard contract term, a duplicate tool, or a usage pattern that breaks licensing assumptions, the central function should review it against enterprise standards. This is where SAM links to broader governance: standardisation, evidence quality, and auditability all depend on a single source of truth.

Local accountability is just as important. A federated model only works when business-unit owners can explain what they bought, why they bought it, who uses it, and when it should be retired. That ownership is especially important for cloud services, shadow IT, and subscription renewals because those categories drift quickly when no one close to the demand side is responsible.

For practitioners building the operating model, the practical question is whether the central team can influence behaviour without owning every transaction. If yes, federation can work well. If no, the programme is probably missing authority, not structure.

What Good SAM Operating Model Decisions Look Like

A good SAM model draws a clean line between enterprise control and local execution. Central teams should own policy, data definitions, assurance routines, and vendor reporting. Local teams should own intake, approval, consumption tracking, and the first response when usage or entitlement data is wrong. That split gives the central function leverage without removing accountability from the business.

This is also where integration quality becomes a decision point. If procurement, finance, endpoint inventory, cloud billing, and identity data are poorly connected, the organisation will argue about numbers instead of managing software. The answer is not to centralise everything by default, but to make the operating model match the systems that already produce the evidence.

A federated structure usually performs best when each domain has a named owner and a standard review cadence. That cadence should answer three questions: what is installed or subscribed, who is accountable for it, and what action follows when the data is inconsistent. Without that rhythm, SAM becomes a reporting exercise instead of a control function.

Risk and Threat Considerations

Weak SAM ownership creates license non-compliance, budget leakage, and blind spots in software exposure. A purely central model can miss local purchasing reality, while a purely federated model can create inconsistent data, duplicated tools, and weak enforcement of contract terms.

Failure mechanism: When ownership is vague, software enters through shadow channels, renewals auto-repeat, and usage evidence is never reconciled against actual demand or deployment. That makes overspend and audit failure more likely, and it can also leave unmanaged software running longer than intended.

Impact: The business loses negotiating power, cannot trust software inventory, and may face compliance issues when vendor true-up or audit evidence is requested. In higher-friction environments, the bigger risk is not a single mistake but repeated drift across many teams.

Practitioner Guidance

What to prioritise: Define the decision rights before debating the org chart. Decide which controls are central, which are local, and which require joint approval so that the model can be enforced instead of merely described.

What to verify: Check that every software item has a named business owner, a technical evidence source, and a review cadence. If any of those three are missing, the operating model is too vague to support reliable governance.

Common mistake: Treating centralisation as maturity. In SAM, stronger governance usually comes from clear ownership and better evidence flows, not from moving every task to one team.

Practitioner takeaway: Choose the structure that matches where buying decisions actually happen, then make ownership explicit enough that the central team can govern quality without becoming the bottleneck.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How does the consumer-secret-entitlement model help with governance at scale?
• How should organisations govern non-human identities in a federated IAM model?
• How do organisations keep governance strong when they run a hybrid authentication model?