Annex A 5.11: Return of Assets

Annex A 5.11 sits in the “Organizational controls” portion of ISO/IEC 27001:2022 and targets a predictable failure point: departures and contract terminations. Asset return is not only about getting laptops back. It’s about preventing continued use of anything that can store, access, or represent your information, including credentials, keys, removable media, hard-copy records, and third-party-held materials.

For a Compliance Officer, CCO, or GRC lead, the fastest path to readiness is to treat 5.11 as an offboarding control with inventory, workflow, and evidence. If you can’t show auditors a repeatable process and a trail of records for recent exits, you’ll struggle even if the organization “usually gets devices back.”

ISO 27001 does not prescribe one tool or one checklist format. Your job is to define the scope of assets that matter in your environment, assign accountable owners, and run a consistent operational process that works for employees, contractors, and third parties. ISO’s overview of the standard and public summaries of Annex A controls provide the framework context for implementing these controls in an ISMS ¹.

Regulatory text

Control: “ISO/IEC 27001:2022 Annex A control 5.11 implementation expectation (Return of Assets).” ¹

Operator interpretation (what you must do):
You must have a defined, repeatable process that ensures assets are returned when employment, contract engagement, or a third-party relationship ends, and you must retain evidence that the process ran. “Assets” includes physical items (devices, badges, keys) and information-related assets (documents, records, storage media) that could expose confidential information or enable ongoing access.

Plain-English interpretation

If someone leaves, you collect what they have, you shut off what they can still use, and you can prove both happened. That includes:

• Items the person physically holds (laptop, phone, hardware tokens, building access badge, keys).
• Items they can access remotely (accounts, shared secrets, API keys, VPN).
• Items held on your behalf by a third party (hosted data exports, backups, paper files in a contractor’s office).

This control tends to fail when organizations treat “return of assets” as “IT collects the laptop” and ignore credentials, shared admin accounts, and non-IT assets.

Who it applies to

Entity scope

Any organization implementing ISO/IEC 27001:2022 with an ISMS, including service organizations that must demonstrate controlled handling of information assets across the lifecycle of personnel and third-party relationships ².

Operational context (where it shows up)

• Employee offboarding: voluntary and involuntary terminations, retirements, internal transfers (where access changes), long-term leaves (where devices may be retained but access should change).
• Contractor/consultant offboarding: end of statement of work, reassignment, loss of sponsorship.
• Third-party relationship termination: switching providers, terminating an outsourcing arrangement, ending a data-processing engagement.

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

1) Define the asset-return scope and categories

Create a short, explicit list of asset categories your organization expects to be returned or confirmed as destroyed/removed. Keep it operational, not philosophical.

Minimum categories to consider:

• Corporate devices: laptops, mobiles, tablets, peripherals issued with storage capability.
• Authentication assets: hardware tokens, smart cards, physical keys, keycards.
• Removable media: USB drives, external drives, printed reports, notebooks.
• Confidential paper: contracts, customer lists, architecture diagrams, incident notes.
• Logical assets that must be reclaimed/rotated: shared passwords, break-glass credentials, SSH keys, API tokens, certificates.

Output: an “Asset Return Standard” section in your offboarding procedure that defines what must be collected, what must be revoked, and how exceptions are handled.

2) Assign ownership and handoffs

Your process needs named accountability:

• HR (or People Ops): triggers offboarding events and effective dates.
• IT / IAM: disables accounts, revokes tokens, confirms device return and wipe status.
• Facilities / Physical Security: deactivates badges and recovers keys.
• Information Security / GRC: sets policy, monitors exceptions, samples evidence.
• Asset owners / Department managers: confirm return of non-standard equipment and documents.

Create a simple RACI and embed it into your written procedure so execution doesn’t depend on tribal knowledge.

3) Connect offboarding triggers to an auditable workflow

Pick a system of record for offboarding tasks (ticketing system, HRIS workflow, GRC platform, or a controlled checklist with approvals). The key is: each departure produces a record that lists required asset-return steps and shows completion.

Recommended workflow fields:

• Person/third party name, department, manager, last day, location, engagement type.
• Issued assets (pulled from inventory) and “other assets” free-text prompt.
• Task list with owners and completion timestamps.
• Exceptions section (lost device, remote worker, disputed ownership, legal hold).

4) Reconcile against inventory, not memory

For devices and hardware tokens, reconciliation must tie to an inventory record:

• If your asset inventory is incomplete, fix that first for in-scope assets.
• At offboarding time, generate a list of assets assigned to the user from inventory.
• Update inventory upon return (status, location, custodian) or mark as lost with incident linkage.

This is where auditors look first: “Show me the device inventory record and the offboarding ticket for the same user.”

5) Handle remote and cross-border exits explicitly

Remote exits are where asset return breaks. Document how you handle:

• Shipping labels and tracking number requirements.
• Chain-of-custody expectations for high-sensitivity devices.
• Time-bound escalation steps when assets are not returned.
• Alternative outcome: remote wipe plus written attestation of destruction for certain asset types (where appropriate for your risk model).

Keep it practical: name who authorizes “non-return” outcomes and what evidence is required.

6) Build an exceptions and escalation path

You need a consistent decision path for:

• Non-returned devices.
• Claims that assets are personal property.
• Legal holds or investigations that require preserving devices.
• Third parties that refuse return due to contractual disputes.

Minimum expectation: exceptions are logged, approved, and tracked to closure. Link to incident management when confidentiality risk exists.

7) Monitor and sample for control operation

Define a recurring check run by GRC or Security:

• Pull recent departures and confirm each has an offboarding record.
• Verify evidence attached for high-risk roles (admins, finance, engineering, customer support).
• Track trends: repeated delays, specific teams, specific third parties.

If you run ISO surveillance audits, this sampling record becomes the fastest way to prove the control is operating, not just documented ².

Required evidence and artifacts to retain

Auditors generally want proof at two levels: control design (documents) and control operation (records).

Design evidence

• Offboarding policy/procedure that includes asset return requirements.
• Asset Return Standard (asset categories, responsibilities, exceptions).
• RACI for offboarding and asset return.
• Third-party contract clauses or exit checklists that require return or certified destruction (where applicable).

Operating evidence ²

• Offboarding ticket/workflow record with completed tasks and timestamps.
• Asset inventory record updates (returned, reassigned, wiped, destroyed, lost).
• Badge/key deactivation confirmation (physical access system record or facilities ticket).
• IAM/access revocation evidence (account disable logs, access review record, or ticket tasks completed).
• Exception approvals and remediation actions for non-returned assets.

Retention period: set it in your ISMS documentation based on internal risk and audit needs. ISO 27001 expects you to retain documented information as necessary for the effectiveness of the ISMS ².

Common exam/audit questions and hangups

Expect these questions in certification audits and internal audits:

• “Show the last few departures and evidence that assets were returned.”
• “How do you ensure contractors and other third parties return assets at end of engagement?”
• “What happens when a device is not returned?”
• “How do you cover non-IT assets like paper files, prototypes, or keys?”
• “How do you ensure shared credentials are rotated when someone leaves?”
• “Who reviews exceptions and how do you track closure?”

Hangups that trigger nonconformities:

• No consistent workflow record per departure.
• Inventory cannot be reconciled to people (no assignment data).
• “We emailed the manager” instead of a tracked completion.
• Contractors managed outside HR with no standardized offboarding trigger.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating 5.11 as only device return.
   Fix: Include credentials, tokens, physical access, and confidential records in scope. Put the list in the procedure.

2. Mistake: No exceptions process for non-return.
   Fix: Create a documented path: classify as incident, approve exception, pursue recovery, rotate credentials, document closure.

3. Mistake: Offboarding starts late for involuntary terminations.
   Fix: Build a rapid response path where HR triggers IT/IAM and Facilities actions immediately, with asset return coordinated afterward.

4. Mistake: Third parties offboard through “informal” channels.
   Fix: Require a contract owner to open an offboarding record for third-party exits, and include return/destruction terms in third-party agreements where appropriate.

5. Mistake: Evidence is scattered across email and chat.
   Fix: Centralize evidence in the offboarding ticket or GRC repository. Attach shipping confirmations, signed checklists, and screenshots where needed.

Enforcement context and risk implications

ISO 27001 itself is a certifiable standard, not a regulator. The risk is audit failure (major/minor nonconformities) and downstream customer trust impact when you cannot prove controlled exits. Practically, failures here correlate to:

• Data leakage from retained devices or copied files.
• Unauthorized access from credentials that weren’t revoked or rotated.
• Physical security weaknesses (badges/keys not recovered).

The control is rated “medium” severity in many internal control catalogs because the impact can be high, but the fix is procedural and operational rather than purely technical ¹.

Practical 30/60/90-day execution plan

First 30 days (stabilize the basics)

• Publish a written offboarding procedure with an explicit asset-return section aligned to Annex A 5.11 ².
• Standardize the offboarding trigger and create one workflow template used by HR/Procurement/contract owners.
• Define the asset categories and owners (IT, Facilities, managers) and document exceptions handling.
• Identify the system of record for evidence (ticketing or GRC) and stop storing proof only in email.

Days 31–60 (make it auditable)

• Reconcile your asset inventory so devices and tokens can be tied to individuals.
• Update offboarding workflow to auto-populate assigned assets where possible.
• Add required evidence fields/attachments (badge deactivation, inventory update, access disable).
• Train HR, IT service desk, and contract owners with a short runbook.

Days 61–90 (prove operation and close gaps)

• Run a sample review of recent departures; document findings and corrective actions.
• Add escalation for non-returned assets and link to incident management when appropriate.
• Extend the process to third parties: contract exit checklists, return/destruction attestations, and tracking.
• Consider automation where it reduces misses (IAM disable triggers, device management wipe confirmation), while keeping human approvals for exceptions.

Where Daydream fits naturally

If your main pain is evidence sprawl and inconsistent execution, Daydream can house the control narrative, map Annex A 5.11 to your offboarding workflow, and prompt recurring evidence capture so you can answer audits with a clean record set instead of screenshots collected under pressure.

Frequently Asked Questions

Does Annex A 5.11 require physical return of every asset, or can we accept destruction/attestation?

ISO 27001 expects you to ensure assets are returned or otherwise appropriately handled at the end of the relationship ². For some asset types, documented destruction plus access revocation can be acceptable if your procedure defines it and you retain evidence.

How do we handle BYOD devices where the organization does not own the phone or laptop?

Treat “return of assets” as return of organization-controlled information and access. Require removal of corporate data (via MDM/container removal where applicable) and revoke credentials; retain the offboarding record that shows those steps completed.

Are logical credentials (API keys, shared passwords) considered “assets” under 5.11?

In practice, yes for operational control purposes because they provide ongoing access to information and systems. Build a rotation/revocation step into offboarding for shared secrets and admin access, and keep evidence in the same workflow record.

What evidence is “enough” for auditors?

Auditors typically expect a documented procedure plus per-departure records showing completion, timestamps, and inventory updates. If evidence is split across systems, maintain a single offboarding ticket that links out to supporting records.

How do we apply this to third parties that never had physical assets, only access?

Your exit workflow should still require confirmation of access removal and return or deletion of organization information held by the third party. Where contracts allow, collect a written confirmation of return/deletion and retain it with the termination record.

What if a laptop is not returned and the employee is unresponsive?

Record it as an exception, escalate through HR/legal processes, and treat the exposure as an information security issue where warranted. Ensure accounts are disabled, credentials rotated, and the asset inventory reflects the status and actions taken.

Footnotes

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

2. ISO/IEC 27001 overview