Guide

ISO 27001 Annex A 5.9: The Asset Inventory Your Auditor Expects

What the 2022 control actually requires, how certification auditors sample it, how classification, ownership and risk hang off it, where Cyber Essentials overlaps — and how to build an inventory that survives both.

An information security management system is only as honest as its asset inventory. Almost everything a certification auditor will ask you to demonstrate — that access is restricted to the right people, that endpoints are hardened, that media is disposed of securely, that leavers return their kit — assumes you can produce a complete, current list of what you are protecting and who is accountable for it. ISO/IEC 27001:2022 makes that assumption explicit in Annex A control 5.9, and it is one of the first things tested and one of the most common places certification stumbles. This guide explains what the control requires, how auditors sample it, how classification, ownership and risk connect to it, where it overlaps with Cyber Essentials and UK GDPR, and how to build an inventory that survives the audit rather than one that merely exists in a folder.

One point up front, because it matters: CPCON is not a certification body and does not certify organisations to ISO 27001. The certificate decision belongs to your UKAS-accredited certification body. What CPCON delivers is the underlying inventory evidence the standard asks you to produce — counted and reconciled by an independent team — so that when the auditor starts sampling, the answers are already on the floor.

What control A 5.9 actually says

ISO/IEC 27001:2022 Annex A control 5.9 — Inventory of information and other associated assets — is short and unforgiving: an inventory of information and other associated assets, including owners, shall be developed and maintained. It sits in the organisational theme of the 2022 control set and merges what the 2013 edition treated as two controls: the inventory itself (old A.8.1.1) and ownership (old A.8.1.2). Since the transition deadline for the 2013 edition passed in October 2025, every certification audit now runs against this wording.

Three words carry the weight. Inventory: a structured record, not tribal knowledge spread across spreadsheets, mailboxes and the service desk. Owners: a named person or role accountable for each asset or group of assets — because controls without owners do not get operated. Maintained: the inventory reflects joiners, leavers, moves and disposals as they happen, not as they are remembered the week before the audit.

The detail behind the headline lives in ISO/IEC 27002:2022, the companion code of practice. It is guidance rather than a checklist — the standard deliberately avoids prescribing fields — but it sets clear expectations: the inventory should be accurate, up to date, consistent with other inventories, and aligned to information classification; each asset should have a designated owner; and the owner should be accountable for the asset across its lifecycle, from inventorying and classification through to correct handling on transfer and disposal. Auditors read 27002 as the benchmark for what "good" looks like, even though they certify against 27001.

The logic is older than the standard: you cannot classify, protect, patch or return what you have not identified. Almost every other Annex A control presupposes 5.9 — which is why an inventory finding tends to cascade into findings elsewhere.

“Information and other associated assets” — the scope

The control deliberately reaches beyond hardware. The accompanying guidance in ISO/IEC 27002:2022 expects organisations to decide the right granularity, but a defensible inventory usually covers:

Asset typeExamplesTypical owner
InformationDatabases, files, records, contracts, intellectual property, backups, archived mediaData / process owner
HardwareLaptops, desktops, mobiles, servers, network kit, removable media, IoT/OT devicesIT / named custodian
SoftwareApplications, operating systems, firmware, licences, development toolingApplication owner
Cloud & servicesSaaS subscriptions, IaaS/PaaS tenants, hosting, comms links, outsourced processingService owner
Physical & supportingComms rooms, access-controlled areas, cabling, power, HVAC, fire suppressionFacilities / site owner
People & knowledgeKey roles, qualifications, undocumented know-how, supplier dependenciesLine management / HR

The art is in the granularity. List every cable and you produce an inventory nobody maintains; list "all IT" as a single line and you have no inventory at all. The standard expects a sensible level: individual devices and information assets where they carry distinct risk, ownership or handling requirements, and groups where they do not. A practical rule is to itemise anything that can be lost, stolen, moved or independently disposed of — which is exactly the population a physical count addresses — and to group truly homogeneous, fixed infrastructure.

Two scoping mistakes recur. The first is treating the inventory as an IT-only artefact and forgetting non-digital information assets: paper records still in scope, archived media, and the know-how concentrated in a handful of people. The second is letting the inventory scope drift away from the ISMS scope defined for certification — assets inside the certified boundary that never make the list, or assets on the list that sit outside scope without explanation. Auditors check both edges.

In practice, the hardware layer is where inventories fail first — devices are numerous, mobile and easy to lose track of — and it is the layer your auditor can physically test. That is why the device inventory deserves the most operational discipline, and why a wall-to-wall IT asset inventory is the most reliable foundation for the whole control.

What an A 5.9 inventory record should contain

The standard does not mandate a field list, but auditors and ISO/IEC 27002 converge on the same practical minimum. An inventory line that cannot answer "what is it, who owns it, where is it, how sensitive is it, and when did we last confirm it exists?" is hard to defend. A workable record set:

FieldWhy the auditor cares
Asset identifierUnique tag/ID — the anchor the auditor scans during two-way sampling.
Asset type & descriptionClass and enough detail to recognise the asset on the floor (make, model, serial).
OwnerNamed person or role accountable for the asset, reconciled to HR — mandatory under A 5.9.
Custodian / userWho currently holds or operates the asset, where this differs from the owner.
LocationSite, building and room — granular enough for record-to-floor sampling.
ClassificationConfidentiality / integrity / availability rating that drives the protection level.
StatusIn use, in store, in transit, awaiting disposal — and the data-bearing flag.
Last verifiedDate and method of the most recent physical confirmation — the proof of maintenance.

The last-verified field is the one most inventories omit and the one that most clearly separates a maintained inventory from a populated database. A line that asserts an asset exists but carries no evidence of when that was last confirmed is, to an auditor, an assertion rather than a control. Stamping the date and method of physical verification against every line is what makes "maintained" demonstrable.

Ownership: the word auditors test hardest

"Including owners" is three words in the control and a recurring source of nonconformities in practice. ISO/IEC 27002:2022 is explicit that the asset owner is accountable across the lifecycle: ensuring assets are inventoried and classified, defining and periodically reviewing access restrictions and classifications, and ensuring proper handling when the asset is deleted, destroyed, transferred or returned. Ownership is accountability, not custody — the owner need not be the daily user.

Common failures the auditor will surface: blank owner fields; "IT" or "Facilities" used as a catch-all owner for thousands of assets; owners who have left the organisation; and owners who, when asked, do not know they own the asset or what that entails. The fix is to treat owner as mandatory data, reconciled to current HR records, assigned to named individuals or clearly defined roles, and backed by an acceptable-use and handling expectation the owner has actually seen. Where assets are grouped, the group needs a single accountable owner, not a committee.

Classification: linking the inventory to protection

A 5.9 produces the list; A 5.12 (classification of information) decides how hard each item must be protected. The inventory is where the two meet, because classification is recorded against assets and then drives the controls applied to them. Most UK organisations operate a simple tiered scheme — a four-level model is common and maps cleanly onto government-style handling — assessed primarily on confidentiality, with integrity and availability considered where they matter:

LevelImpact of disclosureTypical examples
PublicDisclosure causes no harm; published or intended for releaseMarketing material, published reports
InternalFor internal use; limited harm if disclosedInternal procedures, org charts, most email
ConfidentialDisclosure causes real business or regulatory harmCustomer PII, contracts, financials, source code
Strictly confidentialDisclosure causes severe harm; tightly need-to-knowCredentials, encryption keys, M&A, special-category data

The classification on an asset is not decoration: it should change how the asset is handled, stored, transmitted and disposed of, and it feeds the risk assessment. A device or repository holding special-category personal data under UK GDPR should carry a classification that pulls in stronger controls than one holding published material. Auditors test the chain — pick a confidential asset from the inventory and ask to see the controls its classification implies — so an inventory whose classifications are blank, default or inconsistent fails on more than one control at once.

How the inventory feeds the risk assessment

ISO 27001 clause 6.1.2 gives you freedom over your risk assessment method, and the 2022 standard does not force an asset-based approach. But in practice the inventory still anchors the risk work in two ways. First, even a scenario-based or threat-based assessment has to know what is in scope to be protected — and the inventory is that boundary. Second, the controls you choose and document in the Statement of Applicability are applied to assets and asset groups, so the inventory is the population over which "are the controls actually operating?" is answered.

The dependency runs in one direction and it is unforgiving: if the inventory is incomplete, the risk assessment beneath it has blind spots it does not know about, and the Statement of Applicability asserts coverage it cannot demonstrate. An asset that was never inventoried was never risk-assessed and is protected by accident if at all. This is precisely why auditors trace between the inventory, the risk assessment and the Statement of Applicability — and why the completeness of the inventory is load-bearing for the whole ISMS, not just for control 5.9 in isolation.

How auditors test it

Certification runs in stages — a Stage 1 documentation review, a Stage 2 implementation audit, then annual surveillance and three-yearly recertification — and the asset inventory is tested at every one of them, because it is cheap to sample and revealing when it fails. Expect:

  • Two-way sampling. Floor-to-record: the auditor points at a laptop, a switch, a server and asks you to find it in the inventory with the correct owner and location. Record-to-floor: the auditor picks lines from the inventory and asks to see the asset. Either direction failing suggests the inventory is not complete or not maintained.
  • Lifecycle probes. Recent joiners, leavers, refreshes and disposals, traced into the inventory. A leaver whose laptop is still “assigned” three months on is a finding against A 5.9 and the return-of-assets control (A 5.11) in one move.
  • Maintenance evidence. Last-verified dates, reconciliation reports, cycle-count records. An inventory with no evidence of upkeep is treated as a snapshot, not a control.
  • Ownership challenge. The auditor may go to a named owner and ask whether they know they own the asset and what that means. Owners who are surprised, or who have left, turn a tidy spreadsheet into a finding.
  • Consistency checks. The inventory against the Statement of Applicability scope, the risk assessment, the classification scheme, MDM enrolment and the fixed asset register. Large unexplained gaps between systems invite deeper digging.

Connected controls multiply the exposure. The inventory is the backbone several other Annex A controls hang off, and a weak inventory pulls them down with it:

ControlTitleDependence on the inventory
A 5.9Inventory of information and other associated assetsThe inventory itself, including owners
A 5.10Acceptable use of information and associated assetsRules per asset class — needs the asset list
A 5.11Return of assetsRecovery on termination — leaver kit traced through the inventory
A 5.12Classification of informationThe classification scheme applied to inventoried assets
A 7.9Security of assets off-premisesHome and field devices — the part that drifts fastest
A 7.10Storage mediaRemovable and archive media tracked through disposal
A 7.14Secure disposal or re-use of equipmentData destruction evidence against disposed assets
A 8.1User endpoint devicesEndpoint hardening applied to a known device population

Get 5.9 wrong and the nonconformities rarely come alone: a single unreturned leaver laptop can be written up against A 5.9 (inventory not maintained), A 5.11 (return of assets) and A 7.9 (assets off-premises) simultaneously, and if it held personal data it becomes a UK GDPR exposure on top.

The Statement of Applicability and the scope boundary

The Statement of Applicability (SoA) is the document that lists every Annex A control, states whether it applies, and justifies any exclusion. A 5.9 is one of the controls hardest to exclude credibly — because so many others depend on it — so in practice it is marked applicable, and the SoA then becomes one of the documents the auditor reads the inventory against. Two consistency tests follow directly.

First, the inventory has to cover the certified scope. The ISMS scope statement defines a boundary — sites, business units, services — and every asset inside that boundary should appear in the inventory. Assets in scope that are missing from the list are a completeness failure; assets on the list that sit outside scope need an explanation, because an inventory that quietly mixes in-scope and out-of-scope assets makes it impossible to tell whether the controls actually cover what they claim to. Second, where the inventory and the SoA disagree about an asset class — the SoA implies a control over a category of devices the inventory does not record — the auditor has found a thread to pull. Keeping the inventory scope and the ISMS scope deliberately aligned, and being able to explain any difference, is what stops these checks turning into findings.

The nonconformities that recur

Across certification and surveillance audits, inventory findings cluster into a small set of recurring patterns. Knowing them is the cheapest way to avoid them:

  • Blank or generic owners. Owner fields left empty, or "IT" used as a blanket owner for the whole estate, against a control that explicitly says "including owners". The fix is owner as mandatory data, named to individuals or defined roles.
  • Stale or absent verification dates. An inventory with no evidence of when assets were last confirmed reads as a snapshot, not a maintained control. Last-verified dates and reconciliation reports are the proof of maintenance.
  • Floor-to-record gaps. The auditor points at a device that is not in the inventory — usually stored, recently arrived, or shadow IT — exposing that the list is not complete.
  • Record-to-floor ghosts. Inventory lines the organisation cannot physically produce, because the asset was moved, swapped or disposed of without the record catching up.
  • Unreturned leaver assets. Kit still assigned to people who have left — a single finding that can be written against the inventory, return-of-assets and off-premises controls at once.
  • Classification missing or default. Assets with no confidentiality rating, or everything defaulted to one level, so the classification cannot be driving the protection it is supposed to.
  • Inventory inconsistent with other records. Large unexplained gaps between the inventory and MDM, the CMDB or the fixed asset register, inviting the auditor to question which — if any — is right.

Almost every item on that list is a symptom of the same root cause: an inventory that was populated once and never physically re-grounded in reality. Each is closed by the same discipline — an independent count, owners as data, classification applied, and a dated reconciliation — which is why a single verification project tends to clear several potential findings together.

Physical evidence: why discovery is not enough

The most common objection in a Stage 2 audit is "our MDM and discovery tools give us a live inventory." They are valuable, and they are structurally incomplete. Agent-based discovery, MDM and RMM tooling enumerate devices that are powered, connected and enrolled at scan time. By construction they cannot see the spare laptops in a cupboard, the switch awaiting disposal, the unreturned leaver device sitting offline at home, equipment on isolated or OT networks, or any non-digital information asset at all. Worse, absence from a scan is ambiguous — a missing device might be off, in transit, re-imaged under a new name, or genuinely gone — so discovery cannot reliably prove a disposal happened either.

This is exactly why physical sampling is a standard part of the audit, and why a periodic physical verification is the evidence that an inventory is complete rather than merely populated. Our companion guide on why CMDBs lie without a physical audit sets out, source by source, what each automated tool systematically misses — the same blind spots an auditor exploits when they walk to the comms room and start pointing at kit.

The Cyber Essentials overlap

UK organisations rarely face ISO 27001 alone — Cyber Essentials is the other assessment that stands or falls on the device inventory. The self-assessment requires you to define scope and declare the devices within it, including make and operating system, and an unsupported operating system inside scope is an automatic fail. Cyber Essentials Plus adds an independent technical test of a sample of those devices. The NCSC’s own guidance treats asset management not as a standalone control but as the foundation that makes the five technical controls possible.

The overlap is not incidental: both schemes are asking the same underlying question in different language. ISO 27001 wants "an inventory of information and other associated assets, including owners"; Cyber Essentials wants "the devices in scope, with make and operating system." A laptop you cannot find for the auditor is the same laptop you cannot honestly declare on the Cyber Essentials self-assessment. An end-of-life operating system you did not know was still in use is a finding in one and a fail in the other.

The practical conclusion: build one device inventory, physically verified, with owners, operating systems and status — and let it feed the ISO 27001 evidence pack, the Cyber Essentials declaration, UK GDPR Article 30 records and the fixed asset register simultaneously. Maintaining four contradictory lists is how organisations fail all four.

UK GDPR: the same inventory does double duty

The asset inventory is also the practical foundation for data protection. UK GDPR Article 30 requires records of processing activities, and those records assume you know which systems and devices hold personal data — a mapping that an asset inventory, classified for confidentiality and flagged for personal data, makes possible rather than guesswork. The same is true of breach response: the Article 33 obligation to assess and, where required, notify a breach within 72 hours is impractical for a lost laptop you did not know existed or could not confirm what it held.

Secure disposal closes the loop. Annex A 7.14 (secure disposal or re-use of equipment) and the UK GDPR storage-limitation and integrity-and-confidentiality principles both expect data-bearing assets to be disposed of with evidence. An inventory that flags every data-bearing device and reconciles disposals against data-destruction certificates turns a recurring audit finding — kit gone with no destruction record — into a controlled, evidenced process.

Building an inventory that survives sampling

  1. Start physical. A wall-to-wall IT asset inventory establishes what actually exists — including the stored, offline and unreturned devices no discovery tool can see — and the same field discipline extends to full fixed asset verification where the estate is wider than IT.
  2. Tag everything. Durable asset tags give every device a scannable identity, so two-way sampling takes seconds instead of arguments.
  3. Assign owners as data, not intention. Owner is a mandatory field, reconciled to HR records — A 5.9 says “including owners”, and auditors check the named owner actually knows they own it.
  4. Classify against the scheme. Record a confidentiality (and, where it matters, integrity and availability) rating on every asset, and make sure the rating actually drives the handling and disposal controls applied to it.
  5. Reconcile the sources. Physical count against discovery/MDM against CMDB against register, on a defined cycle — our guide on why CMDBs lie without a physical audit explains what each source systematically misses.
  6. Wire in the lifecycle. Joiner, leaver, move and disposal processes update the inventory at the moment they happen, with data-destruction certificates filed against disposed data-bearing assets and a last-verified date stamped on every confirmed line.

“Maintained”: surviving surveillance, not just certification

Certification is not the finish line. After the initial Stage 2 audit, the certificate is sustained through annual surveillance audits and a full recertification at the three-year point — and the asset inventory is sampled at every one of them. The word that does the work across that cycle is maintained. An inventory that looked complete in the certification audit but has received no upkeep since will, at the first surveillance visit, show the symptoms the auditor looks for: new joiners with kit that is not recorded, leavers whose devices are still assigned, disposals with no trail, and last-verified dates that have not moved.

Treating the baseline count as the end of the work is therefore the most common way organisations pass certification and then collect findings at surveillance. The inventory has to be wired into the events that change it. Joiner, mover, leaver and disposal processes should update the inventory at the moment of the event, not in a pre-audit scramble. High-churn classes — laptops, mobiles, loan kit — warrant rolling cycle counts so the record stays close to reality without a full re-count. A standing physical-to-CMDB-to-register reconciliation, owned and dated, keeps the three systems converged. And a last-verified date stamped on every confirmed line is the single most persuasive piece of evidence that the inventory is a living control rather than an annual artefact.

Done this way, the surveillance audit becomes a confirmation rather than a risk: the auditor samples, the samples reconcile, the dates are recent, and the findings stay closed. That is the practical meaning of "developed and maintained" — and it is the difference between a certificate you defend with evidence and one you re-earn under pressure every year.

Sector context: regulated environments

For sectors where supervisory expectations sit on top of certification, the inventory carries more weight still. In financial services, operational resilience and outsourcing rules push firms to evidence control over the technology underpinning important business services — which is impossible without knowing what that technology is and where it sits. Our financial services page sets out how asset verification supports that picture. The same logic applies anywhere a regulator, insurer or large customer can ask you to prove, not assert, what you hold.

An A 5.9 readiness checklist

Before a certification or surveillance audit, a quick self-test against the questions auditors actually ask will tell you where the inventory is exposed:

  • Can you produce a single, structured inventory of information and associated assets in scope — not several disagreeing spreadsheets?
  • Does every line carry a named owner reconciled to current HR records, and would that owner confirm they own it?
  • Does every asset carry a confidentiality classification that actually drives how it is handled, stored and disposed of?
  • Can you take any device on the floor and find it in the inventory, and any inventory line and produce the device?
  • Does every confirmed line carry a recent last-verified date and a method, evidencing that the inventory is maintained?
  • Are recent joiners, leavers, moves and disposals reflected — with data-destruction certificates filed against disposed data-bearing assets?
  • Does the inventory scope match the ISMS scope and reconcile to the CMDB, MDM and the fixed asset register without large unexplained gaps?

A "no" or "not sure" against any of these is precisely where an auditor’s sampling tends to land — and exactly what an independent physical verification is designed to close.

Where CPCON fits

CPCON is not a certification body and does not issue audit opinions — the certificate decision belongs to your UKAS-accredited auditor, and our independence from that process is the point. What we bring is 30 years and 4,500+ projects of physical verification discipline: independent counts, asset tagging, owner assignment reconciled to HR, and serial-level reconciliation to your CMDB, ITAM tool and fixed asset register. The deliverable is an A 5.9 inventory that has been counted rather than asserted — defensible evidence behind your control before the auditor starts sampling, and a foundation that simultaneously serves Cyber Essentials, UK GDPR Article 30 and the fixed asset register. To turn the baseline into a maintained inventory, the same teams set up cycle counting on high-churn classes and RFID tracking where volumes justify reading a room in minutes.

Frequently asked questions

Is an asset inventory mandatory for ISO 27001 certification?

In practice, yes. Annex A control 5.9 of ISO/IEC 27001:2022 requires an inventory of information and other associated assets, including owners, to be developed and maintained. Organisations can exclude Annex A controls only with justification in the Statement of Applicability, and excluding the asset inventory is close to unjustifiable — most other controls (access, acceptable use, return of assets, endpoint security, secure disposal) presuppose you know what assets exist. An auditor who sees A 5.9 marked "not applicable" will treat it as a red flag for the whole ISMS.

What changed between ISO 27001:2013 and the 2022 edition for asset inventories?

The 2013 edition had separate controls for the inventory (A.8.1.1) and ownership (A.8.1.2), plus acceptable use (A.8.1.3) and return of assets (A.8.1.4). The 2022 edition merges inventory and ownership into a single organisational control, A 5.9: the inventory must be developed and maintained and must include owners. There are now 93 controls in four themes (organisational, people, physical, technological) rather than 114 in 14 clauses. All certificates have been on the 2022 edition since the transition deadline passed in October 2025, so auditors now test inventory and ownership together against the new wording.

How do certification auditors actually test the inventory?

By sampling in both directions. Floor-to-record: the auditor picks devices in the office or comms room and asks you to find them in the inventory, with the right owner and location. Record-to-floor: the auditor picks inventory lines and asks to see the asset. They also probe maintenance — recent joiners, leavers and disposals — to see whether the inventory reflects them, and they cross-check the inventory against the scope in the Statement of Applicability and the risk assessment. Stale "last verified" dates, missing owners and unexplained mismatches typically surface as minor or major nonconformities.

Does a CMDB or discovery tool satisfy Annex A 5.9 on its own?

It helps, but it is rarely sufficient as evidence. Discovery and MDM tooling only see powered, connected, enrolled devices — they miss stored, offline and unreturned equipment, and they say nothing about non-digital information assets in scope such as paper records or know-how. Auditors know this, which is why physical sampling is standard. A periodic physical verification reconciled to the CMDB is what demonstrates the inventory is complete and maintained rather than merely populated.

What does the standard expect for asset ownership?

A 5.9 requires an owner for each asset or group of assets, and ISO/IEC 27002:2022 expands on what ownership means: the owner is accountable for the asset over its lifecycle — ensuring it is inventoried and classified, defining and reviewing access restrictions, and handling it correctly on transfer or disposal. Ownership can sit with an individual or a role, and assets can be grouped sensibly so you are not naming an owner for every cable. What auditors will not accept is "IT" as a blanket owner for the whole estate, or owner fields left blank.

How does the asset inventory connect to the risk assessment?

ISO 27001 clause 6.1.2 lets you choose your risk assessment method, but most organisations still identify risks against assets or asset groups, and even where the method is scenario-based the inventory is what bounds the scope of analysis. Classification (confidentiality, integrity, availability) drives the protection level, and the controls you select in the Statement of Applicability are applied to assets. An inventory that is incomplete or misclassified therefore undermines the risk assessment beneath it — which is why auditors trace from inventory to risk and back.

Can the same inventory support Cyber Essentials as well?

Yes — and it should. The Cyber Essentials self-assessment requires you to declare the devices in scope, including make and operating system, and unsupported operating systems in scope mean failure. Cyber Essentials Plus adds independent testing of a device sample. One well-maintained, physically verified device inventory feeds the ISO 27001 evidence, the Cyber Essentials declaration, UK GDPR Article 30 records and the fixed asset register at the same time, instead of four lists that disagree.

How does CPCON help if you are not a certification body?

CPCON does not issue certificates or audit opinions — that decision belongs to your UKAS-accredited certification body, and our independence from it is the point. What we deliver is the inventory evidence the standard asks you to produce: an independent, wall-to-wall physical verification of the device estate, asset tagging, owner assignment reconciled to HR, and a serial-level reconciliation to your CMDB, ITAM tool and fixed asset register. The result is an A 5.9 inventory that has been counted rather than asserted, ready for the auditor to sample.

How long does a baseline inventory take, and how is it kept current?

A baseline for a single mid-sized office is usually a matter of days in the field; multi-site estates are phased. The count is the start, not the end. Keeping A 5.9 satisfied between audits means wiring the inventory into joiner, mover, leaver and disposal processes so it updates at the moment of the event, running cycle counts on high-churn classes such as laptops and mobiles, and scheduling a standing physical-to-CMDB reconciliation. That is what turns a one-off snapshot into the "maintained" inventory the control actually requires.

Need your device inventory verified before the audit?

CPCON physically verifies, tags and reconciles IT estates across the UK — talk to a specialist about an audit-ready baseline.

Request a Proposal