What should compliance and IAM teams align on before a MiCA licence application?

Scope first: what compliance and IAM need to agree before filing

The first alignment point is the boundary of the licence narrative. Teams need a shared view of which business activities, legal entities, jurisdictions, systems, and user populations are in scope so the application does not mix regulated and non-regulated controls. That includes deciding where IAM evidence stops and where broader compliance evidence begins, especially if operations span multiple products or affiliates.

For IAM, the scope conversation should turn abstract obligations into concrete identity populations and control owners. A licence application becomes much easier to defend when the teams can say which human and non-human access paths are relevant, which systems are authoritative for identity data, and which controls sit with security, operations, or the business.

Where the organisation uses cloud workloads, service identities, or delegated admin models, scope has to include those access paths too. Cloud Workload Identity Guide is a useful reminder that machine-access patterns belong in the control boundary, not just human login flows.

Another useful anchor is the record of which identities are actually governed by the programme. Identity Security Programme Guide helps frame ownership, scope, and operating model so the application does not depend on informal assumptions about who manages what.

Controls and artefacts: how to avoid contradictory evidence

Once scope is fixed, compliance and IAM should map each MiCA obligation to a specific control, owner, and proof point. The goal is not to produce more evidence, but to produce evidence that tells one consistent story across policy, process, configuration, and operating records. If two teams can describe the same control differently, reviewers will usually assume the control itself is weak.

The practical test is whether each obligation has a named control, a named system of record, and a current artefact that shows the control is operating. That may include access review records, approval workflows, role design, privileged access restrictions, joiner-mover-leaver evidence, or technical settings that enforce the policy in practice. If the control is manual, the evidence must still be repeatable and time bound.

For programmes that span multiple identity domains, it is helpful to use a single control vocabulary. Identity Security Regulatory Map is relevant because it ties identity controls to multiple regulatory obligations and reduces the chance that compliance and IAM create separate mappings for the same requirement.

When the issue is licence readiness rather than generic governance, the evidence set should be curated, not exhaustive. Ultimate Guide to NHIs, Regulatory and Audit Perspectives is a useful model for thinking about audit trails, governance obligations, and artefacts that a reviewer can actually test.

Operating model: who owns gaps, exceptions, and remediation

The last alignment point is ownership. Compliance should own the interpretation of the rule, but IAM should own how identity controls satisfy it, and the business should own the process changes needed to make the control sustainable. If nobody owns exceptions, the licence application will show polished documents but weak execution.

The teams should also agree on escalation thresholds before the application is submitted. For example, unresolved privileged access exceptions, missing attestation evidence, or unclear ownership of shared accounts should be treated as open issues, not narrative footnotes. A licence pack is stronger when it shows how exceptions are approved, time limited, and reviewed, rather than pretending they do not exist.

For teams that need a stronger operating model anchor, Identity Security Programme Guide is useful because it treats governance, RACI, and roadmap as part of the control design rather than an afterthought.

Practitioner Guidance

What to prioritise: Lock the scope and control map first, then build evidence from that map. If you start with documents before agreeing the control owner and source of truth, you will almost certainly end up with duplicated artefacts and mismatched wording.

What to verify: Check that every material MiCA obligation has one named owner, one control, and one proof point. If the same obligation is represented by different teams in different ways, treat that as a readiness defect, not a wording issue.

Decision rule: If a control cannot be traced to a live operational process and a current artefact, do not present it as fully evidenced in the application. Treat it as a remediation item or an exception that needs explicit sign-off.

Practitioner takeaway: The strongest licence submissions are built on a single control narrative, with compliance defining the obligation and IAM proving how access, entitlement, and governance controls satisfy it.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities for SOC 2 compliance?
• What should IAM and compliance teams audit before enabling enterprise AI at scale?
• What should IAM teams do before moving authorization into application runtime?