What an Asset Inventory Needs to Contain for SOC 2 and ISO 27001

Direct answer: An asset inventory has to cover anything that stores, processes or transmits data in scope, with an owner and a classification for each. That includes cloud infrastructure, data stores, SaaS applications and endpoints. A list of laptop serial numbers satisfies neither framework.

What counts as an asset

Production infrastructure, including containers and serverless functions. Data stores, including the ones somebody spun up for analytics. SaaS applications holding company or customer data. Endpoints. Code repositories. Domains and certificates. Service accounts and API keys.

The SaaS list is where reality bites. Most companies discover during the first inventory that they are paying for tools nobody remembers buying, several holding customer data, none assessed as vendors.

The fields that matter

Identifier, type, owner, data classification, environment, and whether it sits inside the audit boundary. Owner and classification are the two auditors press on, because without them you cannot show that controls are applied proportionately.

Every asset needs a named person, not a team. "Platform" is not an owner. When an auditor asks who is accountable for a data store, a name is the answer.

Keeping it current

A manually maintained spreadsheet is accurate for about a fortnight. Pull cloud resources from your provider's inventory API, pull SaaS from your identity provider's application list, and reconcile quarterly. What you maintain by hand is the ownership and classification layer, which changes far more slowly than the resources.

Tie it to the access review. The same quarter you review who has access, confirm the inventory still matches reality. Two controls, one sitting.

Where it connects

The inventory drives risk assessment, access control, vendor management and incident response scoping. Every one of those depends on knowing what you have. Auditors treat a weak inventory as a signal about the whole programme, which is why it is worth doing early rather than in the last fortnight.

The free Workspace keeps the inventory beside the controls it supports, and our risk register builder is free if you want to start from the risk side instead.

Where the inventory actually comes from

Nobody builds an accurate inventory by asking people what they run. You build it by pulling from the systems that already know, then reconciling the lists against each other and investigating the differences. There are five sources worth pulling from, and each one sees a slice the others miss.

The cloud provider, at the organisation level rather than the account level. AWS Resource Explorer, Azure Resource Graph and the GCP Cloud Asset Inventory API will all enumerate across accounts or subscriptions if you query from the management account with the right role. Querying account by account is how the forgotten account stays forgotten, and there is almost always a forgotten account: the one an engineer opened with a personal card in 2022 for a proof of concept that ended up serving a customer-facing integration.

Your identity provider's application list. Every SaaS tool wired to Okta, Entra, Google Workspace or JumpCloud shows up here, along with the OAuth grants nobody approved. The OAuth list is the interesting one. It is where you find the note-taking bot with read access to every calendar, the AI meeting assistant with mailbox scope, and the browser extension somebody granted Drive access to in a hurry.

Finance. Export twelve months of card and expense transactions and filter for software vendors. This catches everything paid for outside the identity provider, which is where shadow SaaS actually lives. A twenty dollar monthly charge to a data enrichment vendor is invisible to every technical control you own and may well be receiving customer contact records.

Certificate transparency and DNS. Your registrar zone file plus a certificate transparency search on your domains will surface subdomains you forgot: the old marketing site, the staging environment left publicly resolvable, the acquired product's legacy host. These are assets whether or not you think of them that way, and an attacker enumerates them in about ninety seconds.

Device management. MDM enrolment gives you endpoints, but only enrolled ones. The gap between headcount and enrolled devices is the number worth looking at, because contractor laptops and the founder's personal machine are usually sitting in it.

The reconciliation is the work

Once you have those five lists, they will disagree, and the disagreements are the findings. A resource in the cloud provider's list with no owner tag. A SaaS application in the finance export that nobody in the identity provider has an account for, meaning somebody is logging in with a shared password. An enrolled device assigned to a person who left in March.

Budget a full working week for the first reconciliation on a company of thirty people, and expect it to be uncomfortable. It is normal to find somewhere between fifteen and forty SaaS tools when leadership expected twelve, and to find at least one production data store that nobody had classified as holding customer data because it was originally built for something else.

What you produce at the end is not a list. It is a list plus a set of decisions: this stays and gets an owner, this gets decommissioned, this gets brought under single sign-on, this one holds customer data and therefore needs a vendor assessment and a data processing agreement.

What the auditor is actually testing

Auditors do not read your inventory admiringly. They use it as a population, and the thing they are quietly assessing is whether the population is complete.

Here is how it plays out. The auditor needs to test logical access, so they ask for the list of in-scope systems, pick a sample of five, and request the user list for each. If your inventory says you have eleven in-scope systems and the sample comes back clean, fine. But if during the walkthrough your engineer mentions a database that is not on the list, the auditor now has evidence that the population was incomplete, and the completeness of every other population you gave them is in question. That is how a single missing row turns into a scope expansion and additional testing hours.

The same logic runs through the change management test, the vulnerability management test and the access review test. All of them start from a population, and the population comes from the inventory. This is why a weak inventory is treated as a signal about the entire programme rather than as one weak control: it undermines the evidence base for everything else.

Expect the auditor to try to break completeness deliberately. Common moves include asking for a cloud billing export and comparing the services billed against the inventory, asking your engineers directly in a walkthrough what they logged into this week, and picking a random production incident from your ticketing system to see whether every system named in the timeline appears on the list.

Classification schemes that survive contact with reality

Three tiers is right for almost every company under two hundred people. Public, internal, and confidential covers it, with a fourth restricted tier only if you genuinely hold something like payment card data or health records that needs different handling.

Five-tier schemes fail for a predictable reason: people cannot reliably tell tier three from tier four, so classification becomes inconsistent, and an auditor sampling ten assets finds three misclassified. Inconsistent classification is worse than coarse classification, because it demonstrates the scheme is not actually operating.

The classification must also do something. If confidential and internal assets are handled identically, with the same access model, the same encryption, the same retention and the same logging, then the classification is decoration and a competent auditor will say so. Tie each tier to concrete handling requirements before you tie it to assets. Confidential means single sign-on is mandatory, access is reviewed quarterly, encryption at rest is required and the data cannot be copied into a personal account. Write that down, then classify against it.

Where SOC 2 and ISO 27001 diverge

SOC 2 has no control that says "maintain an asset inventory". The requirement arrives indirectly through the common criteria: you cannot evidence logical access controls, boundary protection, change management or risk assessment without knowing what is in the boundary. So the inventory is load-bearing without being explicitly named, and its adequacy is judged by whether it supports the other controls.

ISO 27001 is more direct. Within the 93 Annex A controls you have an explicit expectation to maintain an inventory of information and other associated assets with ownership assigned, plus acceptable use rules, plus return of assets on termination, plus classification and labelling. That is four or five distinct controls all hanging off the same artefact, and a certification body will test each of them separately.

The practical difference: for ISO you need the labelling and the acceptable use policy and the leaver process to visibly connect back to the inventory. For SOC 2 you need the inventory to be complete enough that every other population derives from it cleanly. The underlying list is the same list. The evidence around it differs, which is worth knowing if you are doing both, because the ISO work covers the SOC 2 need but not the reverse. We go through how the two overlap in SOC 2 or ISO 27001 for Canadian startups.

Ephemeral infrastructure without going mad

The obvious objection to any inventory is that your infrastructure changes constantly. Containers live for minutes. Lambda functions scale from zero. An autoscaling group replaces every instance during a deploy.

The answer is to inventory the class, not the instance. The asset is the service, with its definition in code, its data classification, its owner and its environment. Individual task instances are output of that asset, not assets themselves. No auditor has ever asked for a list of container IDs, and any consultant telling you they need one is billing you for theatre.

The line sits at persistence and configuration. Anything that holds state, anything with its own access control, anything with its own credentials, and anything that can be reached from outside your network is an asset in its own right. A stateless worker that runs from the same image as forty siblings is one asset. An S3 bucket is one asset each, because each has its own policy and its own contents.

Serverless functions deserve a specific mention because they accumulate quietly. Functions are cheap, so nobody deletes them, and a three year old function with an over-broad execution role and an unrotated third-party API key in its environment variables is a genuinely common finding. Enumerate them, attribute them to owners, and delete the ones nobody claims.

The copies nobody counts

The category that most often gets missed is derived data. The primary database is on the list. The copies are not.

Analytics warehouses seeded from production. Backups, including the ones in a second provider and the ones an engineer takes manually before a risky migration. Log aggregation platforms, which frequently contain more personal information than anyone intended because somebody logged a full request body. Development and staging environments populated from a production dump because building realistic test data was too slow. Support tooling where agents can view customer records. CSV exports sitting in a shared drive because a customer asked for their data in 2024.

Each of those is a place customer data lives, and each therefore inherits the same classification and the same control expectations as the primary store. The dev-environment-seeded-from-production pattern is the one that most often turns into an actual finding, because the dev environment has weaker access control by design, and now it holds real personal information under weaker controls than the policy requires. You either scrub the data, or you apply production controls to dev, or you accept the risk in writing with a named signatory. All three are defensible. Not noticing is not.

Decommissioning is half the control

Every inventory process gets built around adding things and forgets removal, which is why inventories bloat and then get abandoned. Add a decommission path from the start: when an asset is retired, record the date, who authorised it, that data was destroyed or migrated, and that credentials and DNS entries were revoked. Keep the row with a retired status rather than deleting it, because an auditor asking about a system a customer mentioned wants to see that it was retired deliberately.

The leaver process is the same control from the other end. When somebody leaves, the inventory tells you every place they might have had access. Without it you are relying on somebody's memory of which tools that person used, which is how a former employee keeps a login to a monitoring platform for eight months.

What actually drives the cost of getting this right

If you are pricing help, the variables that move the number are the count of cloud accounts and subscriptions, whether infrastructure is defined in code or clicked together by hand, whether single sign-on is already in place, how many years of accumulated SaaS you are untangling, and whether there was an acquisition or a platform migration that left two of everything.

A single-account, infrastructure-as-code, single-sign-on shop can produce a defensible inventory in two or three days of focused work. A company with four cloud accounts from three eras, no consistent tagging, a legacy colocation rack and an acquired product still running on the founder's old stack is a multi-week piece of archaeology, and most of that time is spent finding owners for things rather than listing them.

The one line item that surprises people is remediation triggered by discovery. You will find a data store with public access, an unrotated key, or a SaaS tool holding customer data with no agreement in place. Fixing those is the point, but it is engineering time nobody budgeted, which is a theme we cover more broadly in the hidden costs of SOC 2.

When you should not pay anyone for this

Asset inventory is one of the tasks where hiring us is often the wrong call, and it is worth being plain about that.

If you are under about forty people, running one cloud account, with infrastructure in code and single sign-on already deployed, you do not need a consultant. You need one engineer, two days, the API queries above, and a spreadsheet with the fields the frameworks expect. The knowledge required is knowledge of your own environment, and you have more of that than any outsider will acquire in a week of interviews. Paying a firm several thousand dollars to interview your team and hand back a list your team already knew is a bad trade, and firms that lead with inventory as a standalone engagement are usually doing it because it is easy to sell and easy to deliver.

The case for outside help is narrower and mostly about untangling history rather than making lists. Multiple cloud environments from different eras with nobody left who remembers the decisions. A merger where two stacks need reconciling and neither team has visibility into the other. A situation where the inventory must be defended to a regulator or a certification body and you want somebody who has watched that conversation go wrong before. Those are real problems where an outsider adds something.

The other honest answer is timing. If your gap analysis has not happened yet, doing a heroic inventory first is premature, because you may narrow your audit boundary and discover half of what you catalogued was out of scope. Scope first, inventory second. The free Workspace holds the register while you do that, and if you want a view on whether the boundary you have drawn will hold up, tell us the shape of the environment and we will tell you plainly whether this is a job you should be paying for at all.