Employee offboarding is easy to describe and hard to close. One authorized departure event has to reach identity systems, application owners, device records, physical access and the people responsible for company information. A Virtual Employee can coordinate that work, but it should not decide whether employment ends or invent an effective time from a message or calendar entry.
The useful design starts with one rule: no verified HR trigger, no offboarding run. Everything after that should leave evidence a person can inspect.
MAJLS process map: trigger to closure
The UK's National Cyber Security Centre recommends a joiners, movers and leavers policy so access can be revoked when it is no longer needed.[1] NIST's personnel-termination control is more explicit about the work that follows: disable system access within an organization-defined period, revoke credentials, retrieve security-related property and retain access to organizational information formerly controlled by the departing person.[2]
Turn those control objectives into six operating steps.
- Accept one authorized trigger. Receive the employee identifier, effective time, departure type, requesting HR owner and change-record reference from the approved HR source. A forwarded email, chat message or manager note is not enough.
- Resolve one identity. Match the HR identifier against the corporate directory and worker record. Stop on a mismatch, duplicate record or missing effective time. Send the evidence to the named HR and identity owners instead of guessing.
- Compile the working register. Bring together corporate identity, managed applications, privileged and shared access, devices, physical credentials and information custody. Each item needs a system owner and a planned treatment.
- Separate preparation from authority. The Virtual Employee may prepare revocation requests, schedule actions already covered by system-owner rules and gather completion evidence. People decide nonstandard timing, employment questions, access exceptions, shared-credential changes, data custody and retention.
- Run the timed handoffs. Deliver owner tasks before the effective time, execute only approved technical actions at the recorded time, and retry only where a documented rule allows it. A failed action becomes an exception with an owner and due time.
- Close against evidence. Reconcile the register with system results, asset receipts and owner attestations. An unchecked item does not disappear from the run. A named IT security owner accepts closure, while HR confirms that the run used the authorized event.
The evidence trail matters. NCSC guidance says identity and access policies should define how audit records are acquired and protected, and which actions need more than one person to perform or authorize.[1] For this workflow, record the trigger, requested action, actor, timestamp, result, evidence link and exception owner. Do not treat an unreturned API call or a model-generated summary as proof of revocation.
Filled example: trigger-to-closure contract
This is an illustrative example, not a client deployment, a real employee record or a claim of measured results. A regional sales-operations analyst is leaving on an HR-approved date.
Verified trigger
| Field | Filled value |
|---|---|
| Authorized source | Approved HR leaver event feed |
| Worker identifier | SAL-042, illustrative token only |
| Effective time | 30 September 2026, 18:00 Gulf Standard Time |
| Departure type | Voluntary departure, supplied by HR |
| Requesting owner | HR Operations Lead |
| Change record | CHG-OFF-042, illustrative reference |
| Start condition | HR event signature valid; identifier and effective time match the worker record |
| Stop condition | Missing authorization, identity mismatch, duplicate run or changed effective time |
Access, asset and information register
| Item | System owner | Planned treatment | Evidence required | Human decision point |
|---|---|---|---|---|
| Corporate identity and SSO | IT Identity Lead | Disable at effective time under approved rule | Directory event ID and timestamp | Any timing change or failed disable |
| Regional CRM account | CRM Product Owner | Prepare owner-specific revocation task | Owner completion record | Transfer of open opportunities |
| Analytics workspace | Data Platform Owner | Revoke individual membership | Membership diff and timestamp | Ownership of private analyses |
| Shared campaign credential | Sales Systems Owner | No automatic action | Named owner response | Rotate, replace or document no access |
| Managed laptop and security key | IT Service Desk | Issue return task and track receipt | Asset receipt or open return case | Lost, damaged or unavailable asset |
| Customer files in personal workspace | Information Owner | Preserve access pending owner instruction | Custody decision and evidence link | Retention, deletion or legal-hold question |
Timed action sequence
| When | Virtual Employee action | Recipient or executor | Completion rule |
|---|---|---|---|
| One business day before | Compile the register and send unresolved ownership gaps | HR Operations Lead and IT Identity Lead | Every item has an owner or a named exception owner |
| Two hours before | Prepare revocation requests and confirm the effective-time record has not changed | Application owners | Current authorization and identity match remain valid |
| At the effective time | Submit the pre-approved SSO disable action | Identity platform | Recorded success event returned by the system |
| Within 15 minutes | Verify SSO status and dispatch application-owner tasks | IT Identity Lead and application owners | Evidence link recorded for each completed item |
| Within four hours | Reconcile access results, assets and custody questions | IT Security Owner | No silent blanks; every open item has an owner and due time |
| At closure | Produce the completion and exception register | IT Security Owner and HR Operations Lead | IT accepts technical closure; HR confirms trigger provenance |
Exception handoff
A failed CRM revocation in this example would produce this handoff:
- Exception: account still active after the owner task's due time.
- Observed evidence: revocation request ID, last status, system response and timestamp.
- Consequence: application access remains unresolved; no claim of complete offboarding.
- Owner: CRM Product Owner.
- Due time: 19:00 Gulf Standard Time on the effective date.
- Escalation: notify the IT Security Owner when the due time passes or the system returns a failure code.
- Prohibited shortcut: do not use model confidence alone to mark the account closed or choose an alternative action.
Checklist for a controlled first run
- Name the single HR source allowed to start the workflow.
- Define the required trigger fields and reject a run when any are missing or inconsistent.
- Give each access, asset and information item a named system owner.
- Document which technical revocations are pre-approved and which always require a person.
- Use observable exception conditions: authorization absent, identity mismatch, privileged account found, owner missing, action failed, asset unresolved or evidence absent.
- Keep consequential approval with a named human owner. The Virtual Employee may prepare evidence but may not approve employment, retention, legal-hold, nonstandard access or external commitments.
- Test the workflow with synthetic records before connecting it to live identities.
- Close only when the register reconciles or every remaining exception has an accountable owner, due time and recorded approval state.
The finished role is deliberately narrow. It turns one verified event into a timed, reviewable set of handoffs. People still own the decisions that affect employment, access exceptions and information obligations.