Pre-Review Baseline

Expanded Definition

A pre-review baseline is the point-in-time access picture captured before certification or attestation work begins. It records what was actually present, such as dormant users, orphaned accounts, service accounts, and applications already queued for review, so remediation can be measured against a known starting state.

In NHI and IAM operations, the baseline is more than a report extract. It is evidence context: it explains why an access review exists, what risk conditions were already in place, and whether subsequent changes were corrective rather than arbitrary. This matters for service accounts, API keys, and machine identities because their access can be persistent, widely distributed, and poorly documented. As NIST Cybersecurity Framework 2.0 frames governance and risk management, organisations need a defensible inventory and a repeatable way to show what changed and why.

Definitions vary across vendors on whether the baseline is a formal control artifact, a workflow snapshot, or a compliance record, but the operational goal is consistent: preserve the original state before any remediation begins. The most common misapplication is creating the baseline after cleanup has already started, which occurs when teams want a cleaner audit trail than the actual access state.

Examples and Use Cases

Implementing a pre-review baseline rigorously often introduces extra documentation overhead, requiring organisations to balance auditability against the speed of remediation.

• Before a quarterly access certification, a team snapshots all users and service accounts so inactive identities can be compared against the state that existed at review launch.
• During NHI remediation, a baseline captures orphaned API keys and unused certificates, then ties each revocation to the specific governance issue that triggered it. The Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which makes baseline capture especially important.
• In a cloud application review, the baseline shows which entitlements were inherited through group membership before role cleanup began, helping distinguish legacy access from newly approved access.
• For a CI/CD pipeline audit, a baseline documents long-term credentials stored in code or pipeline variables before secret rotation starts, so reviewers can confirm the original exposure surface. OWASP guidance on access and secret handling aligns with this evidence-first approach, while NIST Cybersecurity Framework 2.0 reinforces the need for current, reliable asset and access governance.

For certificate and token reviews, the baseline may also include expiry dates, ownership metadata, and last-used timestamps so remediation can be sequenced rather than applied blindly.

Why It Matters in NHI Security

Pre-review baselines matter because NHI risk is often invisible until auditors, incident responders, or platform owners discover that access has drifted far beyond policy. Without a baseline, organisations struggle to prove whether a change was necessary, whether a dormant identity was already present, or whether a remediation step accidentally removed legitimate access. That weakens audit evidence and complicates governance sign-off.

The case for this discipline is reinforced by NHIMG research: 97% of NHIs carry excessive privileges, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs. A baseline gives responders a way to separate pre-existing exposure from remediation results, which is essential when explaining why access was changed and whether the action reduced real risk. It also supports Zero Trust-style verification by making current state visible before action is taken, rather than assuming the directory is accurate.

Organisations typically encounter the need for a pre-review baseline only after a failed certification, an audit exception, or a suspected access incident, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When should organizations review their NHI policies?
• When should organizations review access controls?
• When should enterprises review their extension policies?
• When should organisations review service accounts and API keys?