How to Move from Ad Hoc Offboarding to a 30-Day Exit Plan

To move from ad hoc offboarding to a controlled process, define who owns each departure step, remove or transfer access on the employee’s last day, and perform documented follow-up checks for 30 days. This is how to create a 30 day employee exit plan that produces evidence for ISO 27001 while remaining manageable for one IT administrator: standardize the workflow first, pilot it with real departures, then make the process mandatory through HR and manager notifications. The result is a repeatable exit record showing that continuing security duties were communicated and access was handled on time.

What does your current offboarding state actually look like?

Before designing a compliant process, document what happens today rather than what policy says should happen. As a sole IT admin, you may receive a manager’s Slack message after an employee has already left, search through several SaaS consoles, disable obvious accounts, and hope there are no shared credentials, API tokens, or company devices missing. That is not a process you can reliably evidence or improve.

ISO 27001 practice 6.5, Responsibilities After Termination or Change of Employment, requires that information security responsibilities and duties that remain valid after termination or a role change be defined, enforced, and communicated to relevant personnel and interested parties.[1] Your assessment must therefore cover more than account deletion. It must identify who tells the departing worker about confidentiality and return obligations, who tells IT, who confirms access removal, and who checks for remaining responsibilities after the final day.

Which gaps should you measure first?

Set a baseline using the previous three to six departures. Calculate the elapsed time between HR notification and account suspension, count accounts found after the initial offboarding action, and identify departures without a completed record. Do not wait for perfect data. A simple spreadsheet with departure date, notification date, systems removed, assets returned, and evidence links is enough to expose the process failures you need to fix.

How do you create a 30 day employee exit plan that fits your environment?

Your target state should be a 30-day offboarding plan with four time windows: pre-exit preparation, last-day access removal, early post-exit confirmation, and a 30-day closure review. The plan should use one tracked ticket as the system of record, even if your organization is small. A ticket prevents requests from being lost in email and gives you a timestamped evidence trail without creating a separate compliance program.

Define the minimum roles before automating anything. HR owns initiating the exit workflow and providing the departure date. The manager owns work transfer, customer handoff, and identifying business systems or data held by the employee. IT owns identity, device, application, and privileged-access actions. Finance, legal, security, and system owners are interested parties when their responsibilities apply. For a role change, use the same workflow but replace termination actions with access review and removal of no-longer-needed entitlements.

What should the target workflow require?

• T-5 to T-1 business days: HR opens an offboarding ticket, manager identifies systems, IT reviews privileged access, and HR prepares continuing-obligations communication.
• Last working day: IT suspends central identity access, revokes active sessions, removes high-risk application access, collects or locks devices, and rotates shared credentials when required.
• Days 1 through 7: IT reviews residual access, transfer rules, shared mailboxes, repository ownership, cloud keys, and active sessions; the manager confirms work handover.
• Days 8 through 30: IT closes lingering vendor accounts and checks for attempted sign-ins, while HR retains acknowledgement of post-employment obligations.
• Day 30: The ticket is closed only after required evidence is attached, exceptions are accepted by an owner, and remaining duties are recorded.

For example, a 75-person payments company using Google Workspace, Okta, Jira, GitHub Enterprise Cloud, AWS, and CrowdStrike can make Okta the central disablement point while still assigning explicit application checks. Disabling an Okta user may remove SSO access, but it will not necessarily revoke a GitHub fine-grained personal access token, transfer a Jira project ownership role, or rotate a shared Stripe test-mode secret stored outside the password vault. The plan must identify those separate actions.

What phased migration plan can one IT admin complete without stopping normal work?

1. Phase 1: Establish the baseline and sponsor (Week 1). Review recent departures, name HR as the initiating owner, and obtain agreement that no manager may bypass the ticket. Milestone: A one-page gap list and an approved RACI are stored with the ISO 27001 evidence.
2. Phase 2: Build the minimum workflow (Weeks 2–3). Create an “Employee Exit” ticket type in Jira Service Management or your existing help desk. Add required fields for last day, manager, employment type, device assigned, privileged access, forwarding requirement, and legal/HR acknowledgement. Milestone: The form cannot be submitted without a departure date and manager.
3. Phase 3: Create system-specific checklists (Weeks 3–4). List the systems that require direct action when SSO or SCIM is incomplete. Start with identity provider, email, endpoint management, VPN, cloud, source control, password manager, finance tools, and customer support. Milestone: Each critical system has an owner, action, evidence type, and deadline.
4. Phase 4: Pilot the 30-day exit process (Weeks 5–6). Use the new process for two planned exits or one exit and one role change. Do not automate exceptions during the pilot; document every manual step and missed handoff. Milestone: Both pilot tickets reach Day 7 with no unexplained active accounts.
5. Phase 5: Cut over and enforce (Weeks 7–8). Make the ticket mandatory, train HR and managers in a 20-minute session, and publish the escalation path for late notice. Milestone: Leadership approves that IT will not action informal termination requests except as emergency incidents.

At a 40-person fintech with Microsoft 365, Entra ID, Intune, Azure, GitHub, and a third-party transaction-monitoring platform, the pilot exposed a typical gap: HR notified IT, but the manager did not identify that the departing analyst had an Azure subscription Contributor role. The revised checklist added an Azure role-assignment export and manager attestation before closure. That is the value of migration: you turn an individual discovery into a permanent control.

What should the cutover runbook and rollback procedure include?

Cutover means the date on which the new ticketed process becomes the only approved path. Keep the runbook short enough to follow during a same-day termination, but specific enough that another administrator or managed service provider could execute it if you are unavailable.

Emergency exit sequence
1. HR or executive opens an Employee Exit ticket and marks "Immediate".
2. IT disables the identity account and revokes active sessions.
3. IT removes VPN, cloud administrator, source-control owner, and password-vault access.
4. IT preserves required mailbox and audit data according to retention rules.
5. IT records each action, timestamp, executor, and evidence link in the ticket.
6. IT notifies HR and the manager that access is disabled.
7. IT starts the Day 1 residual-access review.

Rollback should never mean restoring all prior access because an employee claims they need one file. Restore only the minimum access approved by HR, the manager, and the system owner, set an expiry time, and create a new ticket task. For an actual termination, prefer manager-provided files, delegated mailbox access, or controlled data export over reactivating the former employee’s identity.

How do you validate the process after migration?

Post-migration validation proves that your 30-day offboarding plan works in practice and supports ISO 27001 practice 6.5. Review every exit ticket at Day 7 and Day 30 for completeness, then perform a monthly sample review for the first quarter. You are looking for timely action, clear responsibility, communication of remaining duties, and evidence that exceptions were managed rather than ignored.

• Compare the HR termination list against closed and open exit tickets; every departure should have one record.
• Sample identity-provider, VPN, cloud, GitHub, and password-vault access for terminated users and confirm access is absent.
• Review sign-in logs for attempted access after termination and investigate successful authentication immediately.
• Confirm the exit communication or acknowledgement addresses confidentiality, return or destruction of company information, and any continuing contractual duties.
• Measure notification lead time, last-day completion rate, Day 7 residual-account findings, and Day 30 closure rate.
• Record corrective actions, such as adding a newly discovered vendor application to the checklist or retraining a manager who bypassed HR.

A practical success target for the first 90 days is 100% of departures initiated through the ticket, 95% of standard access removed by the last working day, and zero unexplained privileged accounts after the Day 7 review. If you miss those targets, treat the cause as a workflow defect, not a reason to add more reminders to your own calendar.

Next step: This week, create one mandatory Employee Exit ticket template and use it to assess your last three departures before the next one arrives.