Build a Useful Security Inventory for a Small Team

Start with a record you can maintain

A useful security inventory is a working list of the technology and information your business depends on. It gives a small team one place to answer basic questions: What do we use? Why do we use it? Who keeps the record current? Is it still active? What do we still need to find out?

The goal is not to build an enterprise configuration-management database. It is to create enough visibility to support later decisions about ownership, priorities, access, backups, recovery, and retirement.

NIST SP 1300 advises small and medium-sized businesses to create and maintain an inventory of hardware, software, systems, and services. The FTC’s small-business guidance similarly calls for an inventory covering hardware, software, data, and services. Neither source says that filling in a table makes a business secure.

This guide adds a PlainFort-designed minimum schema for a 1–50-person team. The field set, workflow, completeness prompts, and suggested review rhythm below are editorial choices—not requirements prescribed by NIST or the FTC.

What belongs in the inventory

Use one row for each distinct item the team depends on:

Devices: company laptops, phones, tablets, network equipment, and other equipment used for work.
Software: installed operating systems, applications, utilities, and specialist tools.
Services and SaaS: hosted email, collaboration, accounting, storage, customer-management, website, and infrastructure services.
Business accounts: accounts that represent the business or control an important service. Record that the account exists, not its password, recovery code, or authentication secret.
Data stores: the places where business, customer, staff, financial, or operational information is kept.
Vendors: outside organizations the business depends on. Record the vendor’s existence and business purpose here; keep access paths, privileges, external contacts, access reviews, and removal evidence in the separate vendor access register.

These categories are a PlainFort organizing device, not a legal classification or compliance taxonomy. If an item fits more than one category, choose the category that helps your team find and maintain it, then note the ambiguity rather than duplicating the row silently.

Minimum viable inventory schema

Start with these eight fields. Add a field only when it supports a real decision and someone will maintain it.

Field	What to record, why, and where to stop
Item name	A human-recognizable name so the team discusses the same item consistently. Never record credentials, recovery codes, private addresses, or secrets.
Category	Device, software, service/SaaS, business account, data store, or vendor. This is an editorial convenience, not a compliance taxonomy.
Business use or dependency	The work or capability that depends on the item. Explain why the row matters without turning it into a numeric risk calculation.
Internal owner	The role responsible for keeping the row current. This is not a public byline or legal designation.
Sensitivity or criticality cue	Routine, important, critical, or unknown, with a short reason. This is not legal data classification, a risk score, or proof of impact.
Lifecycle state	Planned, active, changing, retiring, or unknown. The value does not prove access or data has been removed.
Last inventory review	The date someone checked that the row still describes reality. It is not an access-review date or proof of secure configuration.
Notes or uncertainty	A missing fact or follow-up question. Do not store sensitive operational detail.

For a vendor row, stop at the vendor’s existence, business dependency, internal owner, lifecycle state, and inventory review. The vendor access register—not this inventory—owns access-specific details.

Fictional example — do not copy as a completed inventory

The example below represents Example Co. and contains invented, non-production details.

Field	Fictional value
Item name	ExampleCRM
Category	Service/SaaS
Business use or dependency	Tracks prospective and current customer work for Example Co.
Internal owner	Operations lead
Sensitivity or criticality cue	Important — sales handoffs depend on it
Lifecycle state	Active
Last inventory review	2026-08-15
Notes or uncertainty	Data export owner: Unknown — follow up

For a fictional data-store item, Example Co. customer files might use Client services lead as the internal owner and keep Retention period: Unknown — follow up visible. For a fictional vendor item, ExamplePayroll might record only that payroll depends on the service, the internal owner is Finance lead, and access details belong in the vendor access register.

The example deliberately leaves uncertainty visible. A blank or an Unknown — follow up value is more useful than an invented answer.

Build the first version

1. Name one coordinator

Choose a role that will gather the first version and keep the process moving. The coordinator does not need to own every item or know every answer. Their job is to find the relevant owner, record uncertainty, and schedule follow-up.

2. Gather ordinary business records

Use sources the team already controls: purchase and renewal records, device lists, software deployment records, browser bookmarks used for work, finance subscriptions, shared process documents, backup records, and short interviews with people who perform key tasks.

This is not automated discovery. Do not claim that these records reveal every service, data flow, personal device, or shadow tool.

3. Enter known items before debating perfect categories

Create rows for the items people can name today. Give each row a business purpose and internal owner. When a category or owner is unclear, mark it as unknown and continue. Early visibility is more useful than a polished table that excludes uncertain items.

4. Add the sensitivity or criticality cue

Use a short, plain-language cue to prepare for later prioritization. For example:

Routine — temporary loss would be inconvenient but work could continue.
Important — loss would disrupt a meaningful business activity.
Critical — the team believes a core activity would stop or important information could become unavailable.
Unknown — the consequence has not been established.

This four-part cue is a PlainFort editorial method. It is not a formal risk assessment, legal classification, or universal definition. The separate security priorities guide will own the method for deciding what security work happens first.

5. Record lifecycle and review state

Mark whether the item is planned, active, changing, retiring, or unknown. Add the date the row was checked. A retiring item stays visible until the relevant later process confirms that business dependencies, data, and access have been handled; the inventory itself does not prove completion.

Run a completeness check

Do not ask only, “Which laptops do we own?” Walk through how the business operates and look for missing categories.

How does work get done?

Which devices and installed applications are used for daily work?
Which browser-based services would stop a key process if unavailable?
Which tools are purchased by individual teams or reimbursed through expenses?

Where is information kept?

Where do customer deliverables, contracts, finance records, staff records, source files, and backups live?
Are important files stored in personal folders, removable media, or local devices as well as shared services?
Is the location or owner still unknown? Record that uncertainty without guessing.

Which accounts control email, domains, websites, finance, cloud services, or administrative consoles?
Which business accounts would be difficult to recover if the usual account holder were unavailable?

Record only the account’s existence, business purpose, internal owner, lifecycle state, and review date. Never place passwords, authentication secrets, recovery codes, or access instructions in this inventory.

Which outsiders and services does the business depend on?

Which vendors, contractors, managed providers, or hosted services support a business capability?
Has an old supplier or service remained in the list after the business stopped relying on it?

For vendors, do not expand this check into privilege, access-path, external-contact, or removal fields. Those belong in the vendor access register.

Review and maintain the inventory

An inventory becomes less useful when nobody can tell whether its rows still describe reality. PlainFort recommends two complementary review triggers as a practical starting point:

Event-based review: update affected rows when a device, service, account, data location, owner, or vendor is introduced, changed, transferred, or retired.
Scheduled review: check a manageable portion monthly and complete a whole-inventory pass at least quarterly until the team has evidence that a different rhythm fits its rate of change.

That cadence is editorial judgment, not a NIST or FTC requirement. A very small and stable operation may choose a different rhythm; a rapidly changing team may need shorter intervals. Record the chosen cadence and the reason for it.

During a review:

confirm the item still exists and the business still depends on it;
confirm the internal owner and lifecycle state;
keep unknown or disputed facts visible;
update the review date only when someone actually checks the row;
create follow-up work in the system where the team normally manages tasks rather than hiding actions in a notes cell.

Use the inventory as an input, not a verdict

The inventory should feed later decisions without trying to perform them all:

Security priorities uses known assets and dependencies when deciding what work should happen first.
The first 30 days uses the inventory as an input to a broader implementation sequence.
The vendor access register records access-specific fields for vendors already known to exist.
Later device, account, backup, and recovery guides can use inventory rows to identify what requires a decision or test.

Do not add those sibling workflows to this table. Linking to a dedicated decision keeps one owner for each method and reduces contradictory records.

Limits and escalation

A manually assembled inventory can be incomplete or stale. It may miss shadow services, unmanaged infrastructure, personal devices, informal data flows, subcontractors, or items whose owners do not realize they are business dependencies. Recording an item does not show that it is configured securely, backed up, recoverable, appropriately accessed, or compliant.

Seek qualified professional help when the team cannot determine where sensitive data resides, discovers unmanaged infrastructure it cannot safely assess, or needs legal or regulatory data classification. If there is a suspected compromise, use an approved incident-response path rather than treating inventory work as containment or forensic investigation.

Completing this table is not proof that the business is secure, that every item has been found, or that any recorded item is configured safely. It is a maintained starting point for better decisions.