Join our Newsletter — 33% off our NHI Course

What should healthcare and IT teams do first when building a digital identity programme?

The first step is to assess the current state of tools, processes, and maturity before adding new controls. From there, teams can identify gaps in governance, identity management, authorisation, and authentication. That baseline lets leaders prioritise investments in the right order, instead of layering technology on top of inconsistent practices and hoping the workflow problems disappear.

Why the first move is a baseline assessment, not a tool purchase

The right starting point is to understand what already exists. In healthcare and IT, digital identity work usually fails when teams add another product before they understand current workflows, approval paths, account sources, and authentication practices. A baseline exposes where identity data is incomplete, where ownership is unclear, and where the operating model already creates risk.

That assessment should cover process as much as technology. Teams need to see how identities are created, who approves access, how exceptions are handled, how service and shared accounts are managed, and where clinicians or staff rely on workarounds. For healthcare teams, that often means examining shared workstations, clinical access patterns, and downstream access to patient systems. For IT teams, it means tracing the actual path from onboarding to deprovisioning, including where manual steps still override policy.

A useful baseline is less about cataloguing every product and more about identifying the gaps that matter most to the programme design. If identity records are fragmented, if access reviews are not actionable, or if authentication is inconsistent across applications, those conditions shape the sequence of later controls. NHIMG’s Identity Security Programme Guide is useful here because it frames the programme around operating model, governance, roadmap, and ownership rather than isolated controls.

What the baseline should reveal about governance, identity, authorisation, and authentication

The baseline is meant to answer four practical questions: who owns the identity programme, what identities exist, what each identity can do, and how access is proved. Without those answers, teams tend to automate inconsistency. A clear current-state review should surface whether governance is centralised or fragmented, whether entitlement decisions are based on role or exception, and whether authentication strength matches the sensitivity of the workflow.

That matters because identity programmes in healthcare often span workforce access, third-party access, technical accounts, and patient-facing identity flows. A narrow view can miss the real control problem. For example, weak authorisation may show up as excessive application access, while weak authentication may show up as shared credentials, weak MFA adoption, or inconsistent sign-in experience across clinical and administrative systems. A baseline should make those distinctions visible before any redesign begins.

It also helps to separate identity lifecycle questions from access design questions. Provisioning, review, rotation, and revocation are different control problems from role design, session policy, or authentication assurance. If teams treat them as one workstream, they often lose accountability and cannot tell which part of the programme is improving. NHIMG’s Healthcare Identity Security Guide is a useful adjacent reference because it ties those controls to the realities of clinical access, shared workstations, medical devices, and regulated data access.

How to use the baseline to set the order of investment

The baseline should drive sequencing. First stabilise the highest-friction and highest-risk identity processes, then improve assurance and governance, and only then expand into more advanced controls. That usually means fixing ownership and lifecycle visibility before trying to optimise access analytics or introduce more sophisticated policy layers.

In practice, the first investment should usually go to the control that reduces the most ambiguity. If the organisation cannot reliably answer who has access, where identities come from, or how access is removed, then better reporting or a new access platform will not solve the underlying problem. If authentication is inconsistent, then standardising sign-in and step-up policy may deliver more value than adding another governance dashboard. A mature programme starts with the weakest operational link, not the most visible technology gap.

That approach is also easier to defend to leadership because it links spending to measurable state change. Teams can show that inventory quality improved, orphaned accounts decreased, access exceptions were reduced, and authentication coverage became more consistent across core systems. For teams building the programme in a healthcare environment, that order of operations matters because operational disruption is costly and trust in the process depends on visible improvements. NHIMG’s NHI Lifecycle Management Guide is relevant as a model for thinking about lifecycle discipline, visibility, and offboarding, even when the programme is broader than NHI alone.

Risk and Threat Considerations

Identity programmes that skip the baseline often create hidden exposure rather than reducing it. The common failure mode is control sprawl: teams deploy new tools over inconsistent account sources, weak ownership, and unmanaged exceptions, which makes access harder to explain and harder to revoke.

Failure mechanism: Fragmented identity records and inconsistent approval workflows leave excessive access, stale accounts, and weak authentication paths in place while creating the appearance of modernization.

Impact: The result can be unauthorized access to clinical or administrative systems, slower incident response, poor auditability, and greater blast radius when an account is misused or compromised.

Standards & Framework Alignment

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

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

Framework Control / Reference Relevance
NIST CSF 2.0 GV.OV-01 — Oversight of Cybersecurity Risk Management Baseline assessment supports governance oversight before control rollout.
Recommendation — Establish executive oversight for the identity baseline and use it to prioritise remediation.
NIST SP 800-53 Rev 5 PM-31 — Continuous Monitoring Strategy The question is about assessing current state before adding controls.
IA-5 — Authenticator Management The answer explicitly includes authentication practices and lifecycle gaps.
Recommendation — Define the monitoring scope and baseline measures before deploying new identity controls. Standardise authenticator lifecycle handling before adding new authentication layers.
ISO/IEC 27001:2022 A.5.9 — Inventory of information and other associated assets A current-state identity baseline depends on knowing assets, accounts, and ownership.
Recommendation — Build an inventory of identity assets and owners before implementing new governance controls.
CIS Controls v8 CIS-5 — Account Management The question centers on access, identity management, and account lifecycle ordering.
Recommendation — Prioritise account inventory, provisioning, and deprovisioning before expanding the programme.

Practitioner Guidance

What to prioritise: Start with a current-state inventory that covers identity sources, access approval paths, authentication methods, and offboarding behaviour across the main healthcare and IT systems. If those four areas are unclear, the programme is not ready for control expansion.

What to verify: Confirm that each critical identity type has an owner, a defined lifecycle, and a repeatable approval path. Verify that exception accounts, shared accounts, and service accounts are included in scope, not treated as edge cases.

Practitioner takeaway: The first useful milestone is not better technology, but a defensible baseline that shows where governance, access, and authentication actually break down, so later investment lands in the right order.