A.5.11 Return of assets: requirements and evidence

What A.5.11 return of assets requires in ISO 27001

A.5.11 Return of assets requires the organization to make sure that personnel and other interested parties hand back every organizational asset in their possession when their employment, contract or agreement changes or ends. For a compliance lead or engineer, that means being able to show, from records rather than memory, that laptops, phones, removable media, access tokens and business data held on personal devices were collected or removed on the day someone left or moved roles. The control carries forward control A.8.1.4 Return of assets from the 2013 edition of the standard, so organizations moving from that edition should confirm their existing procedure and evidence still map cleanly to the 2022 wording of the Annex A control. The risk is simple to state and easy to underestimate. A departing employee, a contractor whose statement of work has ended or a temporary worker can leave with a company laptop, a USB drive holding customer exports, a copy of a source code repository on a personal laptop or a mailbox synced to a personal phone. Assets are rarely in one place. Hardware sits in an asset register that may be out of date, licenses and cloud accounts sit in other systems, and information on personal devices is invisible to central inventory unless someone deliberately looks for it. Contractors and suppliers' staff are often missed entirely because they never appeared in the HR system that drives offboarding.

The practical question to settle is which system is the source of truth for each asset class, and how a leaver event reaches every one of them. In a self-hosted setup, GLPI's Assets module can hold computers, peripherals and other equipment with an assigned user, and Wazuh's Syscollector inventory can confirm which endpoints are still reporting after a departure. authentik's SCIM provider can deprovision a user from connected applications when access is removed, and FreeIPA can disable the identity centrally. Each of these covers part of the picture. None of them tracks a physical laptop that was never enrolled, or business files saved to a personal device, so the return step still needs a signed checklist, a recorded handover and a rule for personal-device data. Confirm the exact capabilities of your chosen tools against their current documentation before you rely on them as evidence.

Which assets, people and agreements fall under return of assets

Scoping decides how much work return of assets becomes. Each choice below sets who must hand back what, and when, so the leaver process can be tested against a defined population. Organizations should settle these decisions in writing before they design the checklist.

Employees and their exit trigger

Permanent staff are the core population, and the trigger is the end of employment. Confirm whether notice periods, internal transfers and role changes also count as triggers, since a mover may still hold equipment or access meant for the previous role. Auditors usually sample recent leavers and compare their return records with the asset register, so the trigger must start a ticket automatically rather than rely on a manager remembering. Ask HR which events reach IT and how quickly.

Contractors and temporary staff

Contractors and temporary staff often hold laptops, tokens and accounts but sit outside the HR system. Their end date lives in a contract or agency feed, so the scoping decision is whether those sources feed the leaver workflow. Where a third party employs them, the return duty usually belongs in the supplier agreement under A.5.20. Confirm which agency or supplier notifies you and how returns are evidenced.

Other interested parties

Consultants, auditors, board members, visiting researchers and partner staff may hold organizational information without being employees. Decide which of these groups receive equipment or accounts, and treat each group as a defined population with its own trigger. A common gap is a shared guest account or a partner's copy of a document that nobody tracks after the engagement closes. Record who owns the relationship and who confirms closure.

Laptops, phones and removable media

Physical hardware is the easiest asset to count and the most often lost. Scope should list each device class, including laptops, mobile phones, tablets, USB drives, external disks and printed records held in secure storage. Link each item to its owner in the inventory so that a return can be reconciled with a record. Ask whether removable media is issued, approved or simply permitted, because the answer decides whether it is tracked at all.

Software licenses, tokens and credentials

Licenses, hardware security tokens, certificates and API keys are assets that leave with the person unless revoked. Scope should treat a returned token and a disabled account as separate actions, because a token can still work after an account is closed if it is registered elsewhere. Licenses assigned to a named user need reassignment or removal. Confirm the owner of each class and the evidence that each was withdrawn.

Information on personal equipment

This is the hardest scope item. Organizational information may sit on personal phones, home computers, personal cloud storage or messaging apps, often under bring-your-own-device or informal practice. Decide whether the policy covers such copies, how the person certifies deletion, and which systems can confirm removal, such as mobile device management or managed application containers. Where an organization cannot verify deletion, document the residual risk and the compensating step, such as remote wipe of managed apps.

Triggers that connect joiners, movers and leavers

Return of assets only works when it shares triggers with identity and access handling. Map which events disable accounts, collect devices and reassign licenses, and decide whether a mover must return items for the old role before receiving new ones. Each added trigger increases the number of workflows to run and evidence to keep, so scope fewer, reliable triggers first. Check that the HR feed, identity provider and asset register agree on the same leaver date.

How an assessor tests return of assets

This table sets out the steps an auditor typically takes to test A.5.11, what each step looks at, and the evidence the organization should have ready. Read it as a preparation checklist: each row is a test an assessor may run, and the findings column shows where organizations most often fall short. The main takeaway is that an assessor compares the offboarding record against what actually left the building and when access was revoked.

Test step	What the assessor checks	Evidence requested	Common finding
Review the offboarding procedure	Whether a documented procedure covers every leaver, contract end and third-party exit, and names who recovers each asset type	Current offboarding procedure, checklist template, approval history and version dates	Procedure exists but covers employees only, leaving contractors and suppliers out
Sample recent leavers	A sample of people who left or changed role recently, traced from HR termination to asset return	HR termination records, signed return checklists, dates of return compared with exit dates	Return checklist missing or unsigned for one or more sampled leavers
Compare returns with asset records	Whether the devices, media and licenses recorded against each leaver were actually returned or accounted for	Asset register extract for sampled users, return receipts, write-off or reassignment records	Assets assigned to leavers in the register with no return or disposal entry
Check device and account revocation timing	Whether logical access and devices were disabled or wiped in step with the exit, not weeks later	Directory disable timestamps, MDM or endpoint wipe logs, VPN and SaaS revocation records	Accounts still active or devices still enrolled after the exit date
Review personal device and personal account handling	Whether organizational information held on personally owned devices or personal cloud accounts was identified and removed	Bring-your-own-device policy, MDM enrollment records, written attestations from leavers, removal logs	No check for personal devices or personal storage, and no attestation requested at exit
Check contractor and third-party returns	Whether assets and information held by contractors, suppliers and other interested parties were returned when agreements ended	Contract end notices, supplier exit confirmations, access revocation tickets for external users	Contract closed in procurement but external accounts and laptops never tracked back
Test a change of role	Whether assets no longer needed after a transfer were returned, not just after a full exit	Mover checklist, reassignment tickets, register updates showing the new holder	Old equipment stays with the previous role holder and the register is not updated
Look for unrecorded assets	Whether assets in use can be traced back to an inventory entry, which shows the return process cannot close gaps the register never captured	Discovery scan results, endpoint inventory compared with asset register, reconciliation notes	Devices or media found in use that have no register entry and no owner

Implementing return of assets step by step

This sequence turns A.5.11 from a policy statement into a repeatable exit process. Each step produces a record an assessor can sample, from the list of covered assets and parties to a tested, dated leaver checklist.

Define covered assets and parties
Start by agreeing which assets and which parties fall under the control. Assets include laptops, phones, removable media, access tokens, badges, printed records and information held on personal devices. Parties include employees, contractors, temporary staff, interns and any other interested party with a contract or agreement that grants them organizational assets. Information security, HR, IT and legal should sign off the list together. The output is a short written scope statement, approved by an accountable owner, that names each asset class and each party type and states where personal equipment is in or out of scope.
Link the asset inventory to exit
Connect the inventory required by A.5.9 to the exit process so that every asset a leaver could hold is traceable to a named owner and a record. Inventory tools such as GLPI's Assets module can hold computers, peripherals, phones and other equipment, with entries created manually or pushed by the GLPI Agent. Wazuh's Syscollector can add endpoint hardware, software and user data to the same picture. The output is a reconciliation view that lists which assets are assigned to each person, so that an exit checklist can be generated from it and an auditor can compare it with the inventory.
Connect access removal to the exit process
Tie the return of assets to access removal under A.5.18 and identity management under A.5.16, so that account changes and physical returns happen as one event. In a directory such as FreeIPA, disabling or removing a user is recorded centrally. Where authentik's SCIM provider pushes user deletions or access removals to target applications, the removal propagates on its scheduled sync, which the team should confirm for each application. The output is a documented sequence in which the identity change is logged, the access record shows the date it was removed, and the person cannot reach systems after handover without a separate approved process.
Write the return procedure with owners and deadlines
Write a procedure that states who initiates the exit, who collects each asset class, who confirms receipt, and what happens to items that are not returned. Assign a named owner for each step, usually HR for notification, the line manager for coordination, IT for collection and wiping, and information security for escalation of missing items. Set deadlines in the procedure based on the organization's own policy, because no standard fixes a number of days. The output is an approved, versioned procedure that a reviewer can find and follow, with the owners and deadlines written into it rather than left to memory.
Build a checklist for each leaver
Create a checklist template that is completed for every leaver or ended contract. It should list each asset class from the scope, the inventory reference, the return date, the receiving person, the condition or wipe status, and the access removal reference. Include a line for information held on personal equipment, with confirmation that it was deleted or transferred under supervision. Contract ends for third parties need the same checklist with the contract reference. The output is a completed, signed record per person, stored where HR and IT can both retrieve it, which gives an auditor a complete trail for each sampled exit.
Run a test exit and record it
Before relying on the process, run a test exit with a volunteer or a non-production account and walk through every step, including collection, wiping, access removal and checklist sign-off. Record what failed, such as an asset missing from the inventory or a delayed access removal, and fix the procedure or tooling. Repeat the test after significant changes to the inventory, identity or HR systems. The output is a dated test record with findings, corrective actions and an owner for each action, which shows the control works in practice rather than only on paper.
Review exit records on a schedule
Set a recurring review in which a sample of completed leaver checklists is compared with the inventory, the identity records and the HR notifications. Look for assets assigned to people who have left, checklists without signatures and access removals that happened after the stated date. Feed exceptions into the incident or corrective action process. The output is a dated review record with the sample, the findings and the follow-up actions. Ask any implementation partner or auditor to confirm the sampling approach and retention period before the first review.

Evidence that passes a return of assets audit

An assessor testing A.5.11 looks for a chain of records that starts with a documented offboarding procedure and ends with proof that assets and access were actually recovered. Each artifact below covers one link in that chain, and the set only holds up if it is refreshed between audits rather than rebuilt before one.

Written offboarding procedure

This is the document that defines what must come back, from whom, by when, and who confirms it. It should cover employees, contractors and other interested parties, and list asset types such as laptops, phones, badges, tokens, removable media and printed records. Check that the owner, review date and version are recorded, and that the procedure matches what the HR and IT teams actually do. An auditor will compare the steps against a recent leaver's file.

Signed return and exit checklists

A completed checklist per leaver or contract end shows each asset item, its serial or identifier, the date it was returned, and the name of the person who received it. Blank or unsigned lines are the most common gap auditors find. Keep checklists in the same system as HR records so a sample can be pulled by person or by date. Note any asset the person did not return and the follow-up taken.

Asset register status changes

The asset inventory should show each returned device moving from assigned to in stock, retired or pending wipe, with a timestamp and the actor who made the change. GLPI's Assets module can hold these records, with the GLPI Agent feeding device data automatically. Confirm that a returned laptop still appears in the register until its status changes, so an auditor can trace the device from the leaver's record to its current state.

Timestamped account disablement records

Returned hardware is only part of the picture. Records showing when directory accounts, application logins and SCIM-provisioned access were removed prove that access ended when employment or the contract ended. authentik's SCIM provider can push deletions to target applications and deprovision users, so keep its event logs alongside the HR end date. Compare the two timestamps for every sampled leaver and explain any gap.

Endpoint inventory evidence after return

Once a device is back, the endpoint should stop reporting under the leaver's name and show its current owner or status. Wazuh's Syscollector inventory records users, groups, installed software and services on each endpoint, which helps confirm that a returned machine was reconnected, reimaged or left offline as recorded. Set a check that flags devices reporting under inactive users after the return date.

Wipe and retrieval certificates

Information held on personal equipment or removable media needs its own proof. Keep a retrieval confirmation for files returned from personal devices, and a wipe certificate or vendor log for any device that held organizational data and was not returned. The certificate should name the device, method, operator and date. Ask the assessor which record format they accept before the audit, because wording and detail vary between assessors.

How self-hosted tools support asset return evidence

GLPI's Assets module is the place to record who holds each organization asset and what state it is in. Its native inventory, fed by the GLPI Agent, can enter computers, monitors, software, network equipment, peripherals and phones automatically, while the rest can be entered by hand. For A.5.11, the value is the status history: an assessor can ask when a laptop was assigned, when it was marked as returned and whether the record matches the physical handover. The register proves that the organization recorded the return. It does not prove the device was physically handed back, and it only reflects what someone updated or what the agent reported.

Assignment history: Records the user linked to each asset and the dates of changes, which supports sampling leavers.
Status transitions: Shows whether a device moved to a stock or retired state after the holder left.
Manual entries: Phones, media and personal-device notes often need hand entry, so their accuracy depends on the process.
Agent coverage: Automatic records only cover machines where the agent is installed and reporting.
Reconciliation: Compare register entries against the endpoint inventory and the leaver list each cycle.

Confirm with your team which asset classes GLPI must cover, who owns each status change and whether the module's fields match your return procedure.

What return of assets costs to meet

This table breaks down the cost components of meeting A.5.11 Return of assets, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Read it to scope a quote, since most of the spend sits in integration effort and recurring procedure upkeep rather than in software licenses.

Cost component	One-time or recurring	Who is paid or who carries the work	What drives the cost and how to reduce it
Tooling and licenses	Recurring if commercial, none for the open-source core	Software vendor for commercial tools, or internal staff for hosting open-source platforms	GLPI (GPL-3.0-or-later), Wazuh (GPL-2.0-only), authentik (MIT) and FreeIPA (GPL-3.0-or-later) carry no license fee, but hosting and support staff still cost money. Confirm each license term with the project before reuse.
Integration and automation engineering	One-time, with later change work	Internal platform team or an implementation partner under a written, fixed scope	Connecting HR, identity and asset records so offboarding triggers removal is the largest one-time item. Reduce it by automating joiner, mover and leaver events from one authoritative source.
Procedure and checklist upkeep	Recurring	Internal HR, IT and security owners	Return steps change when staff, devices or equipment types change. Keep one owned checklist, review it on a set schedule and tie each revision to a change record.
Asset record accuracy and reconciliation	Recurring	IT operations and asset owners	Reconciling GLPI or Wazuh inventory against the devices issued to leavers takes time each cycle. Reduce it by having agents report automatically and by recording personal-device and media holdings where they exist.
Independent review	Periodic, usually one-time per cycle	External reviewer or internal audit function outside the team being reviewed	Scope and sample size set how much evidence the reviewer pulls. Ask for a scope statement and a sample plan in writing before the review starts.
Auditor sampling effort	Recurring at each certification audit	Certification body for the audit, internal staff for evidence retrieval	Auditors typically sample leavers and check return records against asset inventories. Keep returns, exceptions and acknowledgements retrievable by person and date so sampling does not turn into a manual search. Certification body fees are set by each body and should be quoted separately.

Who owns return of assets: your team, a partner and the auditor

A.5.11 is an organizational control, so the organization owns the requirement, the asset records and the proof that devices and information came back. An implementation partner can build the systems and evidence that make that proof easy to produce, but the conclusion on whether the control works belongs to an independent auditor or certification body.

Your team owns the control

Your organization decides which assets count, who must return them, and what happens when someone refuses or cannot return a device. Those decisions sit in your offboarding procedure and in the named owners recorded for each asset. A partner can draft the procedure, but your leadership must approve it, staff must follow it, and your records must show it operates. Check that a named business owner signs off the asset return rules and that HR, IT and line managers each know their step.

Partners can integrate the asset register

An implementation partner can connect the asset inventory to the systems that record what each person holds, such as GLPI for hardware and software assets. Integration work covers agent deployment, asset ownership fields, and reports that list assets still assigned to leavers. The integration is usually a one-time build with later maintenance. Ask who keeps the register accurate after handover and how the partner tests that a test asset appears correctly.

Offboarding automation and its limits

Identity platforms can disable accounts and push deprovisioning to connected applications, which covers access rights but not physical devices. authentik's SCIM provider can remove users from target applications when they lose access. A partner can wire that into the leaver workflow. Automation does not collect laptops, badges or paper records, so a manual checklist must still cover those items. Confirm which assets your automation touches and which still need a human sign-off.

Endpoint evidence from inventory tools

Returned laptops should disappear from the user's assigned list and reappear in stock or in a wipe queue. Wazuh's Syscollector module reports hardware, installed software, users and groups from each endpoint, which helps confirm that a returned machine no longer shows the leaver's accounts. Tell your partner which inventory fields prove return and set a rule for devices that go offline. Partners can build the report, but your team must review exceptions.

Evidence packs for the auditor

A partner can assemble a sample pack showing, for each leaver in the period, the offboarding ticket, the asset return record, and the access removal entry. This is preparation work, usually one-time setup plus recurring collection. The auditor chooses which leavers to sample and tests the records independently. Ask the partner to label the pack as prepared material so that no one mistakes it for an audit conclusion.

Where auditor independence stops

A partner that prepares your systems and evidence cannot also test them and report a result. Certification bodies follow ISO/IEC 17021-1, which requires them to remain impartial. Only accredited certification bodies issue ISO/IEC 27001 certificates, and a partner's readiness review does not substitute for their audit. Before engaging a partner, confirm that your certification body accepts their work as preparation only and that the same firm will not also perform the certification audit.

Questions buyers ask about A.5.11 return of assets

How much effort does return of assets take to run under ISO 27001?

Most of the effort is recurring routine rather than a one-time project. The work is a documented offboarding and role-change process, a list of what each person holds, and records showing that items came back. Effort rises with headcount, device count, contractor turnover and how many systems hold company information outside managed devices. Ask any implementation partner to break its quote into a one-time setup part (process design, checklist, tool configuration) and a recurring part (running each leaver and mover case, periodic checks). Your own staff time for HR and IT sign-off is a cost that a quote will not show, so estimate it from your own leaver volume.

Can a small team run return of assets in-house?

Yes, provided the team has a clear owner for the process and a single record of who holds what. A small organization can usually run the control with a checklist, an asset register that lists devices and accounts by person, and a sign-off step that HR or the manager completes before access is closed. The harder part is discipline: every leaver must go through the same steps, including contractors and people who worked on personal equipment. External help is most useful when the team has no one with time to design the process or when an auditor's sampling will look at records the team has not kept consistently.

How long does preparing return of assets take?

The honest answer depends on how mature your offboarding already is. If you already keep an asset inventory and have a leaver checklist, preparation is mostly documenting and testing what exists. If not, you need to build the inventory first, because the return process cannot be checked without a list of what should come back. Ask any provider for a written timeline tied to the agreed scope, and ask which dependencies it assumes, such as access to your HR system, your device management tool or your inventory data. No duration is given here because none has been researched for this control.

What does return of assets need from HR and IT?

Return of assets works only when HR and IT share one trigger and one record. HR should raise the event when employment, a contract or an agreement changes or ends, and should confirm the date and reason. IT should hold the list of devices, media, accounts and information assigned to that person and record what was received. Both teams should agree who closes the case and where the evidence is kept. Ask your provider how the workflow connects to your HR system and whether the process can cover people who never appear in HR records, such as contractors and partner staff.

How are contractors and other third parties handled for return of assets?

The control covers personnel and other interested parties, as appropriate, so contractors, consultants and some supplier staff fall within its scope when they hold your assets. The practical step is to record their assets when access is granted, not when they leave. Contract terms should state what must be returned and when, and your offboarding checklist should apply to them. Contractors often hold access through a sponsoring manager or an agency, so confirm who owns the end-of-contract step. Supplier obligations are also addressed by the supplier relationship controls, so check those clauses alongside this one.

How are personal devices and information on personal equipment covered?

Information held on personal equipment is an asset in scope, so the process must find it and remove it. Start by listing where company information is allowed to sit, including personal phones, home computers, personal cloud accounts and removable media. Then require each leaver or changing role to confirm, in writing, what they hold and to return or delete it, with IT checking where it can. Where technical controls cannot reach a personal device, the evidence is the signed confirmation plus the removal of account access. Decide your policy on personal devices before you design the check, because it determines what counts as a return.

Which open-source tools can produce evidence for return of assets?

Several self-hosted tools can supply parts of the evidence, and none replaces the process itself. GLPI keeps an asset register of computers, peripherals, phones and other equipment, entered manually or pushed by its agent, which gives you the list to check against. Wazuh collects inventory of hardware, software, users and groups from endpoints, so you can compare what a leaver's device still reports against what was issued. authentik can deprovision users from connected applications through its SCIM provider, which removes access when an identity is disabled. FreeIPA stores users and groups centrally, so disabling an account there is recorded in one place. Confirm each tool's fit with your environment before you rely on it as evidence.

What evidence will an assessor ask for under A.5.11?

An assessor will normally sample leavers and movers and ask for the record of what each person held and what came back. Expect to show the asset list for the sampled person, the offboarding case with dates, the sign-off by the responsible owner, and any confirmation covering personal equipment. Assessors also look for consistency: the same steps applied to employees and contractors, and records kept where they can be retrieved. The independent certification body decides what it accepts, so confirm its expectations before you design the evidence set. DeployOpen prepares these systems and records; only the auditor reports on them.

How DeployOpen prepares return of assets evidence

DeployOpen starts by scoping the return of assets requirement in writing, before any system is configured. The organization decides which asset classes count (laptops, phones, badges, removable media, tokens and licenses), which parties are covered (employees, contractors, temporary staff and other interested parties), and which events trigger a return, such as resignation, termination, role change or the end of a contract. DeployOpen then documents how those decisions map onto the organization's own systems. The organization keeps ownership of its controls and of the policy that sets these rules. DeployOpen prepares the systems, records and evidence that show the rules are followed, and it does not decide on the organization's behalf what the policy must say.

On the technical side, DeployOpen connects self-hosted platforms into the exit process so that the asset record and the access record change together. GLPI's Assets module can hold the register of computers, phones, peripherals and other equipment, with entries made manually or pushed by the GLPI Agent, so that an assigned device can be traced to a named person. Wazuh's Syscollector inventory shows which endpoints are still reporting and which users and groups exist on them, which helps confirm that a returned device is no longer active. authentik's SCIM provider removes a user from connected applications when access ends, and FreeIPA holds the central user and host objects. Each of these needs a documented owner and a tested leaver step. Confirm with the vendor documentation and your own environment which fields, reports and deprovisioning behaviors your versions provide before you commit to a design.

The evidence an independent assessor will sample for A.5.11 is usually a set of leaver records: the asset list at the time of departure, the return or wipe confirmation, the matching account removals and the exception log for items not returned. DeployOpen assembles these records from the platforms and documents the procedure, but the assessor's conclusions come only from an independent auditor or certification body, and DeployOpen does not issue audit reports or certificates. Ask any implementation partner to state in the statement of work which records they will produce, who signs off each one, and what the organization must still perform itself, such as collecting devices and deciding on disciplinary follow-up for unreturned equipment.

A.5.11 Return of assets