Access Review Finding: A Dormant Admin Account With Active Sessions
During a quarterly access review at a payments processor, an analyst flags user account 'svc_ops_07'. It is a shared service account with system-administrator rights on the core transaction switch. The HR extract shows no employee owns it; it was created 14 months ago by an engineer who left 9 months ago. The identity system marks it 'inactive - no interactive login in 90 days', yet the switch's session log shows 312 authentications in the last 30 days from two internal IP ranges, all successful, all outside business hours. The change-management system shows no approved change referencing the account. The review owner proposes disabling it immediately; the operations manager objects, saying it may be used by an undocumented batch job and disabling it could halt settlement. Settlement runs at 02:00 daily.
1. Assess the risk posture of svc_ops_07 and justify whether immediate disablement is appropriate.
Read the worked answer
The account fails every ownership and least-privilege test: no accountable human owner, orphaned by a leaver, privileged on the most sensitive system (the transaction switch), and active in a way the identity system does not see (312 successful auths in 30 days vs. 'inactive' status). The off-hours pattern and absence of any approved change referencing it are red flags consistent with either an undocumented automated process or unauthorized use.
Immediate disablement is defensible on risk grounds but carries a real availability risk because settlement depends on the switch at 02:00. The judgement call is not 'disable vs. leave' but sequencing: the account is high-risk enough that it cannot simply be left running indefinitely, yet a blind disable the day before settlement could cause an outage. The defensible path is to (1) capture the 312 auth events and source IPs as evidence, (2) identify what process is authenticating - check the two IP ranges against the batch hosts, (3) coordinate with operations to observe or trace the 02:00 run, and (4) disable or rotate credentials with a rollback plan in place. Pure recall of 'disable dormant accounts' is wrong here; context dictates a controlled containment.
2. The operations manager insists the account powers settlement. How should the reviewer test that claim before acting?
Read the worked answer
Treat the claim as a hypothesis with a falsifiable test, not as grounds to stand down. Steps: map the two source IP ranges to specific hosts and confirm whether the settlement job authenticates as svc_ops_07; review the switch's session log timestamps against the 02:00 settlement window - 312 auths in 30 days is roughly 10/day, which is more frequent than a once-daily batch and suggests either retries or additional consumers; and check the settlement job's configuration for its service identity.
If the job does depend on the account, that is itself a finding: a settlement-critical process running under an orphaned shared admin account with no change record is a control failure regardless of intent. Remediation is to migrate the job to a named, owned, least-privilege service identity via an approved change, then retire svc_ops_07 - not to keep it because it 'works'. If the job does not depend on it, disable immediately and investigate the 312 auths as potential unauthorized access.