ISO 27001 Annex A 6.5: offboarding, movers and surviving duties

The due-diligence questionnaire asks how you offboard staff. The honest answer is a checklist HR believes IT completed, and an IT team that assumed the line manager had it. An auditor finds that gap in minutes by comparing HR leave dates with account timestamps.

This guide covers ISO 27001 Annex A 6.5 for security leads and operations heads at 25–250-person firms. It sets out the contract wording, the last-day protocol, duty handover, movers, the audit sample and the automation that makes all of it routine.

What do ISO 27001 responsibilities after termination or change of employment require?

ISO 27001 responsibilities after termination or change of employment means deciding which security duties keep binding a person once they leave or move role, then making those duties contractual, reminding people at exit, and handing the leaver's security responsibilities to a named successor. The control is preventive, covering employees, contractors and supplier staff.

The control is titled Responsibilities after termination or change of employment, and it breaks into three jobs:

• Surviving duties. Confidentiality above all, plus intellectual property and any agreement-specific commitments, written into the contract rather than assumed.
• A clean exit. A reminder of those duties on the way out, and notice to the customers and suppliers affected by the change.
• Named succession. Every security responsibility the leaver held passes to a named successor.

Scope runs wider than payroll. Contractors, supplier-provided staff and internal movers are all covered.

The control is preventive by design. Enforceable terms, prompt revocation and clean handovers exist to stop an ex-employee or role-changer misusing what they carried out the door. The control touches confidentiality through leaked secrets, integrity through tampering via lingering accounts, and availability through orphaned operational duties.

Enterprise due-diligence teams probe offboarding specifically, because it is where small firms most reliably fail. That makes it one of the cheaper controls to get right and one of the more valuable to evidence.

Which duties must survive after someone leaves, and how do you make them enforceable?

Confidentiality, intellectual-property and agreement-specific obligations must keep binding people after they leave, and the contract has to say so expressly. Write surviving clauses into employment terms and contractor agreements, have legal counsel confirm they are enforceable under UK law, and restate them at exit. Without that, the duty exists only as goodwill.

Confidentiality is the one duty that cannot be optional, because keeping it binding is the core of the control. Intellectual property follows, so source code and designs stay yours. Agreement-specific duties come last, such as data-return terms in a client contract.

The wording is laid down at hiring under A.6.2, terms and conditions of employment, and sharpened by the confidentiality agreements in A.6.6. Annex A 6.5 is where those terms get tested.

Our guidance for a 50-person regulated firm runs in this order:

1. Draft with legal input. Clauses must expressly continue after the engagement ends. An unenforceable clause discovered mid-dispute is worse than useless.
2. Cover every route in. Employment terms and contractor agreements both need the wording. For supplier staff, put the exit obligations in the supplier contract.
3. Confirm under UK law. Ask legal counsel to check enforceability instead of trusting a downloaded template.
4. Restate at exit. Remind the leaver of what still binds them during the exit conversation.

Early employees and long-standing contractors are where this usually fails. Trust-based arrangements with nothing in writing surface only when the salesperson who exported the pipeline joins a competitor. You then find your contracts do not forbid it.

The exposure is not only commercial. If personal data leaves with the person, the ICO may ask how you protected it, and a surviving clause is part of the answer.

What should happen on a leaver's last day under Annex A 6.5?

On the last day, or immediately for a hostile exit, disable every account including directory, SSO, VPN, directly provisioned SaaS tools and MFA tokens, then collect badges, keys, laptops, phones and storage media against the asset register. Finish with a short exit conversation and a signed leaver declaration, with devices wiped before reissue.

The NIST SP 800-53 Rev. 5 PS-4 Personnel Termination control is a useful external benchmark. It requires disabling system access within a defined period, revoking authenticators and credentials, conducting exit interviews and retrieving property. Annex A 6.5 leaves the window to you, so define it: same day, and at once when the departure is contentious.

Run every exit from one checklist. Small firms fail this control through inconsistency rather than ignorance, and the checklist is what makes the seventeenth exit match the third.

Run the day in this order:

1. Disable accounts. Directory, SSO, VPN, every directly provisioned SaaS tool and MFA tokens. The directly provisioned tools are the ones that get missed.
2. Recover assets. Badges, keys, laptop, phone and storage media, ticked off against the asset register entries in the leaver's name. Asset return is also tested under A.5.11, return of assets.
3. Wipe before reissue. No device goes to a new user until it has been wiped.
4. Hold the exit conversation. Restate the surviving obligations and capture a signed leaver declaration.
5. Record the timestamps. Note when each account stopped working, because that is what gets sampled later.

Two signatures, theirs and yours, turn "we told them" into evidence. A verbal reminder that nobody recorded will not survive a dispute or an audit question.

Mailboxes need a decision, not a default. Keeping the leaver's login live for the auto-reply creates an unowned, unmonitored account holding years of sensitive mail. Forward the address to a named colleague, delegate access to the manager if the mail must be read, and kill the login.

Before a sensitive departure, review recent activity for unusual data movement, such as large downloads or forwarding to personal email, while logs are fresh and your options are still open. Agree the scope with HR and legal first, because monitoring staff has employment and data protection implications.

How do you transfer security duties, not just equipment?

List every security duty the leaver held, such as backup checks, alert triage, supplier contacts and key custody, assign each to a named successor, and rotate any shared credentials, keys or third-party access they knew. Record the handover in writing, because a duty with no named owner stops being performed.

Duties evaporate because nobody wrote them down. The one person who ran the backups leaves, the duty leaves with them, and the missed check surfaces months later as an availability incident.

A laptop returned with no successor named for the leaver's duties is not a completed exit.

Start the duty list with these four categories:

• Backup checks. Who confirms backups ran and restores work?
• Alert triage. Who watches the alerts the leaver used to see?
• Supplier contacts. Who now holds the relationship and the escalation route?
• Key custody. Who holds the encryption keys, signing keys and admin secrets?

Small firms keep critical tasks alive with a light touch. A one-page handover note per leaver, naming each successor, is enough. Ask the leaver and their manager to draft it together, because the leaver knows which duties were never documented.

Rotation matters because the leaver still knows the secret after the account is gone. Shared admin passwords, API keys and supplier portal logins all need changing or reassigning. Customers and suppliers who dealt with the leaver also need to hear who their contact is now.

How do you manage a change of responsibility for internal role transfers and access changes?

A role change counts as leaving the old job and starting the new one. Strip the old role's access first, grant the new role's access on its own merits, and formally hand over duties. NCSC guidance expects a joiners, movers and leavers policy, and NIST PS-5 requires reviewing ongoing need at every transfer.

The NCSC Identity and Access Management Guidance asks for account management processes with a joiners, movers and leavers policy, so access can be revoked when no longer needed or changed for movers. NIST SP 800-53 Rev. 5 PS-5 Personnel Transfer supplies the test: review and confirm the ongoing operational need for current access whenever someone is reassigned.

A mover process needs four steps:

1. Trigger from HR. The role change in the HR record starts the review, not the employee's request for new access.
2. Strip first. List the old role's entitlements and remove them explicitly.
3. Grant on merit. Approve the new role's access on its own, rather than copying a colleague or layering it over the old.
4. Hand over duties. Old security duties pass to a named successor, exactly as they would for a leaver.

Privilege creep is the failure this prevents. Every internal transfer adds access and none removes it.

Five years of internal moves quietly build an access profile nobody would ever have approved.

Broad admin access is the legacy that lingers longest, so check it first. In a 50-person firm the review can be a five-minute ticket: the manager lists what the person had, IT removes what the new role does not need, and both sign off. The record of that removal is what you show when an auditor asks what happened to the old permissions.

How do auditors test ISO 27001 Annex A 6.5?

Auditors take the HR leaver list and reconcile it against the identity platform, tracing two leavers from HR leave date to the timestamp their accounts stopped working. They then sample one mover for accumulated access, one checklist for completion, and the contract clause that survives exit. Any account alive past its owner's exit is a finding.

Expect questions like these in the room:

• "Who left in the last six months? Pick two and walk me from their HR leave date to the timestamp their accounts stopped working."
• "Show me the clause in your contract that still binds someone after they've gone."
• "This person moved from support into engineering. What happened to their old permissions?"
• "Who does what your last leaver used to do, and where is that written down?"
• "What did the leaver sign on the way out?"

Have this evidence ready before the audit:

• Contract and agreement templates showing the surviving confidentiality and IP clauses, plus the legal review.
• Completed, dated and signed-off offboarding checklists for recent leavers.
• Directory disablement timestamps, with SSO and SaaS revocations lining up with leave dates.
• Asset-register entries confirming returned and wiped equipment.
• Signed leaver declarations and exit-interview notes.
• Handover documents naming successors, and records of credential rotation.

In our reading of certification-body practice, grading follows the pattern. Active accounts for departed staff, or contracts with no surviving-obligation clauses at all, are the absence-or-breakdown case and grade major. A single late revocation, an unsigned declaration or a thin handover note grades minor, though repeated minors can aggregate into a major.

The checklist sample tests completion, not existence. The auditor wants one that was filled in, dated and signed, not merely printed and filed.

An empty offboarding template is evidence against you, not for you.

How does GRC engineering automate joiners, movers and leavers?

The HR leave date triggers account disablement across the identity provider and connected SaaS on the day, with timestamps captured as they happen. A scheduled job flags orphan accounts, each exit spawns a tracked ticket, and role changes trigger a diff review. The reconciliation an auditor performs manually then runs continuously.

Four mechanisms do the work:

• HR-triggered deprovisioning. The leave date in the HR platform drives disablement across the identity provider and connected SaaS. Timestamps are captured as the accounts close.
• Orphan-account detection. A scheduled job compares active accounts with current HR records and flags survivors the day they appear. It catches the directly provisioned tools that automation missed.
• Checklist as workflow. Each exit spawns a ticket with tasks for HR, IT and the manager. Nothing closes until every step is done, and the closed ticket is the evidence.
• Mover diffs. A role change triggers an access review that lists old-role entitlements for explicit removal. Privilege accumulation stops structurally.

Run this way, offboarding becomes an event rather than a scramble. The disablement timestamp, the closed ticket and the access diff exist because the work happened, not because someone reconstructed them the week before the audit.

HR, IT and managers also stop assuming someone else did it, because the ticket names an owner for every step. A small team gains most, because nobody has spare hours to chase exits by hand.

We recommend building in a fixed order. Connect the HR feed to the identity provider first, because it delivers the timestamp auditors ask for before anything else. Add the orphan job next, then the ticket workflow and the mover diff.

Frequently asked questions