.svg){kind=logo}
Picture this: your auditor asks for a complete list of company assets in the first hour of your SOC 2 review. You hand over a spreadsheet. It hasn’t been updated in six months. Three laptops on it belong to people who left the company. Two SaaS tools listed are ones nobody remembers signing up for.
That’s not an edge case. That’s what I see in almost every first-time compliance engagement.
An asset management policy is the document that prevents that conversation. It defines how your organisation identifies, registers, classifies, uses, and disposes of every asset: hardware, software, data, cloud accounts, and information systems. It assigns ownership, sets rules for acceptable use and secure disposal, and creates the audit trail that shows auditors you actually know what you have.
This policy is required or expected by:
- SOC 2 (Trust Services Criteria CC6.1, CC6.7)
- ISO 27001 (Annex A controls 5.9, 5.10, 5.11)
- NIST Cybersecurity Framework (ID.AM-1, ID.AM-2)
- HIPAA (164.310(d) device and media controls)
By the end of this, you’ll know exactly what your asset management policy needs to cover, how to write one that holds up in an audit, and how to keep it current without making it a full-time job.
Here’s what I’ll cover:
- What an asset management policy actually is (and what counts as an asset)
- Why skipping it creates real security and compliance risk
- Who needs one and when
- What to include, with a free template you can use immediately
- How to implement it and map it to SOC 2, ISO 27001, and NIST
- What auditors look for, and where companies usually get it wrong
Free Template
Download the Asset Management Policy Template (PDF)
Pre-built for SOC 2, ISO 27001, HIPAA, and NIST. Ready to customise and use immediately.
What Actually Goes Into an Asset Management Policy
You have a new hire starting Monday. IT sets up their laptop and adds them to Slack. But does anyone register that laptop in your asset inventory? Does the serial number go on file? When they leave in two years, will you know to collect it and wipe it?
Key insight
An asset management policy doesn't just satisfy auditors — it's the foundation for almost every other security control. You can't patch what you haven't inventoried. You can't offboard someone from a system you didn't know they had access to.
An asset management policy is the set of rules that makes sure the answer to all of those questions is yes. It defines which assets your organisation tracks, how they’re registered and classified, who owns them, how they’re used, and what happens when they’re transferred or disposed of.
The policy is the rulebook. The asset register (or asset inventory) is the living record that shows the policy is being followed. These two things are often confused. The policy tells people what to do. The register proves they did it.
What Counts as an Asset?
Most people think of laptops when they hear “asset management.” The scope is broader:
- Physical hardware: laptops, desktops, servers, mobile devices, tablets, network equipment, peripherals
- Software and licences: operating systems, productivity applications, licensed software, firmware
- SaaS applications: cloud-based tools your team subscribes to, whether IT-managed or employee-initiated
- Data assets: databases, backups, cloud storage, intellectual property, customer records
- Cloud and virtual assets: cloud accounts, virtual machines, containers, serverless functions, managed services
- Information assets: credentials, encryption keys, configurations, sensitive documentation
ISO 27001 specifically broadens the definition to include “information assets” and “services,” which matters if you’re pursuing certification.
What Is an IT Asset Management Policy?
An IT asset management policy covers the same ground but scoped specifically to IT-managed hardware and software: company-issued devices, licensed applications, and the technical infrastructure your team uses day to day.
Larger organisations sometimes maintain this as a separate document from a broader asset management policy that also covers physical assets, data, and third-party services. For most startups and SMBs, a single combined policy is easier to maintain and just as effective for audit purposes.
If you’re writing your first policy, start with one document that covers everything. You can split it later if the scope genuinely warrants it.
Why an Unmanaged Asset List Is a Security Liability
I spoke to a founder who discovered during their SOC 2 audit that three former employees still had active accounts in their production environment. The accounts had never been closed because there was no asset management process connected to offboarding. Nobody had flagged it. Nothing had gone wrong yet. But the auditor flagged it immediately.
Free Demo
An incomplete asset register is one of the top SOC 2 findings
ComplyJet keeps your asset inventory current, maps it to compliance controls, and generates the evidence trail auditors expect from day one.
You can’t protect what you don’t know you have. That’s the core of why this matters.
Every untracked laptop is a potential data loss event waiting to happen. Every forgotten SaaS account is an open door. Every device disposed of without secure erasure is a liability you can’t see.
There are three dimensions to the risk:
Security risk. Untracked assets create blind spots in your security posture. An old server nobody knows is still running can’t be patched. A SaaS tool an employee signed up for independently won’t be covered by your data processing agreements. Devices that leave the office without being logged create exposure you can’t measure.
Compliance risk. SOC 2, ISO 27001, NIST, and HIPAA all require you to know what assets you have and how they’re protected. When an auditor asks for your asset register on day one and you can’t produce a current, accurate one, you’re starting from a deficit that’s hard to recover from.
Operational risk. Without an asset register, offboarding is guesswork. Licence management becomes expensive: you pay for seats nobody uses and miss renewals on tools people depend on. You can’t plan hardware refreshes. You have no baseline to recover from an incident.
The policy doesn’t protect you on its own. The discipline it enforces does.
Which Businesses Actually Need an Asset Management Policy
The short answer: any company that processes customer data, handles sensitive information, or has employees using company-issued devices.
Why it matters
Enterprise procurement teams routinely ask for your asset management policy in security questionnaires. Without one, you're flagging a basic governance gap to every deal you're trying to close.
Companies pursuing SOC 2 need a documented asset management policy to satisfy CC6.1 (logical access controls informed by an understanding of the systems in scope) and CC6.7 (secure disposal of assets containing sensitive information).
Companies pursuing ISO 27001 certification need it to satisfy three Annex A controls: 5.9 (inventory of information and other associated assets), 5.10 (acceptable use), and 5.11 (return of assets at termination or change of employment).
Companies in healthcare need it for HIPAA compliance under 164.310(d), which requires controls over hardware and electronic media that store or process protected health information.
B2B SaaS companies selling into enterprise will encounter this on security questionnaires before a formal compliance programme is even in place. Enterprise procurement teams ask for it, and not having one creates friction in deals.
Any company with remote employees needs an asset management policy more than most. When laptops are shipped to home offices and never physically returned, the risk of losing track of devices and the data on them is real.
Everything Your Asset Management Policy Should Cover
I’ve seen one-page asset management policies that pass audits and ten-page policies that fail them. The length doesn’t matter. What matters is whether the policy addresses each of these areas:
| Policy Section | What to Include |
|---|---|
| Purpose | Why the policy exists; which risk or compliance requirement it addresses |
| Scope | Which assets, locations, and people are covered |
| Asset Types | The categories of assets the policy applies to |
| Roles and Responsibilities | Policy owner, register maintainer, employee and manager obligations |
| Asset Registration | How and when assets get added to the register; required fields |
| Asset Classification | How assets are categorised by sensitivity or criticality |
| Acceptable Use | What employees can and cannot do with company assets |
| Asset Lifecycle | Procurement, deployment, maintenance, transfer, return, and disposal |
| Loss or Theft | How to report lost or stolen assets; escalation procedures |
| Return of Assets | Offboarding procedure, timelines, and confirmation requirements |
| Disposal and Sanitisation | Secure erasure or destruction requirements; documentation required |
| Exceptions | How to request and document deviations from the policy |
| Enforcement | Consequences for non-compliance |
| Review Cadence | How often the policy and register are reviewed |
| Records | What evidence must be maintained and where |
The Asset Lifecycle Management Policy Section
The lifecycle section is the one I see skipped or written too vaguely most often. It’s also the one auditors dig into most. A proper asset lifecycle management policy covers every stage an asset moves through:
| Stage | Requirements |
|---|---|
| Procurement | Purchase approval required before acquisition; asset registered before deployment |
| Deployment | Asset tagged, assigned to an owner, classified, and added to the register |
| Maintenance | Patching and updates applied per your patch management schedule |
| Transfer | Register updated when ownership changes; new owner acknowledged |
| Return | Asset returned at offboarding; access revoked within an agreed timeframe |
| Disposal | Secure erasure or physical destruction; certificate of disposal retained |
The evidence trail at each stage is what makes the policy auditable. Without it, you have rules but no proof they were followed.
Asset Management Policy Example: What Good Coverage Looks Like
Here’s a quick contrast between a thin scope section and a complete one.
Thin version: “This policy applies to all company assets.”
Complete version: “This policy applies to all physical hardware (laptops, servers, mobile devices, network equipment), software (licensed applications, SaaS subscriptions, operating systems), data assets (databases, backups, cloud storage, intellectual property), cloud and virtual assets (accounts, virtual machines, containers), and information assets (credentials, encryption keys, sensitive documentation) owned, leased, or operated by [Company Name] or on behalf of [Company Name] by authorised third parties.”
One of these passes an audit. The other makes an auditor ask follow-up questions for the next hour.
Asset Management Policy Template (Free Download)
Asset Management Policy Sample and Asset Management Policy PDF Download
The template below is based on the policy we use in ComplyJet, adapted as a standalone document. Fill in the bracketed placeholders with your company’s specifics. Everything else is pre-populated with best-practice defaults you can use immediately.
A downloadable PDF version is available via the button below.
Free Template
Download the Free PDF Template
Pre-built and compliance-ready. Customise and use immediately.
Asset Management Policy
Policy Owner: [Name and Role] Effective Date: [Date] Last Reviewed: [Date] Next Review Date: [Date] Version: 1.0
1. Purpose
The purpose of this policy is to:
- Identify organisational assets and define appropriate protection responsibilities.
- Ensure that information receives an appropriate level of protection in accordance with its importance to the organisation.
- Prevent unauthorised disclosure, modification, removal, or destruction of information stored on media or systems.
2. Scope
This policy applies to all [Company Name] employees, contractors, and authorised third parties who use, manage, or have access to company assets. It covers all assets owned or managed by [Company Name], including:
| Asset Category | In Scope | Examples |
|---|---|---|
| Physical hardware | Yes | Laptops, desktops, servers, mobile devices, tablets, network equipment |
| Software and licences | Yes | Operating systems, productivity tools, licensed applications |
| SaaS applications | Yes | Cloud-based tools, whether IT-managed or employee-initiated |
| Data assets | Yes | Databases, backups, cloud storage, intellectual property, customer records |
| Cloud and virtual assets | Yes | Cloud accounts, virtual machines, containers, managed services |
| Information assets | Yes | Credentials, encryption keys, sensitive documentation |
| Third-party-owned equipment | No | Unless used to process company data, in which case subject to vendor agreements |
3. Roles and Responsibilities
| Role | Responsibility |
|---|---|
| IT / Security Team | Maintain the asset register; manage procurement, onboarding, and disposal processes |
| Asset Owners | Accountable for the security, classification, and acceptable use of assigned assets |
| Line Managers | Ensure assets are returned and access revoked at offboarding; report lost or stolen items |
| All Employees | Use assets only for authorised business purposes; report incidents and losses promptly |
| [Policy Owner] | Responsible for reviewing and maintaining this policy |
4. Inventory of Assets
Assets associated with information processing facilities that store, process, or transmit classified information shall be identified, and an inventory of these assets shall be created and maintained.
All assets must be registered in the company asset register within [X] business days of procurement or deployment. Each entry must include:
- Asset ID and description
- Asset category and type
- Serial number or licence key (where applicable)
- Assigned owner and department
- Classification level
- Physical location or logical environment
- Date of procurement or deployment
- Status (active, in storage, decommissioned)
- Disposal date (when applicable)
5. Ownership of Assets
Assets maintained in the inventory shall be owned by a specific individual or team within [Company Name]. The asset owner is responsible for:
- Ensuring the asset is used in accordance with this policy
- Ensuring the asset is correctly classified
- Approving access to the asset where relevant
- Notifying IT when the asset is no longer required or when ownership changes
6. Asset Classification
Assets must be classified by sensitivity level in line with the [Data Classification Policy]:
| Classification | Description | Examples |
|---|---|---|
| Critical | Assets storing or processing highly sensitive or regulated data | Production databases, authentication systems, encryption key stores |
| High | Assets with privileged access or containing confidential information | Developer laptops, admin accounts, SaaS tools with customer data |
| Medium | General business assets | Standard employee laptops, internal SaaS tools, communication platforms |
| Low | Non-sensitive, non-critical assets | Meeting room equipment, shared printers, public-facing content repositories |
7. Acceptable Use of Assets
Rules for the acceptable use of information, assets, and information processing facilities shall be identified and documented in the [Information Security Policy]. In addition, employees must not:
- Install unauthorised software or applications on company devices
- Transfer company data to personal devices or unauthorised storage media
- Use company assets for personal commercial activity
- Share access credentials for company assets with unauthorised individuals
- Leave company devices unattended in public spaces without enabling appropriate locks
8. Handling of Assets
Employees who are issued or handle company equipment are expected to use reasonable judgment and exercise due care in protecting and maintaining equipment. Employees are responsible for ensuring that company equipment is secured and properly attended to whenever it is transported or used outside company facilities.
All mobile devices shall be handled in accordance with the [Information Security Policy]. No company computer equipment or devices may be moved or taken off-site without appropriate authorisation from management, except for devices issued to employees for remote or hybrid work.
9. Loss or Theft of Assets
All [Company Name] personnel must immediately report the loss or theft of any company asset: computers, mobile devices, authentication tokens, or any device that stores, processes, or provides access to company data. Reports must be made to [IT Team / Security Team] within [X] hours of discovery.
Upon receiving a report, the IT team will:
- Remotely wipe the device if technically possible
- Revoke all active sessions and credentials associated with the asset
- Update the asset register to reflect the loss
- Assess and document any data exposure resulting from the incident
10. Return of Assets
All employees, contractors, and third-party users of [Company Name] equipment shall return all organisational assets within their possession upon termination of their employment, contract, or agreement.
Line managers are responsible for confirming asset return before the employee’s final day. The IT team is responsible for verifying return in the asset register and revoking all system access within [X] hours of the last working day.
Any physical assets owned by customers shall be promptly returned to the customer following service termination, in accordance with the terms of the relevant contract or service agreement.
11. Asset Disposal and Re-Use
Company devices and media that stored or processed confidential data shall be securely disposed of when no longer needed. Data must be erased prior to disposal or re-use:
| Disposal Method | When to Use | Documentation Required |
|---|---|---|
| Secure erasure (software) | Storage devices to be re-used or resold | Record of method and date; written confirmation by IT |
| Physical destruction | Devices that cannot be reliably erased | Certificate of Destruction retained for [X] years |
| Third-party destruction | Bulk disposal or specialist equipment | Certificate of Destruction from provider retained for [X] years |
| Cloud account deprovisioning | SaaS and cloud services at offboarding or decommission | Record of deprovisioning date and confirming user |
A Certificate of Destruction (COD) must be obtained for devices destroyed by a third-party service.
12. Exceptions
Requests for an exception to this policy must be submitted in writing to [Exception Approver] with:
- A description of the exception required
- The business justification
- A proposed alternative control (if any)
- A proposed expiry date
Approved exceptions must be logged in the exception register and reviewed every [X] months.
13. Violations and Enforcement
Any known violations of this policy should be reported to [Violation Report Contact]. Violations may result in immediate withdrawal or suspension of system and network access privileges, disciplinary action in accordance with company procedures, or termination of employment.
Significant violations include: wilful failure to register or return an asset, intentional destruction or theft of company property, or unauthorised transfer of sensitive data to a personal or unregistered device.
14. Review
This policy will be reviewed at least annually. Additional reviews will be triggered by:
- Significant organisational changes (mergers, acquisitions, major headcount changes)
- A security incident involving an untracked or improperly disposed asset
- A significant change to the company’s infrastructure or asset categories
- An audit finding related to asset management
15. Version History
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | [Date] | [Author] | Initial version |
How to Write and Roll Out Your Asset Management Policy
Writing the document is the easy part. Getting it to actually work in your organisation is where most companies fall short.
Free Demo
Get a compliant asset management policy in minutes
ComplyJet generates a pre-built policy tailored to your framework requirements, routes it for approval, and tracks employee acknowledgements automatically.
Asset Management Policy Procedures: Your Step-by-Step Checklist
1. Assign a policy owner. For most startups, this is the IT lead, Head of Engineering, or CISO. If you don’t have a dedicated security function, the CTO is fine. Someone needs to own this; “the team” as an owner means nobody is.
2. Audit your current asset inventory. Before writing a single line of policy, find out what you actually have. Talk to IT, finance, and department heads. Check your MDM tool, your SaaS billing dashboard, your cloud provider’s account inventory. The first audit is always uncomfortable.
3. Choose your asset register format. A Google Sheet or Notion database works for small teams. An ITSM tool, MDM system, or dedicated compliance platform works better as you grow. The format matters less than the discipline of keeping it current.
4. Draft the policy using the template above. Customise the scope, roles, lifecycle timelines, and classification levels to match your actual environment. Remove sections that don’t apply and add any that are specific to your infrastructure or regulatory context.
5. Review classification and disposal clauses. These are the two areas most likely to create legal exposure. If you handle regulated data (PII, PHI, financial records), get a legal review of the disposal and retention language before finalising.
6. Get exec or board approval. ISO 27001 specifically requires management approval for policies. Even if you’re not pursuing ISO 27001, executive sign-off creates accountability at the top and strengthens the policy in an audit context.
7. Communicate to all staff. Send the policy to the entire team. For high-sensitivity environments, collect signed acknowledgements. At minimum, confirm distribution via email and retain the record.
8. Map the policy to your compliance controls. Walk through the relevant framework controls (SOC 2 CC6.1, ISO 27001 Annex A 5.9 to 5.11) and document how each section of your policy satisfies each control. This becomes evidence during an audit.
9. Set a calendar reminder for the annual review. Don’t rely on memory. Set a recurring task or calendar event twelve months from the effective date.
10. Collect and store evidence at each lifecycle stage. Procurement records, onboarding checklists, offboarding confirmations, disposal certificates. These are the documents auditors will ask for. Store them somewhere central and accessible.
Mapping Your Asset Management Policy to SOC 2, ISO 27001, and NIST
Auditors don’t just want the policy. They want the register, the procedures, and the evidence that both are actually being used.
Here’s how an asset management policy maps to the major frameworks:
| Framework | Relevant Controls | What They Require |
|---|---|---|
| SOC 2 | CC6.1, CC6.7 | Logical access controls tied to an understanding of assets in scope; secure disposal of assets containing sensitive information |
| ISO 27001 | Annex A 5.9, 5.10, 5.11 | Inventory of assets with designated owners; acceptable use rules documented; assets returned at termination |
| NIST CSF | ID.AM-1, ID.AM-2 | Physical devices and systems inventoried; software platforms and applications catalogued |
| HIPAA | 164.310(d) | Hardware and electronic media containing PHI tracked; media disposal and reuse controlled |
ISO 27001 Asset Management Policy Template: What Annex A Requires
ISO 27001 is the most explicit of these frameworks about asset management. The three Annex A controls you need to satisfy are:
Control 5.9: Inventory of information and other associated assets. Every asset must be identified, and an inventory must be maintained. Every asset must have a named owner. Auditors check whether the register is complete, current, and whether ownership is actually assigned rather than left blank. The full control text is available in the ISO/IEC 27001:2022 standard.
Control 5.10: Acceptable use of information and other associated assets. Rules for acceptable use must be identified, documented, and implemented. This is typically covered in your asset management policy and cross-referenced in your information security policy.
Control 5.11: Return of assets. All employees and external users must return assets at termination of employment, contract, or agreement. Auditors will ask for evidence that this actually happened for recent leavers.
Use the asset management policy iso 27001 template in Section 6 as the starting point. The roles, lifecycle, and disposal sections map directly to Annex A controls. When preparing for certification, document the mapping explicitly: write down which section of your policy satisfies which Annex A control. Auditors appreciate when the legwork is already done.
What Auditors Actually Look for in Asset Management Evidence
You update your asset register the week before your audit. You know that’s what happened. The auditor knows too. They’ll ask for evidence dated throughout the year, not just the week before the review.
Here’s what auditors actually request:
| Record Type | What It Looks Like |
|---|---|
| Asset register | A current export with all fields populated and a visible “last updated” timestamp |
| Procurement records | Purchase orders or IT provisioning tickets showing assets were registered when acquired |
| Onboarding records | Completed onboarding checklists showing assets were assigned and registered at hire |
| Offboarding records | Completed offboarding checklists confirming assets were returned and access revoked |
| Disposal certificates | Written confirmation of secure erasure or a Certificate of Destruction from a third-party service |
| Policy acknowledgements | Signed or click-through acknowledgements showing all relevant staff have read the policy |
| Review history | A dated, version-controlled record of the last annual policy review |
| Exception log | Any approved exceptions with the justification, approver, and expiry date |
The most common gap I see: offboarding records. Teams close accounts but don’t log the asset return. When an auditor asks for evidence that a specific employee’s laptop was returned and wiped, there’s nothing to show.
Asset Management Policy Mistakes That Show Up in Audits
The most common finding in a SOC 2 readiness assessment isn’t a missing firewall rule. It’s an asset register that’s one spreadsheet nobody updates.
Watch out
The most common audit finding isn't a missing policy — it's a stale one. An asset register that hasn't been updated since the last audit tells your auditor that the control isn't operating continuously. That's a repeat finding.
1. The register has no owner. It was created for a previous audit or a past onboarding project and hasn’t been touched since. When no one person is responsible for keeping it current, no one does.
2. Shadow IT is excluded entirely. The policy covers IT-managed hardware and the handful of SaaS tools procurement approved. It ignores the 30 or 40 tools employees signed up for independently with company email addresses. Those tools are in scope for a data breach and out of scope for the policy.
3. Disposal is informal. Old laptops get wiped with a factory reset (which is not a secure erase), donated, sold secondhand, or left in a storage cupboard indefinitely. No certificates. No records. This is one of the easier audit findings to prevent and one of the more common ones to encounter.
4. Offboarding isn’t connected to asset management. HR runs the offboarding checklist. IT closes accounts. But nobody confirms the laptop was actually returned, and the asset register never gets updated. Six months later, there’s an active record for someone who left the company.
5. Classification is absent or meaningless. Every asset is listed with no classification, or every asset is marked “High” because nobody thought through the criteria. Classification is supposed to drive how assets are protected. If it’s not meaningful, it’s not doing anything.
6. “Annual review” is aspirational. The policy says it will be reviewed annually. There’s no evidence of any review ever taking place: no dated document, no approval record, no version history. This is an easy finding for an auditor and a straightforward one to prevent.
Startup vs. Enterprise: Right-Sizing Your Asset Management Policy
If You’re a Startup (Under 30 People)
Keep it simple. A lean, well-written policy and a Google Sheet asset register are enough for most early-stage audits. The policy needs to exist, be signed off by someone in leadership, and be communicated to the team. The register needs to be accurate and current.
Quick tip
At under 20 people, a Google Sheet backed by a signed policy is sufficient for SOC 2 Type 1. You don't need a full CMDB until you're managing 100+ assets or preparing for ISO 27001.
Your priorities: laptop tracking, SaaS tool inventory, and an offboarding checklist that covers asset return. Get those three things working and you’ll satisfy the majority of what SOC 2 and ISO 27001 will ask of you at this stage.
You don’t need a 20-page policy with a formal exception approval committee. Start lean and add complexity as your headcount and infrastructure grow.
If You’re Growing (30 to 150 People)
Move the asset register to a dedicated tool: your MDM system, a CMDB, or your compliance platform. A spreadsheet becomes unreliable as the team grows and the number of assets increases.
At this stage, consider separating the register into hardware, software, and SaaS categories. Assign asset owners per department rather than per individual. Integrate asset return into your HR offboarding workflow explicitly, rather than relying on informal handoffs between IT and people managers.
If You’re Larger or More Heavily Regulated
Full lifecycle management with documented approval workflows at each stage. A formal exception and deviation process with version-controlled records. Integration between asset management, patch management, vulnerability management, and your data classification framework.
If you operate across multiple jurisdictions or handle regulated data at scale, the disposal and retention clauses may need legal review for each region. Data protection law varies in how long disposal records must be retained and which erasure standards apply.
Keeping Your Asset Inventory Audit-Ready with ComplyJet
The policy is the foundation. The evidence trail is what gets you through an audit.
I’ve watched companies spend a full week before a SOC 2 audit frantically updating their asset register, hunting for disposal certificates, and chasing down signed acknowledgement records. That scramble is what ComplyJet is designed to prevent.
ComplyJet gives you a pre-built asset management policy template you can customise, approve, and version-control in minutes. Employee acknowledgements are tracked through the platform automatically. Control mapping ties your policy to the specific SOC 2, ISO 27001, HIPAA, and NIST requirements it satisfies, so you’re not doing that work manually during audit prep. Review reminders fire automatically so the annual review doesn’t get forgotten. And when an auditor asks for your evidence, it’s all in one place.
The goal isn’t a perfect document. It’s a live, maintained, auditable process.
FAQ: Asset Management Policy
What is an asset management policy?
An asset management policy is a formal document that defines how your organisation identifies, registers, classifies, uses, and disposes of its assets: hardware, software, SaaS applications, data, and cloud resources. It sets the rules for who owns what, how assets are tracked across their lifecycle, and what happens when an employee leaves or an asset is decommissioned. It’s distinct from the asset register itself: the policy defines the rules; the register is the record that shows they’re being followed.
Do I need a separate IT asset management policy?
An IT asset management policy covers the same ground as a general asset management policy but scoped specifically to IT-managed hardware and software: company-issued devices, licensed applications, SaaS subscriptions, and the technical infrastructure the team relies on. Larger organisations sometimes maintain this as a separate document. For most startups and SMBs, a single combined policy covering all asset types is simpler to maintain and equally effective for compliance purposes.
What is an asset management policy in plain terms?
It’s the document that says: here’s everything the company owns, here’s who is responsible for each thing, here’s the rules for using it, and here’s what happens when it needs to be returned or disposed of. It’s the rulebook for your organisation’s assets.
Who should own the asset management policy?
Typically the IT or security team owns the day-to-day operation of the asset register, with the CISO or CTO as the policy owner for approval and review. For startups without a dedicated security function, the CTO or a senior engineering lead usually takes ownership. What matters most is that one named person is responsible. “The team” as an owner means nobody is.
What does ISO 27001 require for asset management?
ISO 27001 Annex A includes three asset management controls: 5.9 (inventory of information and associated assets, with named owners for every asset), 5.10 (acceptable use of information and associated assets), and 5.11 (return of assets at termination or change of employment). During certification, auditors check that your register is complete and current, every asset has a named owner, and return and disposal processes are evidenced.
How often should an asset management policy be reviewed?
At minimum annually. In practice, you should also trigger a review after significant organisational changes: a major hiring round, an infrastructure migration, an acquisition, or a security incident involving an untracked or improperly handled asset. The review should produce a dated, version-controlled record that you retain as evidence.
Do startups need an asset management policy?
Yes, particularly if you’re pursuing SOC 2 or ISO 27001, or selling into enterprise accounts that run security questionnaires. The policy doesn’t need to be complex: a lean document backed by an accurate, current asset register is enough to satisfy most early-stage requirements. The mistake is waiting until the audit sprint to write it. You can’t backfill the evidence trail.
Related Policies
Data Classification Policy: Asset management and data classification work together. Your asset register should reference the classification level of each asset, and the classification policy determines how each tier is protected.
Change Management Policy: Changes to critical assets, including configuration changes, upgrades, and decommissions, should follow a formal change management process. The two policies work in tandem.
