Annex A 6.5: Responsibilities After Termination Change Of Employment

Annex A 6.5 sits in the “people controls” domain of ISO/IEC 27001:2022 and it tends to fail for one simple reason: organizations treat offboarding as an HR task, while auditors test it as an access-control and evidence problem. A clean policy statement is not enough. You need an operational mechanism that starts at the moment a role changes or employment ends and reliably results in (1) access updates or revocation, (2) asset and information return, and (3) formal reminders of ongoing obligations like confidentiality.

This control is “medium severity” in practice because breakdowns often lead to outsized impact: a former employee account left active, a contractor retaining customer data, or privileged access persisting after a transfer. Auditors usually sample a handful of departures and transfers and ask you to prove each one was handled end-to-end. If you can’t produce consistent artifacts quickly, the finding writes itself.

This page gives requirement-level implementation guidance you can put into your ISMS immediately, including a step-by-step operating procedure, evidence pack, audit questions, and a practical execution plan. Control intent and high-level ISO framing are available from the standard’s overview and public Annex A summaries. ¹

Regulatory text

Provided excerpt (summary): “ISO/IEC 27001:2022 Annex A control 6.5 implementation expectation (Responsibilities After Termination Change Of Employment).” ¹

Operator interpretation (what you must do):
You must ensure information security responsibilities are defined and enforced when an individual’s employment terminates or their job role changes. In practice, that means:

• The organization communicates ongoing obligations (confidentiality, acceptable use, IP, return of information/assets).
• Access rights are removed or adjusted promptly based on the change event.
• The organization can demonstrate consistent execution through documented workflows and retained evidence suitable for sampling.

This is not limited to employees. Treat it as a “people lifecycle” control that covers workers, contractors, interns, and other third parties with access to your systems or data, because the risk is access persistence and knowledge retention, not payroll status.

Plain-English interpretation

Annex a 6.5: responsibilities after termination change of employment requirement is about closing the loop on people risk. When a person leaves or moves, you must:

1. stop inappropriate access,
2. get your stuff (devices, badges, keys, documents, secrets) back or invalidate it, and
3. remind them what they still can’t do after they’re gone.

Auditors don’t want a story. They want evidence for real instances: “Show me Jane’s offboarding. Show me Raj’s transfer from Support to Engineering. Show me the access changes and who approved them.”

Who it applies to

Entity scope

• Any organization implementing an ISO/IEC 27001:2022 ISMS, including service organizations. ²

Operational scope (who and what events)

Apply this control whenever there is a:

• Termination (voluntary, involuntary, end of contract)
• Role change (department transfer, promotion, lateral move)
• Access scope change (project change, privileged access granted/removed, secondment)

Cover all identities and access paths:

• Corporate identity (SSO/IdP), email, VPN, endpoint management
• Business applications (CRM, ticketing, finance, source control)
• Cloud consoles, production access, secrets vaults, API keys
• Physical access (badges, keys) and facilities
• Data access to regulated or customer data sets
• Shared accounts and emergency access paths

What you actually need to do (step-by-step)

Use this as a minimum operating procedure your teams can run repeatedly.

Step 1: Define the “mover/leaver” control objective and owners

Create a short control procedure that answers:

• Trigger: What systems record the authoritative event (HRIS, contractor management, procurement, staffing agency notice)?
• Owners: HR (event creation), Hiring Manager (asset confirmation), IT/Security (access changes), Facilities (physical access), Legal (post-employment terms if applicable).
• Evidence: Where artifacts live (ticketing system, HRIS attachments, IAM logs).

Assign a single control owner (often GRC or Security Operations) responsible for evidence completeness.

Step 2: Standardize role-change and termination workflows (don’t rely on email)

Build two templates in your ticketing system:

• Mover ticket: role changes, department changes, privilege adjustments
• Leaver ticket: termination, contract end

Each ticket should include required fields:

• Person identifier (name, unique ID)
• Effective date/time of change
• Manager
• Worker type (employee/contractor/third party)
• Systems to remove/modify
• Asset checklist (laptop, phone, badge, keys, tokens)
• Data handling attestation (return/secure deletion for local copies where applicable)
• Approvals and completion timestamps

Step 3: Implement access revocation and access change as a controlled process

For leavers, your default should be “revoke first, sort out exceptions second”:

• Disable SSO/IdP account
• Revoke MFA tokens and sessions
• Remove VPN access
• Disable email and forwarding rules per policy
• Remove from groups and privileged roles
• Rotate shared secrets the person could know (service account passwords are a special case; prefer eliminating shared credentials)

For movers, require:

• Manager approval for new access based on job role
• Removal of old access no longer needed (this is where least privilege fails)
• A check for privilege accumulation (especially for admins and developers)

Step 4: Handle assets and information return (including “soft” assets)

Tie asset recovery to an accountable party (manager or IT asset owner):

• Collect devices and accessories, confirm encryption and remote-wipe posture
• Recover badges/keys; deactivate credentials at Facilities
• Inventory and revoke any organization-issued tokens (hardware keys)
• Confirm return of paper records or physical media if used
• For contractors/third parties: confirm end-of-engagement access removal and return/destruction of organization data per contract terms

Step 5: Communicate ongoing responsibilities and record acknowledgment

At minimum, ensure the person receives (and you retain):

• A reminder of confidentiality obligations and restrictions on copying/retaining information
• Instructions for returning assets and deleting local copies where applicable
• A statement about continued applicability of policies or contractual clauses (confidentiality, IP, non-solicitation where used)

Common pattern:

• HR offboarding packet includes a short “security responsibilities after termination/role change” acknowledgment.
• For movers, include an updated acknowledgment of acceptable use and data handling for the new role if risk profile changes.

Step 6: Build recurring evidence capture and sampling readiness

Annex A controls get assessed through samples. Prepare for that by:

• Keeping all offboarding/mover tickets in a single queue or tag
• Exporting a monthly list of terminations and role changes from HRIS, then reconciling to closed tickets
• Recording exceptions with documented approval (for example, short-term email access for legal hold, handled as a managed exception)

Daydream (or any GRC system you already run) becomes useful here when it drives a repeatable evidence request cadence: you map Annex A 6.5 to the workflow, define what “good evidence” looks like, and collect it continuously instead of scrambling at audit time. ¹

Required evidence and artifacts to retain

Store evidence so an auditor can trace: HR event → ticket → access changes → asset return → acknowledgment.

Minimum evidence set (keep for both movers and leavers):

• Offboarding/role-change ticket with timestamps, owner, approvals, completion
• IAM/SSO logs showing account disabled or group membership changes
• List of systems/accounts removed or changed (embedded in ticket or attachment)
• Asset return checklist signed by IT/manager (or asset system status change)
• Facilities record of badge deactivation (if applicable)
• Copy of the post-employment responsibilities notice and acknowledgment (or HRIS record)

Nice-to-have (helps for privileged roles):

• Privileged access management logs (vault check-in, role removal)
• Evidence of key/secret rotation when shared secrets were exposed

Common exam/audit questions and hangups

Auditors and cert bodies tend to probe the same failure points:

1. “Show me the last few terminations and how access was removed.”
   Hangup: HR has records, IT has logs, but nothing ties them together.

2. “How do you handle role changes?”
   Hangup: access only gets added, not removed. Privilege creep becomes visible.

3. “How do you ensure contractors and third parties are covered?”
   Hangup: no authoritative source of contractor end dates; accounts linger.

4. “What happens in an involuntary termination?”
   Hangup: no rapid response path (HR/legal/security coordination) and unclear timing.

5. “What evidence do you retain?”
   Hangup: teams do the work but don’t retain artifacts; tickets are inconsistent.

Frequent implementation mistakes and how to avoid them

• Mistake: Treating offboarding as a checklist in a slide deck.
  Avoid it: make the ticket mandatory and the system of record.

• Mistake: Relying on managers to “tell IT” informally.
  Avoid it: HRIS-triggered ticket creation or a required HR step that auto-creates the task.

• Mistake: Missing non-SSO apps and “shadow” access paths.
  Avoid it: maintain an application access register mapped to provisioning/deprovisioning steps.

• Mistake: Ignoring movers.
  Avoid it: enforce “remove old access” as a required closure criterion.

• Mistake: No exception handling.
  Avoid it: document exceptions, approvals, and compensating controls (for example, legal hold).

Enforcement context and risk implications

ISO 27001 is a certification standard rather than a regulator with fines in the framework text itself. The practical risk is certification findings, customer trust erosion, and real security exposure from orphaned accounts or retained data. Your highest-risk scenarios are:

• Privileged users leaving (admins, engineers with production access)
• Contractors with unclear end dates
• Role changes into sensitive functions (finance, security, infrastructure)

Because no public enforcement sources were provided for this control in the supplied catalog, this page focuses on audit readiness and operational risk outcomes rather than citing enforcement actions. ²

Practical execution plan (30/60/90-day)

You asked for speed; treat this as an implementation sequence, not a promise about effort.

First 30 days (Immediate stabilization)

• Name the control owner and publish a one-page procedure for movers/leavers aligned to Annex A 6.5.
• Create standardized mover and leaver ticket templates with mandatory fields and approvals.
• Identify the authoritative trigger sources for employee and contractor changes (HRIS, procurement, staffing).
• Define the minimum access revocation steps for leavers (SSO, VPN, email, critical apps) and document them.

By 60 days (Operational hardening)

• Integrate HR events to ticket creation (automation if feasible; otherwise a required HR step with daily reconciliation).
• Build an application access register that lists each key system and the deprovisioning owner.
• Add a “post-employment/role change security responsibilities” acknowledgment to HR processes and centralize retention.
• Pilot sampling: pick recent mover/leaver events and test whether you can produce the full evidence chain quickly.

By 90 days (Audit-grade evidence and continuous control)

• Implement monthly reconciliation: HR events versus closed tickets, tracked exceptions.
• Expand to privileged access: ensure PAM/vault steps exist for high-risk roles and rotate shared secrets when needed.
• Establish metrics that are evidence-backed (for example, count of movers/leavers processed, count of exceptions) without inventing performance claims.
• Operationalize continuous evidence capture in your GRC workflow so Annex A 6.5 stays “always ready” for audits.

Frequently Asked Questions

Does Annex A 6.5 apply to contractors and other third parties?

Yes in practice, because the risk is continued access and retained information. Treat contractors, interns, and consultants as in-scope whenever they have system access or handle organization data. ³

What’s the minimum evidence an auditor will accept for a termination?

A dated record of the termination event, proof of access revocation/changes (IAM logs or admin records), and a completed offboarding record showing assets returned and obligations communicated. Put it all behind one ticket ID so it samples cleanly.

How do we handle role changes where someone needs access to both old and new systems temporarily?

Allow it only via a documented exception with an end date and manager approval, then track removal as a follow-up task. Auditors accept transitional access when it is controlled and time-bounded.

We use SSO. Is disabling the SSO account enough?

Often it covers many apps, but auditors will ask about non-SSO systems, local accounts, and privileged paths. Maintain an inventory of exceptions (apps not tied to SSO) and show deprovisioning steps for each.

What should the post-employment “responsibilities” notice actually say?

Keep it short: confidentiality continues, organization data must be returned or deleted as directed, and unauthorized use or disclosure is prohibited. Align the wording to your employment agreements and policies, and retain acknowledgment.

How can Daydream help with Annex A 6.5 operationalization?

Use Daydream to map Annex A 6.5 to your mover/leaver workflow, define required artifacts, and run recurring evidence collection so you always have a ready-to-sample pack. That reduces audit scramble and exposes workflow gaps early. ¹

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview

3. ISMS.online Annex A control index