A common mistake is reviewing accounts without reliable human context. Teams may see a username or app account, but not know whether it belongs to an employee, contractor, or former worker. Another mistake is treating source systems as separate truths instead of reconciling them into one directory that supports ownership, status, and responsibility decisions.
Where account reviews go wrong
The biggest error is assuming the account record is the answer. In practice, account review is a reconciliation problem: the same person or process can appear as a user in one system, a contractor in another, and an inactive record somewhere else. If teams do not resolve those records into a trusted ownership view, they end up certifying labels instead of accountability.
That mistake shows up most clearly when business applications and infrastructure are reviewed in separate lanes. A directory entry, SaaS user, VPN login, admin account, and cloud principal may all represent the same operator or former worker, but they are often governed by different teams and different source systems. Without a common view of status, ownership, and sponsor, reviewers cannot tell whether an account should exist, who approves it, or what business function it still supports.
One useful way to think about the problem is that review quality depends less on the number of accounts inspected and more on the quality of the context attached to each one. Only when identity data is normalized and reconciled can teams make reliable decisions about access, recertification, disablement, or escalation. That is why lifecycle accuracy matters as much as access list completeness.
Why separate source systems create bad decisions
Business apps and infrastructure usually carry different fragments of the truth. HR may know employment status, the application may know last login, and infrastructure may know whether an administrator credential still works. If those signals are not joined, reviewers are forced to infer rather than verify. The result is either over-approval, where stale access survives, or over-removal, where active access is cut because the context was missing.
Trusted review depends on a single directory or equivalent reconciled layer that can answer basic questions consistently: who owns the account, what is the current status, whether the account is human or system-operated, and which business process requires it. That model does not eliminate exceptions, but it gives reviewers a defensible basis for them. It also makes audit evidence stronger because decisions can be traced to a common record rather than a spreadsheet full of conflicting exports.
For teams that need a deeper reference point on governance, visibility, and lifecycle control, NHIMG’s Ultimate Guide to NHIs is useful because the same reconciliation discipline applies when non-human accounts are part of the population under review. The operational lesson is broader than any one account type: if source-of-truth boundaries are unclear, review quality degrades fast.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 5 — Account Management | Account review depends on knowing which accounts exist and who owns them. |
| 6 — Access Control Management | The question is about deciding whether accounts should retain access across systems. | |
| Recommendation — Maintain accurate account inventories and reconcile ownership before certification decisions. Enforce consistent access decisions using a reconciled source of truth. | ||
| NIST CSF 2.0 | GV.OC — Organizational Context | Reviewing accounts correctly requires knowing business role, ownership, and lifecycle context. |
| PR.AA — Identity Management, Authentication and Access Control | The issue is fundamentally about reliable account identification and access decisions. | |
| PR.PS — Platform Security | Infrastructure accounts need governance across platforms and systems, not isolated checks. | |
| Recommendation — Define accountable ownership and authoritative context for each account population. Use authoritative identity data to support consistent account review and access decisions. Reconcile platform accounts into a single governance view before review. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Human-context accuracy depends on assurance about who the account represents. |
| AAL — Authentication Assurance Level | Reviewing accounts safely requires confidence that the authenticated account still reflects the right subject. | |
| FAL — Federation Assurance Level | Cross-system account review often depends on federated assertions and source trust. | |
| Recommendation — Match assurance strength to the identity evidence behind each account record. Require assurance that the active authenticator still belongs to the intended subject. Verify federation trust before using external account assertions in review decisions. | ||
| NIST Zero Trust (SP 800-207) | 4.2 — Policy Decision Point | Reconciliation and authorization decisions need a central policy decision basis. |
| 2.1 — Zero Trust Architecture Logical Components | The answer centers on aggregating identity context across systems to make reliable decisions. | |
| Recommendation — Centralize policy decisions so disparate account sources resolve to one access decision. Treat identity context as a shared control input across business apps and infrastructure. | ||
Practitioner Guidance
What to verify: Before a reviewer signs off, confirm that every account in scope has an owner, a current status, and a source of authority for that status. If any of those are missing, treat the item as unresolved rather than approved.
Decision rule: If the account cannot be tied to a responsible business owner and a current lifecycle state, do not rely on manual reviewer memory to bridge the gap. Escalate for reconciliation first, then certify or remove access after the record is corrected.
What good looks like: The review package should show one reconciled identity view, not a stack of contradictory exports. Reviewers should be able to distinguish active employees, contractors, former workers, and non-person accounts without cross-checking multiple systems by hand.
Practitioner takeaway: The real control is not the review meeting itself, it is the quality of the identity context that feeds it. If the record set is fragmented, the review outcome will be noisy, hard to defend, and likely wrong.
Related resources from NHI Mgmt Group
- How should security teams make NHI best practices usable across the business?
- What do teams get wrong when they try to scale access control across multiple SaaS applications?
- What do security teams get wrong when implementing sensitive data encryption for modern web applications?
- What do teams get wrong about using security frameworks for identity security governance?
