What should organisations do first when building an access management program?

The first step is a comprehensive audit of current access. Organisations need to identify roles, privileges, and active entitlements before they can set policy or deploy controls. Without that baseline, teams end up automating bad assumptions. A clear inventory also helps prioritize where privileged access, MFA, and monitoring are most urgently needed.

Start with an access baseline, not a policy stack

An access management program should begin by establishing what access already exists. That means identifying users, service accounts, roles, entitlements, and the systems those entitlements can actually reach, so the program starts from evidence rather than assumption. The baseline is the foundation for later decisions about least privilege, privileged access, MFA, review cadence, and monitoring.

A useful first pass is the same discipline captured in NHI Lifecycle Management Guide: inventory first, then classify ownership and purpose before you try to optimise control design. In practice, that avoids building governance around stale roles, duplicate accounts, or hidden machine access that never shows up in policy documents.

The inventory should be granular enough to answer three questions: who has access, what they can do, and why they have it. If you cannot answer those questions cleanly, you do not yet have an access management program, only a collection of disconnected controls. This is also where organisations often discover that the biggest risks are not exotic, but routine, such as orphaned access, overbroad roles, and long-lived exceptions.

Why the first step is discovery before control design

Access management fails when teams start by choosing tools, approval workflows, or enforcement rules before they understand the current state. Policy without baseline data tends to overfit to assumptions from one team or one system, then break when applied across legacy applications, cloud services, and administrative paths. A current-state audit lets you separate intended access from inherited access, and temporary access from standing access.

The same logic appears in broader access-governance references such as CIS Controls v8 and NIST SP 800-53 Rev 5 Security and Privacy Controls, both of which treat inventory, account management, access control, and auditability as prerequisites for effective enforcement. Those controls only work well when the organisation already knows what needs to be governed.

Discovery also reveals where access management effort will produce the most risk reduction. A mature program usually prioritises privileged accounts, shared accounts, automation credentials, externally facing access, and dormant entitlements before it spends time refining low-risk approvals. That sequencing matters because not every entitlement deserves the same review depth or the same remediation speed.

What a practical first pass should produce

The first audit should result in a usable inventory, not a perfect one. Practitioners need a list that can be acted on: role names, associated privileges, system owners, business justification, and whether the access is human, service, or shared. From there, teams can identify obvious cleanup items, establish review priorities, and decide where stronger authentication or privilege controls are needed first.

A good starting point is to group findings into a few operational buckets: legitimate access with clear ownership, access that is valid but too broad, access with unclear ownership, and access that appears unused or orphaned. That classification is more useful than trying to solve every issue in one pass because it creates an immediate remediation queue and makes accountability visible.

For many organisations, this is also the point at which MFA, privileged access workflows, and monitoring become targeted investments rather than blanket rollouts. The baseline tells you which identities and entitlements are highest value to protect, which ones are most exposed, and where a control failure would have the largest blast radius.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-5 — Account Management	Access programs begin with account and entitlement inventory.
Recommendation — Inventory accounts and entitlements before tightening access controls.
NIST SP 800-53 Rev 5	AC-2 — Account Management	The question is about establishing and governing current access before control design.
	IA-5 — Authenticator Management	Baseline access work reveals credentials and authenticator scope that must be managed.
Recommendation — Establish account inventory and review processes before enforcing policy. Track authenticator lifecycle alongside access inventory to reduce unmanaged access.
ISO/IEC 27001:2022	A.5.15 — Access control	Access management programs need a defined baseline before access rules can be applied.
	A.8.2 — Privileged access rights	The first audit should surface privileged access for targeted governance.
Recommendation — Define and enforce access control using a verified inventory of current access. Identify privileged accounts early and review their standing access first.

Practitioner Guidance

What to prioritise: Start with systems and identities that can change financial, production, or security-sensitive data, then move outward. If the inventory is incomplete, prioritise sources of truth over manual spreadsheets and reconcile access against authoritative system records first.

What to verify: Confirm that every entitlement has an owner, a purpose, and a current business need. If any of those three are missing, treat the access as an exception until proven otherwise.

Common mistake: Teams often try to define roles before they understand actual access patterns. That usually produces neat-looking policy that does not match how people and systems really operate.

Practitioner takeaway: The first job is not to enforce stricter access, it is to make access visible enough that enforcement can be accurate, defensible, and worth automating.