What A.5.9 asks for and why auditors sample the register
An auditor asks for the asset register and wants to know whether it matches the environment. A.5.9 requires the organization to develop and maintain an inventory of information and other associated assets, including their owners, so that it can identify what it holds and keep those assets secure. The owner is the point of the control: every entry needs a named person accountable for its protection, not just a line in a spreadsheet. Information assets are the data itself, such as customer records, source code, backups and exports. Associated assets are the things that store, process or transmit that information, including servers, endpoints, cloud accounts, SaaS applications, network devices, removable media and the software licenses that run them.
The risk of unknown assets is that a control cannot protect what the organization does not know it has. A forgotten test database, a SaaS tenant opened on a corporate card or a server that missed patching are all outside the security program until someone finds them, often during an incident. The register is hard to keep accurate because assets appear and disappear continuously: cloud resources are created by pipelines, engineers adopt tools without asking, and laptops change hands. A register that was complete at the start of an audit cycle can be stale within weeks. Compare it with actual discovery data from directories, cloud consoles, endpoint agents and network scans before you trust it.
ISO/IEC 27001:2022 merges two 2013 controls, A.8.1.1 Inventory of assets and A.8.1.2 Ownership of assets, into this single control. If your evidence still reflects the older split, map each old record to the new control and confirm the ownership field is populated for every entry. Ask your certification body how it will sample the register, typically by picking entries from the list and tracing them to the real system, and by picking systems from the environment and checking they appear on the list. Confirm the scope of the inventory with your own risk assessment and the controls in ISO/IEC 27002:2022, which gives implementation guidance for this control.
What belongs in the ISMS asset inventory
A.5.9 asks for an inventory that names every asset in scope and its owner, so the organization can protect what it holds. The categories below are the decisions that change how large the inventory is and who keeps it current, so settle them before anyone starts listing items.
Information assets and records
These are the data sets the ISMS exists to protect: customer databases, file shares, document repositories, backups and retained records. Record each one as a named information asset with an owner, a location and a pointer to its classification, because A.5.12 handling rules depend on it. Check that the list covers data copied into analytics tools, exports and spreadsheets, since auditors often find these outside the official register. Confirm with each owner which copies are authoritative.
Physical and virtual infrastructure
Servers, endpoints, network devices, storage arrays and virtual machines form the processing base that holds the information assets. Track them by hardware identifier and host name, along with their location, the business service they support and the person responsible for patching and configuration. A stale record for a decommissioned host is a common finding, so tie inventory updates to the provisioning and retirement process. Automated discovery can supply the raw list, but a named owner still has to accept each entry.
Cloud accounts and SaaS applications
Cloud subscriptions, projects, managed databases and software-as-a-service tenants often sit outside the team that manages on-premises kit. Record the account or tenant, the business owner, the administrators and the data types stored in each. Include shadow SaaS discovered through expense records or single sign-on logs. Assets that are not in the inventory can still store regulated data, so ask who can create new accounts and whether that step feeds the register.
Software, licenses and media
Installed applications, operating system builds, licensed software and removable or archival media are associated assets that carry both vulnerability and licensing exposure. Record the product, version and installation point, and link each entry to the endpoint or service it runs on. Portable drives, tapes and retired disks belong in the list until they are wiped or destroyed under the disposal procedure. Auditors often test whether a sample of media can be traced to a named owner and a current location.
Third-party hosted assets
Assets operated by suppliers, such as a managed hosting provider, a payroll processor or a contractor's laptop used on your network, still affect the organization's security. Record them in the inventory with the supplier as custodian, and cross-reference the contract and the supplier-relationship controls that govern them. Confirm which assets the supplier is contractually obligated to list, because the two registers should agree at the points where responsibility is shared.
Boundary and granularity
Set the inventory boundary against the ISMS scope in the statement of applicability, so every asset inside that boundary is listed and nothing outside it is recorded by accident. Choose a level of detail that owners can keep current, for example one entry per business service rather than per file. Document the rule in a short procedure, and sample both directions during internal review: items in the scope that are missing, and entries with no current owner or no matching live asset.
How the inventory is built and kept current
Automated discovery is the most reliable way to find hardware, operating systems, installed software and network presence on endpoints, servers and cloud accounts. Agents and connectors report what is actually running, which makes this source the best check against what the organization believes it owns. Discovery does not know who owns an asset or what information it holds, so its output is an input to the inventory rather than the inventory itself.
- Endpoint and server agents: Confirm which agents report from which hosts, and which hosts have no agent at all.
- Cloud account connectors: Confirm which accounts, subscriptions and projects are connected, and whether new accounts are added to scope automatically.
- Network discovery: Scans can reveal devices that never check in, but they need scheduled runs and approved scan ranges.
- Collection gaps: Note what the tools do not collect, such as data stores, SaaS applications and physical media.
- Stale discovery records: A host that stopped reporting should be flagged, not silently kept.
Confirm the exact asset types, collection intervals and retention settings of any discovery tool in your own environment before relying on its output as audit evidence.
Some assets never appear in a scan. Information assets such as databases, document repositories, shared mailboxes, contracts, backup sets and paper records need a person to register them, usually with the business context that discovery cannot supply. Manual registration is where the owner is named, the classification is recorded and the purpose of the asset is explained, so it carries the most governance weight in this control.
- Registration form: Capture the asset name, type, location, business purpose, information held and named owner in one standard template.
- Owner confirmation: Require the owner to acknowledge the entry, not just the security team to create it.
- Change triggers: Require an update when a system is upgraded, moved, outsourced or retired.
- Supplier-hosted assets: Record assets held by suppliers and link them to the supplier agreement that governs them.
- Ownership transfers: Record reassignment when an owner changes role or leaves.
Ask for a sample of registrations and check whether each owner can explain what the asset holds without consulting the security team.
Reconciliation compares discovered assets against registered assets and resolves every difference. Discovered but unregistered items need an owner or a decision to retire them. Registered but undiscovered items need an explanation, because they may be retired, offline, supplier-hosted or simply missing a discovery agent. This comparison is what turns two partial lists into one inventory that an auditor can trust.
- Scheduled comparison: Run the comparison on a fixed cycle and keep the output as a dated record.
- Exception queue: Track each unmatched item to a named owner and a closure date.
- Duplicate handling: Merge records that describe the same asset from different sources, such as a host name and an asset tag.
- Decision record: Keep a note of why an item was retired, accepted as out of scope or assigned to a new owner.
- Accountability: Name the person who signs off the reconciliation, separate from the people who maintain the entries.
Ask to see the last reconciliation output and how long its exceptions stayed open.
An inventory is only as current as the people accountable for its entries. Owners are the people who decide how an asset is used, protected and retired, and they usually sit in business or technology teams rather than in security. The security function sets the rules and checks the records, while owners keep their own entries accurate. Stale entries are the usual reason an inventory fails an audit sample.
- Owner role: Owners approve classification, confirm the entry each review cycle and report changes.
- Custodian role: The team that operates the asset may differ from the owner and should be recorded separately.
- Stale signs: Entries with no recent review, owners who have left, hosts that no longer report and asset names that match no live system.
- Orphaned assets: Assets with no owner should be escalated, not left open.
- Review cadence: Set a review interval in the procedure and show that it was followed.
Confirm with your team how owner reviews are scheduled and recorded, and whether departed staff are removed from owner fields as part of the leaver process.
How an assessor tests the asset inventory
This table compares the four main sampling tests an assessor runs against A.5.9, the evidence each one asks for, and the findings that most often appear. Read each row as a test: start from live discovery and work back to the register, then go the other way from register entries to reality. The main takeaway is that an inventory passes only when the register and live environment agree and every entry has a named, active owner.
| Test | Evidence requested | Common findings |
|---|---|---|
| Live discovery back to the register | Discovery scan or agent output for a sample period, the register export, and the reconciliation between the two | Endpoints, servers or network devices seen live but absent from the register; scan coverage gaps in some network segments |
| Register entries forward to reality | Sample of register entries with evidence the asset exists, such as a serial number, host record, or cloud resource ID | Retired systems still listed; duplicate records for one asset; entries with no hostname, location or identifier |
| Owner confirmation and acceptance | Owner assignment records, acceptance or attestation by each owner, and dated review records | Missing or departed owners; owners who have never reviewed their assets; shared owners such as a team mailbox with no accountable person |
| Link to classification and risk assessment | Classification labels on sampled assets, risk register entries that reference them, and the rule used to assign each label | Assets with no classification; risk assessments that cover systems missing from the inventory; classification applied inconsistently across similar assets |
| Cloud and SaaS resources | Cloud account inventory exports, tag or ownership policy, and SaaS application list from procurement or identity records | Unregistered cloud resources in test or development accounts; SaaS tools adopted without being recorded |
| Scope currency | Current statement of ISMS scope, the date of the last inventory review, and change records for new sites or services | Outdated scope that omits new business units, acquisitions or recent migrations; inventory last reviewed before a major change |
Implementing A.5.9 step by step
This sequence turns A.5.9 from a policy statement into a working register: a defined scope, named owners, discovered assets, reconciled records and an approved procedure that keeps the inventory current. Each step produces a record an assessor can sample.
Define inventory scope and fields
Decide which categories of information and associated assets belong in the inventory, such as hardware, software, cloud services, information repositories, data flows and licences, and set the minimum fields each record must carry. Typical fields include asset identifier, description, location, classification, owner, custodian, lifecycle status and the systems it supports. The output is a register template and a short scope statement approved by the ISMS owner. Confirm the scope against the asset categories named in your Statement of Applicability and risk assessment before you move on.
Assign and record asset owners
Name one accountable owner for each asset or asset group, usually a business or system leader who can approve access and decide how the asset is used and disposed of. Owners are distinct from the technical administrators who maintain the asset. Send each owner the list of assets they hold and collect a written acknowledgement that confirms ownership and their responsibilities. The output is the signed acknowledgement set, with the owner field populated for every register entry that has no owner gap.
Run automated and manual discovery
Populate the register from more than one source, since no single tool sees everything. Use endpoint agents and network or cloud discovery for hardware and software, and interview business units and procurement for SaaS subscriptions, shadow tools and information repositories that automated scans miss. Open-source options such as GLPI can hold the assets module and receive agent-based inventory, and Wazuh's Syscollector can report installed software, services, users and open ports from endpoints. Record which source produced each entry so the origin of every record can be shown.
Reconcile discovered and declared records
Compare the discovered data with the register and the owner-declared list, then resolve each difference. Typical outcomes are a missing asset that must be added, a stale record that must be retired, a duplicate to merge, or a discovered item with no owner that must be escalated. Keep a reconciliation record showing each difference, the decision taken, who decided and the date. Assessors often sample this record to test whether the inventory matches reality, so keep the exceptions visible rather than deleting them.
Set review and update triggers
Define the events that must update the inventory, such as new procurement, onboarding, a change of owner, a cloud account change, a decommission or a significant system change, and set a periodic review of the whole register. Link the triggers to the change management and joiner, mover and leaver processes that already run in the organization, so updates happen as part of normal work. The output is a trigger table and a review calendar. Confirm the review interval with your own risk appetite and any contractual or regulatory commitments you carry.
Approve the inventory procedure
Write the procedure that covers scope, fields, owner duties, discovery sources, reconciliation, triggers and retention of records, then have the ISMS owner and an accountable executive approve it. Store the approved version in the document control system so that the current version and its approval date can be shown. Brief owners and custodians on their part of the procedure. The output is the approved procedure, its version history and training or briefing records. Mark the procedure as operational so that it is tested through the later checks under A.5.36 and A.5.37.
Evidence that passes an A.5.9 audit
An auditor testing A.5.9 wants to see one inventory that matches reality and a record of how it was kept that way. The cards below cover the register itself and the supporting records that show it was built, reconciled, owned and reviewed over time, with the routine that keeps each one current between audits.
Dated register export
The inventory itself, exported with a date and a version number, showing each asset's identifier, type, location, owner and classification. Auditors compare the export against the date of the sample they pick, so an undated spreadsheet is weak evidence. Check that every field the organization claims to track is populated, and that blank owner fields are explained rather than ignored. Keep a dated export at each review point so the history can be shown, not just the latest version.
Automated discovery reports
Scan and agent reports that show what is actually running on the network, compared with what the register lists. For example, an agent-based tool can record installed software, open ports and network interfaces per endpoint, and that output becomes the independent view the register is tested against. Keep the discovery configuration, scan scope and run dates, because an auditor will ask whether the scan covered the whole estate. Discovery reports that only cover servers do not show that endpoints or cloud resources were considered.
Reconciliation records
Records of the comparison between discovery output and the register, listing assets found but not recorded, recorded but not found, and mismatches in owner or location. Each difference should carry a disposition: added, retired, or explained with a reason. A reconciliation that shows zero differences every cycle is more likely to draw questions than one that shows real gaps and how they closed. Confirm the reconciliation frequency with your own risk assessment and keep the records dated.
Owner sign-off records
Evidence that each asset or group of assets has a named owner who accepted responsibility for it. A.5.9 requires owners to be included in the inventory, so auditors sample entries and ask the named person to confirm the asset, its purpose and its classification. Sign-offs can be recorded in the register, a ticket or a signed attestation, but each must show the person, the date and the asset. Owners who have left the organization should be reassigned, and that reassignment should be visible in the records.
Onboarding and retirement change records
Change tickets that show assets being added to the inventory when they are commissioned and removed when they are decommissioned or disposed of. Auditors often pick a recently retired asset and check whether it was closed out in the register and whether its data was handled. Link each register entry to the change or procurement record that created it, and to the disposal certificate or decommission record that closed it. Gaps between provisioning dates and register entries are the most common findings in this area.
Inventory review history
A log of scheduled reviews of the inventory, who performed them, what changed and what was escalated. The review history shows that the inventory is maintained as a process rather than a one-time project. Set the review interval in your own inventory procedure and confirm that the reviews happen on that schedule, because a missed review is easy for an auditor to find. Record each review with its date, reviewer and outcome so the sequence of reviews is visible from one end of the audit period to the other.
What meeting A.5.9 costs in money and effort
This table compares the main cost components of keeping an A.5.9 asset inventory accurate, showing who is paid, whether each cost is one-time or recurring, what drives it up, and how to keep it down. Use it to structure a quote request, since no price figures are published for this control. The main takeaway is that licence spend is often the smallest recurring item, while owner time and evidence upkeep decide whether the inventory stays accurate.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Discovery tooling or licences | Recurring licence or subscription, plus one-time setup | Number of endpoints, cloud accounts and network segments in scope; per-device or per-user pricing models | Use self-hosted open-source inventory tools such as GLPI and Wazuh to remove most licence spend; confirm agent and support terms in writing |
| Engineering time to integrate sources | Mostly one-time, with ongoing effort when sources change | Number of asset sources (CMDB, cloud APIs, MDM, hypervisors, network scanners) and how many need custom connectors | Start with the sources that already hold authoritative data and document which system is the record of truth for each asset type |
| Owner time for reviews and assignments | Recurring, at each review cycle and each join or move event | Number of assets without a named owner, size of the organization, and how often ownership changes | Assign owners by role or service rather than by individual where possible, and tie ownership to HR and procurement events |
| Evidence upkeep | Recurring, at each inventory review and before each audit | How often the inventory is exported, versioned and reconciled against discovery data; how many reconciliation exceptions occur | Automate exports and dated snapshots, and record reconciliation decisions in the same place as the inventory |
| Auditor sampling effort | Recurring, at each surveillance or recertification audit | Number of asset records an auditor samples, the number of unmanaged discoveries found, and the completeness of owner fields | Run a reconciliation before the audit, and ask the certification body in advance which sampling approach it uses |
| Preparation support from an implementation partner | One-time for design and build, optional recurring for reviews | Scope agreed in writing, number of sites and integrations, and whether the partner also runs the tooling | Request a fixed-scope quote with named deliverables, and confirm which parts the organization must keep in-house |
| Hosting and infrastructure for self-hosted tools | Recurring, from the organization's own cloud or data center budget | Size of the discovery data set, retention period and redundancy requirements | Size the database and retention to the data actually needed, and confirm backup and upgrade responsibilities up front |
Who owns the inventory and who can help
The organization owns A.5.9 in full. Named owners must be accountable for the assets they hold, and the people who maintain the inventory must be able to change it when reality changes. Management approves the scope of the inventory and the rules for what counts as an asset, because those decisions define what an auditor will test against.
- Accountable owners: Each asset or asset group has a named owner recorded in the inventory, such as a business owner for an application or a service owner for a data store.
- Custodians: Platform or IT teams maintain the technical record for hardware, cloud resources and software, and confirm changes.
- Approval: The information security function or ISMS owner approves the inventory scope, the attributes recorded for each asset and the review cycle.
- Procedures: Staff document how assets are added, changed, retired and reconciled, so that the process does not depend on one person.
- Ongoing accuracy: Owners confirm their entries at set intervals and after significant change.
Confirm that your own owners can name what they are responsible for before any tool is selected, because no tool can assign accountability on your behalf.
An implementation partner can deploy and configure the systems that hold the inventory, connect discovery sources and draft the procedures that describe how it is run. The partner prepares systems and evidence but does not decide what the organization owns, who is accountable for it, or whether the inventory is adequate. DeployOpen works this way when scope and deliverables are agreed in writing before work starts.
- Tool deployment: Installing and hardening a self-hosted asset register such as GLPI inside the client's own infrastructure.
- Discovery integration: Connecting agents or collectors, for example Wazuh Syscollector, so that endpoint data flows into the inventory and can be compared with the register.
- Procedure drafting: Writing inventory procedures for the client to review, approve and own.
- Evidence preparation: Setting up exports, reports and reconciliation records that the client can show an auditor.
- Handover: Documenting configuration and training staff so the client can operate the system without the partner.
Ask for the written scope to state which items the partner delivers and which remain with your team, and confirm that no part of the ownership decisions is delegated to the partner.
An independent auditor or certification body tests whether the inventory exists, is maintained and matches the environment. The auditor selects samples, compares records with systems and interviews owners, then gives an opinion. The auditor does not build the inventory, configure the tools or write the procedures for the organization, because doing so would compromise independence.
- Sampling: The auditor picks systems from the network, cloud accounts or endpoint population and checks whether each appears in the inventory with an owner.
- Reverse sampling: The auditor takes inventory entries and checks that the recorded assets still exist.
- Owner interviews: The auditor asks owners to explain their assets and the review they perform.
- Records review: The auditor examines change history, review records and the approved scope.
- Opinion only: The auditor reports findings and nonconformities. It does not issue the inventory or certify its completeness in advance.
Before engaging an auditor, confirm with them in writing which parts of the inventory they will sample and what they will accept as evidence.
Where asset inventories fall short at audit
Auditors rarely reject an asset inventory because it is short. They test whether it matches what actually runs, who answers for each entry, and whether anyone checks the two against each other. The cards below cover the gaps that most often surface when an assessor samples the register against live systems, accounts and information flows.
Shadow SaaS and unmanaged cloud accounts
Business teams often sign up for SaaS tools and open cloud subscriptions on corporate cards without going through IT. These services hold customer data and configuration but never reach the register, so A.5.9 is not met for them. Check expense records, identity provider application logs and cloud billing accounts against the inventory, then record each service with its owner and data types. Action: run a discovery sweep across billing and single sign-on sources this quarter and log every unregistered service.
Owners who never confirmed
An owner field filled in during a one-off import is not evidence of ownership. Assessors ask the named person what they own and what they can change or retire, and a vague or departed name is a finding. Owners also drift as people move roles, so the record needs a date of last confirmation. Action: send each owner their list of assets, require a written confirmation, and remove entries whose owner cannot be reached.
Information assets missing from the register
Most registers list servers, laptops and software but omit the information itself: customer databases, backup sets, contracts, source code repositories and exported reports. A.5.9 covers information and other associated assets, so an inventory limited to hardware leaves the core asset class untracked. Check whether each system entry names the information it holds and the classification it carries. Action: add an information asset record for every system that stores regulated or confidential data.
Software and virtual assets without records
Containers, virtual machines, service accounts, API keys and third-party components are created and destroyed faster than a manual register can follow. Records that are not refreshed show decommissioned systems still listed and new ones absent. Agent-based collection, such as the Syscollector module in Wazuh, can gather installed software, services, users and open ports from endpoints, which gives assessors a machine-generated comparison point. Action: confirm which endpoints and servers the discovery tool covers and document any gaps.
No reconciliation record
An inventory that is never compared with the systems it describes cannot show accuracy. Assessors look for a dated record of reconciliation, the discrepancies found, and who resolved them. Without this trail, the register is an assertion rather than evidence. Action: schedule a periodic reconciliation between discovery output and the register, keep the signed results, and track each exception to closure.
A.5.9 questions buyers ask before hiring help
How long does it take to build an asset inventory for ISO 27001 A.5.9?
No supplied figure fixes a duration, and the honest answer depends on how many asset sources exist and how mature they are. The work runs in three parts: discovering what is in use, assigning an owner to each item, and proving the list stays accurate. Ask any partner for a written plan that names the systems in scope, the discovery sources (directories, cloud accounts, endpoint agents, network scans, procurement records), and the point at which the owners sign off. A fixed-scope engagement agrees these deliverables and dates before work starts, so the timeline becomes a commitment you can review rather than an estimate you have to take on trust.
Can a small team build the A.5.9 inventory without outside help?
Often yes, provided the team has the time and a clear owner for the inventory. A small team can usually cover the core assets quickly, but the effort lies in keeping the list current, assigning owners who accept accountability, and recording the decisions an assessor will ask about. Tools such as GLPI and Wazuh can automate much of the discovery, with GLPI's Assets module covering computers, software, network equipment and more, and Wazuh's Syscollector collecting hardware, software, services and users from each endpoint. Confirm with your own environment which assets sit outside those agents, such as SaaS accounts, contractor laptops and cloud resources, because those gaps are where inventories usually fail.
What does the partner need from our team to start?
A partner needs access and decisions more than documents. Expect to provide read access to the systems that hold asset data, such as directories, cloud management consoles, endpoint management and procurement records, plus a named sponsor who can settle disputes about ownership. Your team should also confirm which business units and locations are in scope and agree the classification approach that determines which assets are critical. Ask the partner to list these requirements in writing before kickoff so that delays are visible early and attributed correctly.
What drives the cost of an A.5.9 inventory project?
The main cost drivers are the number of asset types, the number of locations and business units, the state of existing records, and how much cleanup is needed before the list can be trusted. Ongoing costs depend on how often the inventory must be reviewed and whether discovery tools are already in place or need to be deployed. Ask any provider for a quote that separates one-time work (discovery, deployment of agents or connectors, initial owner assignment, documentation) from recurring work (reviews, updates, tool upkeep and support). Also ask who pays for licenses and whether your organization or the partner owns the tooling after handover.
Can the partner sign off the inventory as compliant with ISO 27001?
No. Only an independent auditor or accredited certification body can judge conformity and issue a certificate. A partner can build the inventory, define the process, prepare the evidence and help you rehearse the questions an auditor asks, such as how an asset was found, who owns it and when it was last reviewed. The organization remains responsible for its controls and for accepting the inventory as its own record. When you evaluate a partner, ask for the evidence package they will deliver and confirm that the certification body you intend to use accepts it before work starts.
Which parts of A.5.9 should we keep in-house?
Keep ownership decisions, risk acceptance and final approval of the inventory in-house. Asset owners must be people inside the business who understand what their systems do and what happens if they fail. An external partner can design the discovery approach, configure tools, reconcile data sources and document the process, but it should not become the named owner of assets it does not run. Agreeing this split in the statement of work avoids the common problem where an inventory exists on paper while nobody inside the organization acts on it.
How does the inventory connect to the other controls auditors test?
A.5.9 feeds several other controls, so an inventory that is not maintained undermines them. The list shows what must be classified under A.5.12, which assets must be returned under A.5.11, and which systems are covered by acceptable use rules under A.5.10. Auditors often sample the inventory against reality, picking systems from the network or cloud console and checking that each one is listed with an owner. Confirm with your partner how records will be kept so that a single sample traces through several controls without gaps.
How DeployOpen prepares the A.5.9 inventory
DeployOpen helps organizations build an asset inventory that lists information and associated assets with named owners, and keeps it in step with the systems that feed it. The organization still owns its inventory and decides what counts as an asset, while DeployOpen prepares the systems, records and evidence an independent auditor samples.
How we scope
- The written scope names the asset categories, sites, cloud accounts and business units the inventory must cover.
- Scope records which owner role is accountable for each asset category and how ownership is confirmed.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any work starts.
How we build
- Discovery tools such as GLPI and Wazuh are deployed inside the client's own infrastructure to collect hardware and software records.
- Asset fields for owner, classification and location are defined so each record can be checked against a named accountable person.
- Test runs compare discovered records with a sample of known systems to find gaps before the inventory is relied on.
How we hand over
- Handover includes the configured inventory platform, documented procedures for adding, changing and removing assets, and owner assignment records.
- Documentation explains how each inventory export was produced, so an assessor can trace a sampled asset back to its source.
- The client's staff are trained to review stale records, resolve unowned assets and run the periodic reconciliation themselves.
How we support
- Ongoing support, upgrades and continuous checks of inventory accuracy are available as a retainer.
- Retainer work can cover new platforms, acquisitions and cloud accounts that must be added to the inventory.
- Confirm with DeployOpen during scoping which evidence the auditor will request, since the certification body, not DeployOpen, issues any report or certificate.
