How do regulatory requirements affect where IAM should run?

Why regulatory placement decisions are really governance decisions

When regulation is in play, the question is not just where IAM is technically hosted, but who can prove control, how the service is supervised, and whether the chosen operating model can survive audit and disruption. That makes IAM placement a governance decision about accountability, resilience, and supplier dependence as much as a platform decision.

For organisations operating across cloud, shared services, or outsourced delivery, the practical test is whether the IAM design preserves evidential control over access policy, administration, and recovery. If the answer changes when a regulator asks for oversight proof, the deployment location and control boundary matter.

Regulatory mapping is easiest to justify when it is tied to the specific access function the platform performs. A workforce IAM portal, privileged access layer, or workload identity service creates different supervisory expectations, and a regulatory map for identity security helps teams connect those expectations to the control set they already need to operate.

What DORA and NIS2 change about supplier concentration and continuity

DORA and NIS2 push IAM out of the “shared IT utility” category and into the class of services that must be explainable under stress. If too much access control depends on one vendor, one region, or one operating team, the organisation inherits concentration risk, and the regulator will care about the fallback path as much as the primary path.

This is why placement decisions often shift toward stronger contractual oversight, redundant operating capability, and clearer segregation of duties. A central identity provider can still be acceptable, but only if continuity, logging, and administrative control remain demonstrable during outage, compromise, or change failure.

The continuity question becomes sharper when IAM is the dependency that unlocks every other system. In that case, the service cannot be treated as a convenience layer. It needs operational resilience, tested recovery, and a clear line of sight from the access decision to the party responsible for keeping it available.

If you are aligning an IAM operating model to those expectations, the most useful internal navigation is often the lifecycle and governance layer, especially where access review, rotation, and recovery responsibilities intersect with regulation. NHIMG’s regulatory and audit perspectives explain how governance obligations surface in identity operations, while the lifecycle processes for managing NHIs section shows why continuity depends on owning the full access lifecycle.

How to judge where IAM should run in practice

In practice, the right location is the one that lets you keep control over administration, evidence, and recovery without creating unnecessary dependency risk. That may be on-premises, in a controlled cloud service, or in a hybrid pattern, but the decision should be anchored in the regulated business criticality of the access layer rather than in convenience alone.

For most teams, the useful question is whether the IAM deployment model preserves the ability to answer three things quickly: who administers it, where the control plane runs, and what happens if the provider or region is unavailable. If those answers are vague, the placement is probably too dependent on the supplier.

Where IAM also governs service accounts, APIs, or machine access, the placement choice should also reflect the blast radius of failure. A platform that centralises policy well but cannot isolate workloads, limit privileges, or recover quickly may satisfy architecture preferences while failing the governance test.

For a broader identity architecture view, an identity provider buyer’s guide is useful when the real decision is between operating models, and the identity security programme guide helps teams assign ownership when regulatory accountability spans both internal and external services.

Risk and Threat Considerations

Concentrating IAM in one external service or one administrative domain can create systemic exposure: a failure, outage, or compromise may affect authentication, access approvals, and recovery across the business. Regulation increases the severity of that exposure because the organisation must also demonstrate oversight, continuity, and control of the dependency.

Failure mechanism: The deployment becomes fragile when operational control, audit evidence, or administrative access is controlled by a supplier that the organisation cannot sufficiently observe, test, or replace during disruption.

Impact: Access to critical systems may be delayed or lost, incident response can be slowed, and the organisation may be unable to evidence compliance when regulators or auditors ask how the service remains available and governed.

Practitioner Guidance

What to prioritise: Start with the IAM functions that would stop operations if they failed, then map where administration, logging, backup, and failover actually sit. The right location is the one that preserves control over those functions under regulatory scrutiny, not the one with the simplest procurement path.

What to verify: Confirm that the organisation can still manage access, revoke privileges, and restore service during provider outage, regional disruption, or contract termination. If that cannot be shown with evidence, the placement decision is too dependent on trust rather than resilience.

Practitioner takeaway: Regulatory pressure usually does not dictate a single hosting model, but it does eliminate designs where IAM is easy to consume and hard to prove, recover, or replace.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• What is the difference between human IAM controls and NHI governance?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• Where does cross-environment agent discovery fit in an IAM programme?