Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.
All frameworks →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →An inventory is not a list of laptops. It is the sampling frame an auditor draws from and the scope boundary your whole program rests on. What has to be in it, who owns each row, and what keeps it from going stale.
An asset inventory is the sampling frame for a large share of your audit. Endpoints, servers, network devices, SaaS applications and data stores all get sampled from it, and the scope of your report is defined against it. The field that determines whether it works is the owner, because an asset with nobody against it cannot be sampled: there is no one to ask whether it is encrypted, still in use, or should have been wiped a year ago. Build it from system exports rather than by hand, give every row an owner and an in-scope decision, and wire it to the joiner and leaver process so it updates as a side effect of work people already do.
Most teams build an asset inventory because a checklist told them to, then never use it again, and it is stale within a quarter. That happens because the purpose was never clear. The inventory is not a compliance artifact in its own right. It is the frame that three other things depend on.
The first is scope. Your report boundary, your ISMS boundary, and the systems your buyers think you are attesting to are all defined against a set of assets. If the inventory is wrong, the scope statement is wrong, and every control claim inside it inherits the error.
The second is sampling. An auditor testing endpoint encryption does not test encryption in the abstract. They ask for the population of endpoints, pick some, and ask you to show the encryption state of those specific machines. Same for servers and patching, for SaaS applications and access reviews, for data stores and retention. The inventory is where the population comes from, and an incomplete inventory produces a sample drawn from an incomplete population, which is a completeness finding rather than a control finding.
The third is risk. A risk assessment that is not anchored to assets is a list of generic threats. Anchoring it to real assets with real owners and real classifications is what makes the risk register drive work rather than decorate a binder, which we cover in the risk assessment guide.
ISO 27001 is explicit about wanting an inventory of information and other associated assets, and separately about the endpoints people work on. SOC 2 does not name an inventory as a criterion, but you cannot demonstrate logical access, change management, or configuration controls over a population you have not defined, so the auditor arrives at the same requirement from the other direction. Our post on the asset inventory for SOC 2 covers why it comes up in that audit. This guide is about keeping it accurate once it exists.
The scoping question is not "what do we own". It is "what would compromise, loss, or unavailability of this thing affect the commitments we are making". Answer that per asset and the boundary draws itself.
Practically that means anything that stores or processes in-scope data, anything that can reach something that does, and anything that grants access to either. A developer laptop with a production database credential in a config file is in scope even though it holds no customer data itself, because the reachability is the exposure. A marketing analytics account with no customer records and no network path is arguably out, and the reason for that decision is what goes in the record.
Every asset needs an explicit in-scope decision: yes, no, or a stated reason. What you want to avoid is the third state that most inventories are full of, which is a blank. A blank is not an exclusion, it is an unanswered question, and an auditor reads it as an omission. The useful discipline is to treat unscoped rows as a work queue and drive the count to zero, the same way you drive unowned rows to zero.
Sites matter here too if you hold any. ISO 27001 certifies named sites and the certification body samples them, so physical assets and the location field on each asset need to be right. If you are fully remote, that is a scope decision to record and defend rather than a blank, and it changes which physical controls apply.
An inventory with two columns is a list. An inventory that supports an audit needs enough per row that somebody can answer a question about that asset without going to find a person. The fields that earn their place are the name, a stable identifier such as a serial number or a resource identifier, the type, the owner, the location or site, the data classification, whether it is in scope, its lifecycle status, and the dates that bound its life.
For endpoints and mobile devices there are three more that carry disproportionate weight because they are what gets tested: whether the disk is encrypted, whether the device is enrolled in management, and when it was last seen. Last seen is the field that separates a live inventory from a historical one. A laptop last seen fourteen months ago is either lost, retired without a record, or belongs to someone who left, and all three are findings.
Classification should be a small closed set. Public, internal, confidential and restricted covers almost every company, and four values that people actually apply beat eight values that get left blank. The classification is what connects an asset to your handling rules, your retention schedule, and your encryption requirements, so a blank classification means those rules do not attach to anything.
Resist adding fields you will not maintain. A column nobody fills is worse than no column, because it looks like a control and evidences nothing. If you cannot say who will populate a field and when, leave it out.
If you take one thing from this guide, take this. The owner is the field that determines whether an inventory is usable, and an asset with nobody against it cannot be sampled, because there is nobody to ask whether it is encrypted, still in use, or should have been wiped a year ago.
Owner means a named person, not a team and not a distribution list. Teams do not answer questions. When an auditor selects a server and asks who is accountable for patching it, "Platform" is not an answer, it is a redirect. A name is an answer, and the person with their name on it behaves differently from a person in a group that collectively owns forty rows.
There is a distinction worth keeping between the owner and the custodian. The owner is accountable for decisions about the asset: what classification it carries, who should have access, when it is retired. The custodian operates it day to day. For most companies under a hundred people this distinction is overhead and one owner field is enough. For a larger estate, or where a managed service provider runs your endpoints, splitting the two prevents the argument that surfaces during fieldwork about who was supposed to have applied the patch.
Track the unowned count as a number and put it in front of whoever runs the program every month. It is one of the few compliance metrics that is genuinely leading rather than lagging: unowned rows are where stale access, missed patching and unwiped devices accumulate, and the count going up is an early signal that the feeds have broken.
Endpoints are the most sampled class in the inventory because they are the easiest to test and the most likely to be wrong. The population is every laptop, desktop, phone and tablet that can reach company data, which includes contractor machines and personal devices under any bring-your-own arrangement you permit.
The source of truth should be your device management platform, not a spreadsheet, because the platform knows the last check-in and the current configuration state. Import from it rather than typing, and reconcile the import against the HR roster: every current staff member should have at least one device, and every device should map to a current staff member or an explicit exception such as a spare or a loaner.
What gets tested on a sampled endpoint is a short and predictable list: full-disk encryption on, screen lock enforcing the policy timeout, operating system current or inside the patch window, the endpoint protection agent present and reporting, the daily-use account not a local administrator, the company password manager in use, no unapproved remote access or file sync tools, and the device enrolled in management and reporting. That list is the workstation spot check we run on engagements, and it is worth running yourself on a sample each quarter, because doing so produces a dated record with a named assessor that is itself evidence, and it finds the drift before the auditor does.
Bring-your-own devices are the awkward case. If you permit them, they are in scope and you need some enforcement point, usually application-level controls rather than full device management. If you do not permit them, you need to be able to show enforcement rather than just a policy sentence, because an auditor will ask what stops it and "the policy says not to" is not a control.
The instinct is to extend the endpoint approach to servers, and it fails immediately, because cloud infrastructure is not enumerable by hand. Instances come and go, autoscaling groups replace nodes hourly, containers live for minutes. A hand-kept list of virtual machines is wrong the day after it is written and everybody knows it, which is why it stops being maintained.
The workable approach is to shift the granularity. Inventory the durable things rather than the ephemeral ones: accounts and subscriptions, regions, VPCs, clusters, managed database instances, storage buckets, load balancers, and the services or workloads themselves. Those change on a scale of weeks, not minutes, and they are what an auditor is actually asking about. Then treat the ephemeral layer as something you enumerate on demand from the provider API rather than something you maintain in a register.
Record the query, not the answer. "The production instance population is derived from this command against this account, run at this date" is stronger evidence than a spreadsheet of instance identifiers, because it is re-derivable and the spreadsheet is not. Re-derivability is the same property that makes a sample defensible: an auditor can watch you run it, and the result either matches or it does not.
Tagging is what makes this work, and it needs to be enforced rather than requested. A tagging standard that names an owner, an environment, and a data classification, enforced at deploy time by policy so untagged resources fail or get quarantined, means your inventory is generated rather than maintained. Untagged resources are the cloud equivalent of unowned rows, and the count of them is the metric to watch.
Do not forget the parts of the estate that are not compute. Storage buckets and their public-access state, DNS zones, TLS certificates and their expiry dates, IAM roles with long-lived keys, and third-party integrations holding tokens into your accounts. Certificates in particular belong in the inventory with an expiry date, because an expired certificate is an availability incident and an incident is an audit event.
The SaaS inventory is where the biggest gap usually sits, because SaaS is bought on a credit card by whoever needs it, and no procurement process sees most of it. Companies of thirty people routinely have sixty to a hundred SaaS applications and a register listing twelve.
Three discovery sources get you most of the way. The identity provider tells you what has been connected for single sign-on. The expense and card records tell you what is being paid for, and this is the source that finds the tools nobody mentioned. The workspace admin console tells you which third-party applications staff have authorised against your tenant with OAuth, which is often the most surprising list of the three.
Each SaaS row needs the same fields as anything else, plus two of its own: whether it holds personal data, and whether it is a subprocessor you have to disclose. Those two flags are what drive the data processing agreement and the disclosure obligations on the vendor side, and they are derived from facts about the vendor rather than ticked as a checklist, which is what keeps them from drifting. The overlap between the asset inventory and the vendor register is large and deliberate, and it is covered in the vendor DPA and subprocessor register guide.
The reconciliation to run once a period is simple and it always finds something: every SaaS application in the inventory holding confidential or restricted data should appear in the vendor register with assurance on file, and should appear in the access review schedule. Anything in one list and not the others means one of them is wrong.
ISO 27001 asks for an inventory of information and other associated assets, and the word information is doing real work in that phrase. Most inventories list the containers and never the contents. Listing the laptop and not the customer database is a common and expensive omission, because the data is the thing your commitments are actually about.
A data asset row names a body of information rather than a machine: the customer record store, the payment tokens, the support ticket archive, the application logs, the HR files, the analytics warehouse, the backups. For each one you want the classification, the owner, where it physically lives including region, whether it contains personal data, the retention period, and which systems can reach it.
This register is also the backbone of your privacy work. Under Canadian privacy law and the equivalents you may be exposed to, questions about what personal data you hold, where it is, how long you keep it, and who it is disclosed to all resolve to this same list. Building it once for the ISMS and reusing it for privacy is much cheaper than building two, and the two versions drifting apart is a finding waiting to happen.
Retention is the field that most often exposes a real gap rather than a paperwork gap. Writing a retention period against the support ticket archive frequently reveals that nothing has ever been deleted, that there is no deletion mechanism, and that the policy promising deletion within a stated period is not implemented anywhere. That is a genuine finding and better discovered by you.
Every inventory is accurate on the day it is built. The question is what makes it accurate in month nine, and the answer is never discipline. It is that updating it becomes a side effect of work people already do, plus a small number of scheduled reconciliations that catch what the feeds miss.
The feeds that actually work:
The end of an asset life is tested more often than the beginning, and it is where most inventories fall apart. Acquisition is easy because somebody wanted the thing. Disposal is nobody's priority, so laptops accumulate in a cupboard with an ambiguous status and the register still shows them as active and assigned to someone who left eight months ago.
The disposal record needs the asset identifier, the date, the method, who performed it, and confirmation that the data was destroyed or the device wiped. If a third party handles it, their certificate of destruction is the artifact and it needs to reference identifiers that match your register. A certificate listing serial numbers you cannot tie to inventory rows evidences a disposal of something, which is not the same as evidence that your asset was disposed of.
Do not delete retired rows. Set a status and a retirement date and keep the history, because an auditor testing a period may sample an asset that existed during that period and no longer exists now. A row that vanished from the register cannot be explained, and deletion is the single easiest way to turn a clean disposal into an unexplainable gap.
Transfers matter for the same reason as movers in the access review. A laptop reassigned from one person to another needs a record of the reassignment and of what happened to the previous user data on it. That record is short and nobody writes it unless the offboarding checklist asks for it, so put it on the checklist.
The inventory and the risk register are supposed to be two views of the same reality, and in most programs they are two documents written at different times by different people that never mention each other. Closing that gap is one of the highest-value things you can do, and it costs an afternoon.
The mechanical version: each significant asset or asset group appears in the risk assessment, the risks recorded against it reference the asset identifier, the treatment for each risk names a control, and the control is one you have evidence for. That gives you a traceable line from an asset to a risk to a control to a piece of evidence. That line is exactly what a certification body follows when it wants to know whether your management system is real, and being able to walk it in front of them changes the tone of an audit.
The same line is what justifies your Statement of Applicability. An Annex A control included with no risk behind it looks arbitrary, and a control excluded with no reasoning looks like an omission. Anchoring both to assets and risks makes the document defensible rather than assertive. There is a worked example in our post on the Statement of Applicability.
It also works in reverse, which is the part people miss. A new asset class should trigger a risk review. The first time you deploy a model endpoint, adopt a new cloud provider, or open an office, the inventory is where that shows up first, and the risk assessment should follow rather than wait for the annual cycle.
Expect the inventory itself to be tested for completeness before anything is sampled from it, and expect that test to come from outside your register rather than inside it.
The standard completeness checks are cheap and effective. The auditor takes the HR roster and asks which device each person uses, then looks for those devices in your inventory. They take your cloud bill or your provider console and compare the resources on it to your server list. They take your expense records and compare the vendors on them to your SaaS list. Anything present in the external source and absent from your register is a completeness exception, and unlike a control exception it undermines every sample drawn from that population.
Once completeness is established, the sampling is ordinary. A number of endpoints against encryption and management state. A number of servers against patch level and configuration baseline. A number of SaaS applications against access reviews and vendor assurance. A number of retired assets against disposal records. Sample sizes vary with population size, assessed risk and the firm, but a handful to a couple of dozen per population is the usual shape.
Record your own population sizes and the method you used to select from them, so a sample can be re-derived rather than argued about. A recorded population size with a seeded, repeatable selection is defensible. "We picked a few" is not, and it invites the auditor to select their own sample, which is always more expensive in time than selecting your own.
These are the recurring reasons an inventory does not survive contact with an auditor.
Two weeks of focused work gets a usable inventory for a company under a hundred people, provided you import rather than type and you accept that the first version will be incomplete in known ways rather than complete in unknown ones.
Start with the exports, because they are free and they define reality: the device management platform, the cloud provider consoles, the identity provider application list, the expense records, and the HR roster. Load them as they come and let the register hold duplicates for a day rather than cleaning as you go.
Then assign owners, and treat that as the real work rather than a formality. This is the step that takes the time, because it requires conversations, and it is the step that determines whether the inventory is worth anything. Drive the unowned count to zero before you do anything else, including classification.
Then classify, then make the in-scope decision on every row with a reason where it is not obvious, then add the data assets by walking through where customer data actually lives with whoever built the system. That last conversation typically adds five to fifteen rows nobody had thought of and is the most valuable hour in the whole exercise.
Then wire the feeds, because an inventory without feeds is a snapshot with an expiry date. Device sync, tagging enforcement, the procurement pass, and the joiner and leaver hooks. Put the quarterly reconciliation in the calendar with a named owner, and treat a rising unowned or unscoped count as the signal that a feed has broken.
If you want the shape of what an assessment will ask for before you commit to one, the readiness checklist and the free readiness tool will tell you where your inventory sits against what gets requested. On our own engagements the core populations, including the roster and the inventory, are requested in the first days precisely because everything else samples from them.
| Field | Applies to | Why it matters and what good looks like |
|---|---|---|
| Name and identifier | All assets | A human name plus a stable identifier: serial number, resource identifier, hostname, or account. Without a stable identifier you cannot tie a disposal certificate or a scan result back to the row. |
| Type | All assets | Endpoint, mobile, server or virtual machine, network device, SaaS application, data store, other. The type decides which controls and which tests apply to the row. |
| Owner | All assets | A named person, never a team. This is the field that makes the row sampleable, because sampling means someone has to answer questions about it. Drive the unowned count to zero. |
| Classification | All assets | Public, internal, confidential or restricted. Four values people apply beat eight that get left blank. This is what attaches your handling, encryption and retention rules to the asset. |
| In scope | All assets | An explicit yes or no, with a reason where the answer is not obvious. A blank is not an exclusion, it is an unanswered question, and it reads as an omission. |
| Site or region | Physical and cloud | Where it physically is. Drives which physical controls apply and answers data residency questions from buyers and privacy regulators without a separate exercise. |
| Encryption state | Endpoints, mobile, data stores | Sourced from the management platform or the provider, not asserted. This is one of the most frequently sampled attributes in the whole inventory. |
| Management enrolment | Endpoints and mobile | Whether the device is enrolled and reporting. An unenrolled device is unmanaged by definition, whatever the policy says about it. |
| Last seen | Endpoints, mobile, servers | The field that separates a live inventory from a historical one. A device not seen in months is lost, retired without a record, or belongs to a leaver. |
| Status and dates | All assets | Active or retired, with acquired and retired dates. Never delete a retired row: an auditor may sample an asset that existed during the period and no longer exists now. |
| Personal data flag | SaaS and data stores | Whether the asset holds personal data. Drives the data processing agreement, the subprocessor disclosure, and most of the privacy register, so it should be set deliberately rather than left blank. |
| Retention period | Data stores | How long the information is kept and what deletes it. Filling this in is what usually reveals that the deletion promised in a policy is not implemented anywhere. |
Not as a named criterion. The Trust Services Criteria do not include a line item called asset inventory the way ISO 27001 Annex A does. In practice you cannot demonstrate logical access, change management, or configuration management over a population you have not defined, so the auditor asks for the population and you end up needing the same thing. Scoping the report also requires a defined boundary, and a boundary is a set of assets. Companies that skip the inventory generally discover during fieldwork that they are building one under time pressure.
Change the granularity rather than trying harder. Maintain the durable layer as a register: accounts and subscriptions, regions, networks, clusters, managed databases, buckets, and the services themselves. Treat the ephemeral layer as something you enumerate on demand from the provider API, and record the query rather than the answer. A re-derivable command is stronger evidence than a list of instance identifiers, because the auditor can watch you run it and see the current truth. Enforced tagging at deploy time is what makes the whole approach work, because ownership is captured at creation.
For a small company, yes, provided it is fed by exports rather than typed and it is reconciled on a schedule. What kills spreadsheet inventories is not the format, it is that nothing updates them, so they are accurate on the day they are made and quietly wrong from then on. If you are using a spreadsheet, the two things to add are a last-reconciled date on the sheet itself and a rule that the device rows are replaced from a management platform export rather than edited by hand.
An information asset is a body of data rather than a machine: the customer record store, the payment tokens, the support ticket archive, the application logs, the HR files, the backups. Most inventories list the containers and skip the contents, which is the more important half, because your commitments are about the data rather than about the hardware. Each information asset needs a classification, an owner, a location including region, whether it contains personal data, a retention period, and a note of which systems can reach it.
Quarterly for the reconciliation, and continuously for the feeds. The reconciliation is the scheduled check that catches what the automation missed: roster against devices, inventory against the vendor register, inventory against the access review schedule, and a sweep for unowned and unscoped rows. Whatever cadence you commit to in the policy is the one the auditor will hold you to, so write a cadence you will genuinely hit rather than the most impressive one.
Decide, write it down, and be able to show enforcement either way. If you permit personal devices for company data, they are in scope and you need a control point on them, which in practice usually means application-level controls and conditional access rather than full device management. If you do not permit them, an auditor will ask what stops it, and a policy sentence is not an answer. Conditional access rules that block unmanaged devices from company data are an answer.
A dated record naming the asset identifier, the disposal method, who performed it, and confirmation that the data was destroyed or the device wiped. Where a third party handles destruction, their certificate is the artifact, and it has to reference identifiers that match rows in your register. A certificate listing serial numbers you cannot tie back to your inventory proves that something was destroyed, which is not the same as proving your asset was. Keep the retired row with a status and a date rather than deleting it.
One named person, usually whoever runs IT or the security program, with the individual asset owners accountable for their own rows. The register owner is accountable for the feeds working, the reconciliation happening, and the unowned count trending to zero. They are not accountable for knowing whether a given server still needs to exist, which is what the asset owner is for. Splitting it that way is what stops the register becoming one person guessing about four hundred rows.
traztech Workspace has every control of whichever frameworks apply to you, written in plain English, with somewhere to attach the proof. Free to use, with no card and no trial clock.
No credit card, no trial clock, no locked features. We make money when someone wants help closing the gaps, not from the Workspace.
| traztech Workspace | Other GRC platforms | |
|---|---|---|
| Licence cost | $0. Free forever, no card, no paid tier | $7,500 to $50,000 a year, on an annual contract |
| Control library, evidence register, policy templates, risk register, vendor questionnaires, readiness scoring | Included | Included |
| What it costs inside an engagement with us | $0. You need a workspace either way | Unchanged. The subscription sits on top of the fee |
| What it does to your audit quote | $11,000 off a five-figure quote on one engagement, for a documented readiness position | Nothing. The audit firm prices your readiness, not your tooling |
Pricing in the right column is what compliance automation platforms are publicly reported to charge; none of them publish a number, so treat it as a range rather than a quote. The $11,000 came off the audit firm's own number once the readiness position was documented (the engagement). Where a paid platform is the better buy, and the fuller comparison, is on the Workspace page.
We pull the populations from the platforms you already run, put an owner on every row, and wire the feeds that keep it true after we leave.
Book a strategy callWant the human version?
Jacob sends a few short, practical notes on getting security and compliance right without the months of pain. No fluff, unsubscribe in one click. Reply anytime; it reaches him directly.
From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.
Track record
Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.
At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.