The Real Reason a Leaver's Account Is Still Alive

Summary

Accounts of departed employees stay alive not because offboarding was skipped but because there is no provisioning linking the HR system and the account system. SSO does not solve this problem.

What audits ask about first

In an information security audit or an ISMS-P assessment, the account-related questions are almost fixed.

1. Are departed employees' accounts disabled immediately? Show the evidence.
2. Show the list of accounts with administrator privileges and the reason each was granted.
3. How do you manage accounts with no login in the last N months?
4. Is the history of account creation, change, and deletion kept?
5. Do you periodically reconcile the HR system and the account system?

Number 5 is the core. The answers to the other four all come from this. And most organizations do number 5 by hand in Excel.

Why ghost accounts arise

It is not "because offboarding was skipped." There are structural causes.

Cause 1 — there is no provisioning

This is the biggest cause. Attaching SSO does not solve the account lifecycle.

Most incidents where "a departed employee can still log in to a SaaS" are due to the absence of provisioning, not SSO.

SSO only "verifies who it is at login." Creating and deleting user records inside that system is a separate job, and the standard for automating it is SCIM (RFC 7644).

Without SCIM it goes like this. When a person leaves, login is blocked at the IdP. But the account remains in the individual system, and if that system has even one local login path, they can still get in. And most systems have a local path called "emergency login when the IdP is down."

Cause 2 — incremental synchronization cannot see deletions

This was covered in the previous module. An approach that fetches "recently changed users" cannot see users who have vanished. If you do not periodically run a full synchronization alongside it, departed employees keep remaining.

Cause 3 — non-human accounts

Batch accounts, integration accounts, vendor maintenance accounts, test accounts. Because these are not in the HR system, they automatically drop out of the reconciliation. And they usually have strong privileges.

This is also where the audit finding ranks are high. "Whose account is this?" → "I think a vendor used it a while ago."

Cause 4 — moves that are not departures

Leave of absence, secondment, end of a partner contract, department transfer. These state changes do not have a trigger as clear as leaving the company. So permissions follow the person around. Keeping the previous department's permissions after moving departments is flagged in audits as "privilege creep."

How to reconcile mechanically

Extract the HR roster (HR) and the account list (directory) from both sides and do set operations.

A = HR 재직자 uid 집합
B = 디렉터리 계정 uid 집합

B - A  →  유령 계정 (퇴사했는데 계정이 남음)          ★ 1순위
A - B  →  미생성 계정 (입사했는데 계정이 없음)         업무 지연
A ∩ B  →  정상. 단 부서·직급 불일치는 따로 본다

Add three axes to this.

• Permission axis: among ghost accounts, those in an administrator group → immediate action targets
• Time axis: no login for 90 days or more → dormancy candidates
• Attribute axis: HR department ≠ directory department → personnel transfer not reflected

If you generate these five lists automatically every week and send them by email, it becomes operations and not audit response. A manual Excel reconciliation is done once a quarter, and incidents happen in between.

Account deletion vs deactivation

You must not delete a departed employee's account. There are several reasons.

• Audit trail: the owner information of the data that person left breaks
• Legal retention: in finance, healthcare, and so on, the access-history retention period is long
• Rehire: the same person sometimes comes back
• Referential integrity: it is tied to approval lines, assignee designations, and document authors

So the standard handling is quarantine.

1. 비활성화 (로그인 차단)          ← 즉시
2. 권한 그룹에서 제거              ← 즉시
3. 별도 OU 로 이동 (ou=Disabled)   ← 즉시
4. 사유·일자·처리자 기록           ← 즉시
5. 보존 기간 경과 후 삭제          ← 정책에 따라 (보통 1~5년)

Item 3 is practically useful. If you move it to a quarantine OU, it drops out automatically from the "active users" search filter while the data remains. And just by counting the entries in the quarantine OU, you can report the number of actions taken.

The principle of granting permissions — only through groups

If you start granting permissions directly to individuals, six months later nobody knows the whole picture. The principle is this.

• Attach permissions only to role groups
• People become members of role groups
• If an individual exception is needed, create a separate group with an expiry

And do not mix department groups and role groups. dev-team is an organization and role-deploy is a permission. Reorganizations happen often, and permissions must not collapse along with them each time.

Five numbers that must go in an audit report

A report does not need to be long. These five are enough to start the conversation.

Item	Meaning
Total accounts	Baseline
Ghost accounts	Departed employees remaining — must be 0
Accounts not created	New-hire delay — a work delay indicator
Ghosts among privileged accounts	Top-priority action
Accounts with no login in 90 days	Dormancy candidates

With numbers you can see the trend. "Ghost accounts went from 12 last month to 3 this month" proves improvement. Without numbers, you have to explain from scratch every time.

What it looks like in the field

The last of the five audit questions is the core — "Do you periodically reconcile the HR system and the account system?" The answers to the other four all come from here, yet most organizations do this by hand in Excel.

The problem with Excel reconciliation is not accuracy but frequency. With a reconciliation done once a quarter, an account does not die the day after someone leaves. And access in between remains only as a record — a control that cannot block it and only discovers it later.

It is also common to have only incremental synchronization set up, which is more dangerous. An approach that fetches only what changed cannot see deletions. A person who has disappeared from HR is not a "change," so it never comes across, and the account silently remains.

That is why you need a procedure that quarantines an account before deleting it. If you delete it right away, the documents and approval lines that person created break with it, and you cannot undo it either.