A.6.5 Responsibilities after termination or change of employment

What A.6.5 ISO 27001 asks when someone leaves or changes role

A.6.5 asks you to prove that information security duties do not end on the last day of employment or on the day someone changes role. An auditor who samples a leaver or a mover will want to see that confidentiality, return of equipment and other obligations that still apply were defined, enforced and communicated to the person and to any other party concerned. In plain terms, the control is about the gap between what someone is still bound to do and what their account, access and paperwork still allow. That gap is where many incidents start: a contractor keeps a shared mailbox after an engagement ends, or an employee moving to a new team keeps the access that belonged to the old one. Offboarding and role-change checklists are the usual place where the gap is closed, so the auditor will read them as evidence rather than as policy.

The control sits beside several Annex A controls that an assessor will test together. A.5.11 Return of assets covers the hardware, data and credentials that leave with the person. A.5.18 Access rights covers the removal or adjustment of access when employment ends or the role changes. A.6.6 Confidentiality or non-disclosure agreements supplies the signed duties that must survive termination. A.6.5 is the procedural link that makes those three operate at the moment of change. Confirm with your certification body how it expects you to show that link, because some auditors sample one leaver across all four controls.

The control has a 2013 lineage. The correspondence table in ISO/IEC 27002:2022 Annex B traces A.6.5 to control A.7.3.1, Termination or change of employment responsibilities, from the 2013 edition. If you hold evidence from a 2013-based ISMS, reuse it, but check that it now maps to the attributes and purpose of the 2022 control. The wording here is explained in our own terms, not quoted. Read the standard itself through ISO or the IEC Webstore, and use the 27002 guidance as the detailed reference for what a good procedure contains.

Which leavers, movers and systems fall under A.6.5

A.6.5 applies to anyone whose security duties outlive their current access, which is wider than employees on payroll. The cards below separate the people, the systems and the records that define that scope, and flag the decisions that determine who owns each step.

Employees who leave or change role

Every employee is in scope on exit and on any move that changes what they can reach. A move between teams is often the riskier event, because access accumulates when no one removes the old entitlements. Check that HR triggers cover both resignation and internal transfer, and that the leaver's confidentiality and return-of-asset duties are restated at exit rather than assumed from the original contract.

Contractors, temporary staff and other parties

Contractors, agency staff and other third parties keep working access without appearing in the HR system, so their exit is easy to miss. Decide whether they run through the HR offboarding process or a supplier process, and record that decision in the scope statement. Ask whether the contract ends their duties on the same day their accounts are disabled, and whether confidentiality obligations survive the contract.

Identity directories and federated access

The central directory, and any identity provider that feeds it, defines who is still active. Deprovisioning should disable the source account first, then follow through to downstream applications. An automated connector such as the SCIM provider in authentik can push deletions and changes to target applications, but you still need to confirm which applications are connected and which were added by hand.

SaaS applications and shared accounts

Local accounts in SaaS tools, and shared logins used by teams, are the usual gap in offboarding. A departing person may still hold a password for a tool that is not federated, or know the credentials of a shared account. Inventory every application holding company data, mark which accounts are personal and which are shared, and set a rule for rotating shared credentials when someone with knowledge of them leaves.

Physical assets and removable media

Laptops, phones, access badges, tokens and removable media leave with people or stay in drawers. Scope them as the assets the leaver must return, which links A.6.5 to the return-of-assets control. Confirm that the asset register records who holds each item, so an auditor can compare the register against the offboarding checklist for a sample of leavers.

HR records and offboarding tickets

The HR record and the ticket that tracks each exit or transfer are the evidence an assessor samples. Scope them together: the HR system dates the event, and the ticket shows each access removal, asset return and reminder of continuing duties. Ask whether the ticketing tool keeps an audit trail of completed steps and who signed them off, because an undated checklist is hard to rely on.

How an assessor tests A.6.5 in an ISMS audit

This table sets out each step an assessor takes to test A.6.5, the evidence requested at each step, and the findings that most often lead to a nonconformity. Read it as a test plan: the organization should be able to produce the same records for a sample of leavers and movers before the auditor asks for them.

Test step	What the assessor checks	Evidence requested	Common finding
Define post-employment duties	Whether confidentiality and other duties that outlast employment are written into policy, employment terms or offboarding procedures	Policy or procedure text, template exit letter, contract clauses referencing post-employment duties	No defined post-employment duties, or duties exist only in people's heads
Sample leavers	Recent leavers drawn from HR records, checked against the duties and the offboarding steps taken	HR leaver list for the audit period, offboarding checklist per sampled person, dated sign-off	Checklist missing for some leavers or completed after the leave date
Confirm access removal	Whether accounts, tokens, shared credentials and privileged access were revoked on or near the leave date	Directory disable logs, application deprovisioning records, access review extracts for sampled leavers	Leavers whose access persisted in one or more systems
Sample movers	Employees who changed role, checked for removal of old access and approval of new access	Role change request, approver record, before and after access lists for sampled movers	Role changes with no documented review of retained access
Recover assets and credentials	Whether devices, keys and shared secrets were returned or reset when duties ended	Asset return records, device reassignment logs, secret rotation records	Returned devices not logged, or shared passwords left unchanged after departure
Check reminders and communication	Whether leavers were told in writing which duties continue and that the organization will enforce them	Exit letter or notice template, delivery record, acknowledgment signed by the leaver where practical	No evidence the leaver was informed of continuing duties
Test enforcement	Whether the organization acted on breaches of post-employment duties and how it records that action	Incident or legal records, decisions on enforcement, communication with former staff where relevant	No record of how a known post-employment breach was handled
Check interested party coverage	Whether contractors and third-party staff with access are covered by the same steps	Contractor end-date list, supplier offboarding notices, access removal records for third parties	Contractor access continuing after the engagement ended

How to implement A.6.5 step by step

This sequence turns A.6.5 from a policy statement into working offboarding and role-change routines, each with an owner and a record an assessor can sample. It runs from defining the duties that survive employment through to scheduled review.

Define surviving duties in policy and contract wording
Start by listing the information security duties that must outlast employment, such as confidentiality, return of equipment, and continued compliance with acceptable use. Legal and HR review the wording, then security adds it to the information security policy and the standard employment terms. Done means each duty appears in a written document that staff sign or acknowledge, and the list is linked to the related controls A.6.2 and A.6.6.
Map leaver and mover triggers from HR to IT
Identify every event that should start a security action: resignation, termination, contract end, transfer, promotion, and extended leave. Agree which HR system record creates each event and how it reaches IT and security. Done means a written trigger map exists, with a named source system and recipient for each event type, and the team can show a sample event travelling end to end.
Build offboarding and role-change checklists with owners
Write one checklist for leavers and one for movers. Each line names an owner, such as the line manager, IT administrator, facilities or the asset team, and the action required, for example disabling accounts, collecting devices and tokens, or removing old group memberships. Done means each checklist is approved, versioned, and stored where an auditor can retrieve it, and every item has a completion field.
Enforce access removal and asset return
Execute the checklist for each event. Remove or reduce access in the directory and connected applications, revoke sessions and tokens, and recover assets listed under A.5.11. Tools such as FreeIPA for directory accounts, authentik's SCIM provider for propagating deprovisioning to target applications, and GLPI for asset and ticket records can support this step, but you should confirm each platform's behavior in your own environment. Done means each leaver or mover has a closed ticket showing removals and returns, with timestamps.
Communicate duties to personnel and relevant third parties
Tell leavers and movers which duties continue after they go, such as keeping confidential information confidential, and give them a written reminder. Send the same notice to contractors and other third parties whose access ends or whose agreements carry post-termination obligations. Done means the notice is issued through a recorded channel, such as a ticket in Zammad or GLPI, and the acknowledgment or sent record is kept against the individual.
Review the process on a schedule
Set a review interval in the policy and test the process against a sample of recent leavers and movers. Check whether triggers arrived, checklists were complete, access was removed on time, and communications were recorded. Feed exceptions into corrective actions and update the trigger map, checklists, and policy wording. Done means the review record shows findings, owners, and changes, and it is ready for the internal audit and management review cycle.

Evidence that passes A.6.5 and how to keep it current

An auditor testing A.6.5 looks for proof that post-employment duties were defined, that people were told about them, and that exits and role changes were actually processed. The cards below cover the artifacts that carry that proof. Each one works best when it is tied to the HR event that triggered it, so a sample can be traced from the change to the response.

Defined post-employment duties document

This is the written statement of which security duties survive termination or a change of role, such as confidentiality, return of equipment, and continued restrictions on using system knowledge. It should be version-controlled, approved by someone accountable for HR and security, and reviewed when employment terms or the policy set change. Check that the document names the roles it applies to and that a leaver or mover can find the version in force on the date they left. An auditor will ask for the approved version and its revision history.

Signed confidentiality acknowledgments at exit

An exit acknowledgment signed on or before the last working day shows that the individual was told which duties continue. Keep the signed record linked to the employee identity and the termination date. Check whether the acknowledgment covers contractors and temporary staff, and whether the process still works when the person declines to sign or leaves without an exit interview. Missing signatures are a common finding, so track them as exceptions with a named owner.

Offboarding tickets with timestamps

A ticket created when HR records a leaver gives a single trail from the trigger to each revocation step. Each task should carry an owner, a due time, and a completion timestamp, so the sequence can be reconstructed. The useful test is whether the ticket opened after the HR event and closed after the last access was removed. Self-hosted helpdesk tools such as GLPI or Zammad can hold these tickets, but the organization must confirm that its chosen tool keeps timestamps and history that cannot be edited silently.

Access revocation logs

Logs from the directory, identity provider, and each target application show when access was removed and by which process. Where provisioning is automated, the provider's own event log is the primary record, and an auditor may ask how a manual revocation is captured. Authentik's SCIM provider deprovisions users from target applications when they lose access, so its sync and deletion events are candidate evidence. Confirm which applications sit outside the automated path, because those gaps are where leavers keep access.

Asset return records

A record of each device, badge, token, and licence returned, with the date and the person who received it, closes the loop between the HR event and the asset register. Link the return to the inventory entry so the asset shows as reassigned or retired. Ask how returns are handled for remote staff and for equipment that was never issued through the standard process. The gaps usually sit in shared devices and in tokens that do not appear in the inventory at all.

Role-change reviews

When someone moves to a new role, their old access and responsibilities should be reviewed and removed where they no longer fit. A role-change review records the old entitlements, the decision on each, and the approver. This is the artifact most often missing, because movers keep access that accumulates over time. Sample a recent set of internal moves each cycle and check that the review closed before the new access was granted.

What meeting A.6.5 costs in money and effort

This table breaks down the cost components of meeting A.6.5, who is paid for each, whether it is one-time or recurring, and what drives it up or down. No figures are given because none are published in the supplied research, so use the rows to structure a quote request and compare written scopes.

Cost component	Who is paid or who carries it	One-time or recurring	What drives the cost
Drafting exit and role-change procedure and template	Internal HR and security staff, or an outside consultant	One-time, with periodic review	Number of populations (leavers, movers, contractors) and whether templates already exist
Legal review of confidentiality and exit wording	Internal legal or an external law firm	One-time, repeated on material change	Jurisdictions where staff work and how often contract templates change
Engineering to link HR events to access removal	Internal platform team or an implementation partner	One-time build, then recurring maintenance	Number of systems, depth of integration with the HR source of truth, and identity tooling in use
Ticketing workflow for offboarding and role changes	Internal service desk admins or a partner configuring the tool	One-time setup, recurring administration	Volume of leavers and movers, number of approval steps and checklist items per task
Evidence collection for each leaver and mover	HR, IT and line managers as part of their normal work	Recurring, per event	Headcount turnover rate, number of contractors, and how much evidence is captured automatically
Internal audit sampling and follow-up	Internal audit or compliance team	Recurring, per audit cycle	Sample size set by the auditor's approach, number of exceptions found, and locations in scope
Certification body audit time	The certification body, billed per its written quote	Recurring, at each audit within the three-year cycle	Size and complexity of the ISMS scope and number of sites or systems sampled
Reminder of confidentiality duties after exit	Usually low effort, covered by HR communications	Recurring, at each departure	Whether exit forms and acknowledgments are standardized and tracked
Ways to reduce spend	Organization and any implementation partner	Ongoing	Automate HR-to-access triggers, reuse one exit checklist across roles, and fix the scope of systems early

Which open-source tools support A.6.5 evidence

authentik is a self-hosted identity provider released under the MIT license. Its SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour, and deprovisions users from the target when they lose access to the application. For A.6.5, this is the mechanism that can remove a leaver's access across connected applications, and the sync behavior is the part an assessor will want to see described and tested.

Deprovisioning events: Sync logs and task records can show when a user lost access to a given application, which supports the timing question in A.6.5.
Group-based removal: Changes to group membership can drive application access changes, so role changes can be traced to a group update rather than an ad hoc edit.
Hourly full sync: The stated full sync interval is a control property you can cite, but you should confirm how it behaves for your target applications.
Applications without SCIM: Targets that do not support SCIM still need a documented manual removal step, which the tool does not cover.
Retained evidence: Confirm with your deployment how long event and sync records are kept and where they are exported.

Before relying on this, check which of your applications accept SCIM provisioning, test a leaver case end to end, and keep the test output as evidence.

Where A.6.5 programs usually fall short

Most A.6.5 failures are not missing policies. They are gaps between the policy and the systems and people that actually end access, change privileges and collect acknowledgments. The cards below cover the gaps assessors most often find and the fix for each.

Contractor duties left unwritten

Contractors, temporary staff and outsourced operators often hold privileged access but sit outside the employment contract template. Their post-engagement security duties, such as confidentiality and return of equipment, may appear nowhere in writing. Check that the contractor agreement or statement of work states which duties survive the end of the engagement, and that the same duties are triggered when the engagement ends early.

Access left active after exit

Accounts remain enabled in directories, SaaS applications and admin consoles after a person leaves, often because each system is deprovisioned by hand. Automated deprovisioning from a central identity source closes most of this gap. For example, an identity provider that pushes deletions to downstream applications over SCIM 2.0 removes a leaver from those applications without waiting for a ticket. Test a sample of recent leavers against every system they used.

Old privileges kept after a role change

When someone moves teams, new access is granted but previous group memberships and elevated rights are rarely removed. The result is accumulated privilege that no one approved. Require a role-change ticket that lists access to add and access to remove, and review group membership for movers against the new role at the end of the transition window.

No signed acknowledgment at exit

Many organizations rely on the original employment contract for confidentiality after departure but never ask the leaver to confirm their continuing duties. An exit acknowledgment, signed or accepted electronically, records that the person understands which obligations continue, returns assets and confirms no data is retained. Keep the signed record with the offboarding ticket so an auditor can sample it.

HR and IT on different triggers

HR records the end date in its system, while IT waits for a manager to raise a request, so access ends days late or not at all. Agree on one authoritative trigger, such as the HR status change, that opens an offboarding or role-change ticket automatically. Confirm that both teams can show the same timestamp for each leaver in their records.

Questions buyers ask about A.6.5 effort and outside help

What drives the cost of meeting A.6.5 for a small organization?

The cost depends mostly on how many systems grant access, how many people join, move and leave each year, and how much of the offboarding and role-change process is still manual. Costs fall into three buckets: internal staff time for HR, IT and the control owner to define the duties and procedures; tooling, which may be open-source software you host yourself or commercial software you license; and external help, if you hire it. Ask any partner for a quote built from a written scope that lists the systems in scope, the joiner, mover and leaver workflows, and the evidence to be produced. Cost is partly one-time (defining procedures, configuring integrations, writing the duties into contracts) and partly recurring (reviewing the leaver log, testing deprovisioning and reviewing the procedure each year).

How long does it take to get A.6.5 ready for an audit?

Readiness time depends on how mature your joiner, mover and leaver process already is, how many systems need deprovisioning steps, and how quickly HR and IT can agree on who owns each step. ISO/IEC 27001 does not set a duration for any control, so no fixed timeline applies. A useful way to plan is to split the work into four parts: list the post-employment duties in your policy and contracts, map each duty to a system or manual step, run a few real leaver and mover cases end to end, and keep the records. Confirm timing with your certification body and your own environment before you commit to a date.

What does the work need from HR and IT?

A.6.5 is shared work, and it fails when HR and IT each assume the other owns the handover. HR typically owns the trigger: the termination notice, the role-change approval, the date the change takes effect, and the signed reminder of continuing confidentiality duties. IT owns the technical steps: disabling accounts, removing group memberships, revoking tokens, recovering assets and reassigning access for a new role. Both teams need a shared record of who was told what and when. Agree on the trigger event, the service-level expectation for each step (set internally, not an external standard), and who signs off that the leaver has been fully removed.

Can a small team run A.6.5 without outside help?

Yes, a small team can usually run A.6.5 itself if one person owns the control, the leaver checklist is short and written down, and the systems that grant access are few enough to check by hand. The harder part is consistency: a checklist that is followed only when someone remembers it will not produce evidence an auditor accepts. Small teams often succeed by using a ticket queue for every leaver and mover, so each case leaves a record. Outside help becomes more useful as the number of systems, sites or contractors grows, or when nobody has time to test the process. Ask any provider to confirm exactly which steps it would perform and which stay with your staff.

When does an implementation partner add value for A.6.5?

An implementation partner adds the most value when the leaver and mover process touches many systems that need integration, such as a directory, identity provider, helpdesk and application estate, and when the work must be documented and tested before an audit. DeployOpen plans, implements and integrates self-hosted open-source platforms inside your own infrastructure, and prepares the systems and evidence for a compliance assessment. It does not define your policy on your behalf as a certifying body would, does not decide whether your controls are sufficient, and does not issue an audit report or certificate. Only an independent certification body can do that. Most engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.

How does an auditor sample leavers to test A.6.5?

An auditor usually starts from a population: a list of everyone who left or changed role in the audit period, taken from HR records or the directory. They select a sample from that list, then check each case. For each sampled person, expect requests for the termination or change notice, the date access was removed in each relevant system, evidence that assets were returned, confirmation that confidentiality duties were communicated, and any exceptions with their approval. Auditors also check whether the population is complete, so keep HR and directory records consistent. Ask your certification body how it expects samples to be drawn and what sample size it uses, since those details vary by auditor.

Which open-source tools can produce A.6.5 evidence?

Tools help most when they record the leaver action and its timestamp automatically. For example, authentik's SCIM provider can push user and group creations, changes and deletions to target applications over SCIM 2.0 and deprovision users when they lose access, which gives a directory-level trail. FreeIPA stores users and groups in a central directory with delegated administration, so you can show who removed access and when. GLPI's Assistance module can track each leaver and mover as a ticket, with plannings and statistics. Zammad can hold the request thread between HR and IT. Confirm each product's capabilities in your own environment before relying on it, since a tool does not satisfy a control by itself.

How DeployOpen prepares A.6.5 systems and evidence

DeployOpen's part in A.6.5 starts with a written scope that names the systems, roles and offboarding and role-change events to be covered before any work begins. In practice that means agreeing which identity source is the leaver's starting point, which downstream applications must lose access when an account is disabled, which helpdesk queue receives offboarding and transfer tickets, and who in the organization approves each step. The organization keeps ownership of the policy that defines post-employment duties, including confidentiality expectations, return of assets and the handling of knowledge held by departing staff. DeployOpen prepares the systems that make those duties enforceable and the evidence that shows they were carried out. DeployOpen does not issue audit reports or certificates. Independent auditors and certification bodies do that work, and the organization should confirm the scope and deliverables in the written agreement before work starts.

Implementation typically runs inside the client's own cloud accounts, data center or air-gapped network. Where identity is federated, the authentik SCIM provider can push user and group creations, changes and deletions to target applications over SCIM 2.0, run a full sync every hour, and deprovision users from the target when they lose access. Where the directory is held in FreeIPA on 389 Directory Server, the team configures centralized access control and delegated administration so that the people who can disable accounts are defined and logged. GLPI's Assistance module, or Zammad for customer-facing queues, can hold a templated offboarding or role-change ticket that links each revoked permission to a named approver. Whether a given platform supports a specific deprovisioning behavior should be confirmed against the current documentation and tested in the client's environment before it is relied on.

The evidence an assessor will sample is mostly records of events: the offboarding ticket, the timestamp of account disablement, the list of applications the SCIM sync removed the user from, and the confidentiality reminder sent at exit. DeployOpen can configure these records to be retained and exportable, and can document the procedure so the organization can reproduce it. Ask the implementation partner to state in writing which evidence artifacts will be produced, where they are stored, how long they are kept and who can read them. Also agree on who checks the procedure on a recurring basis, because an offboarding process that works once but is not reviewed will not hold up to sampling. Any ongoing testing or upgrade work is a separate retainer that should be scoped and priced on its own terms.