You cannot reliably secure, maintain, replace, or cancel a business tool that you have forgotten exists.
For a solo professional, the missing inventory is rarely a list of installed programs. The real surface includes cloud subscriptions, browser extensions, mobile apps, shared client workspaces, automation connectors, domains, email rules, API integrations, AI assistants, payment services, and free accounts that still hold business data.
A software and service inventory is a compact operating record of those dependencies. Its purpose is not to satisfy an enterprise asset-management standard. It is to answer: what does the business rely on, what can each service reach, who controls it, what happens if it disappears, and what should be reviewed next?
Testing status. This is a platform-neutral editorial framework. Practical Solo Ops has not tested every discovery tool, identity provider, vendor dashboard, or asset-management product. The worksheet is designed for manual use and can be moved into an approved system after its fields are validated.
Source status, reviewed August 25, 2026. NIST’s Cybersecurity Framework 2.0 Small Business Quick-Start Guide is voluntary guidance, not a legal requirement. It recommends creating and maintaining an inventory of hardware, software, systems, and services, then considering sensitivity, criticality, ownership, MFA, and business impact. The fields below adapt that official small-business starting point to a one-person service business.
Define the inventory boundary
Use this boundary:
Include a tool or service if it stores business information, moves business information, controls access, represents the business publicly, charges the business, or is required to deliver work.
That includes free tools. A $0 browser extension with mailbox access can carry more operational risk than a paid design subscription.
Include:
- email, calendar, file storage, office suites, and messaging;
- accounting, invoicing, banking connections, payment processors, and tax portals;
- CRM, forms, scheduling, proposals, contracts, and electronic signatures;
- project management, client portals, support, and knowledge bases;
- AI tools, meeting assistants, transcription, and document processors;
- automation platforms, webhooks, API clients, and integration accounts;
- domains, DNS, hosting, code repositories, analytics, and search tools;
- password managers, identity providers, MFA devices, and recovery methods;
- browser extensions, desktop applications, and mobile applications used for work;
- client-owned systems where your account or integration remains active.
Exclude purely personal tools unless business data or access has crossed into them. If that boundary is unclear, record the tool and mark it for review rather than silently excluding it.
Use the NIST small-business fields as the base
The NIST Cybersecurity Framework 2.0 Small Business Quick-Start Guide recommends understanding the assets a business relies on by maintaining an inventory of hardware, software, systems, and services. Its sample inventory asks for the asset’s official use, owner or administrator, sensitive-data access, MFA status, and the risk if access is lost.
Adapt that into these fields:
| Field | What to record | What not to record |
|---|---|---|
| Service name | Current product or platform name | Marketing description |
| Business purpose | The outcome it supports | “Useful” or “productivity” |
| System owner | Who can make account-level decisions | Password or recovery code |
| Billing owner | Who can change or cancel payment | Card or bank details |
| Login route | Approved sign-in method or identity provider | Secret credentials |
| MFA state | Required, optional, unavailable, or unknown | MFA seed or backup code |
| Data classes | Categories the service can access | Unnecessary copied records |
| Access scope | Read, write, send, publish, delete, bill, administer | Token value |
| Criticality | Effect of losing access | Vague “high priority” |
| Dependencies | Inputs, outputs, integrations, and client systems | Unverified guesses |
| Renewal | Date, cadence, plan, and notice source | Payment instrument number |
| Exit route | Export, replacement, fallback, cancellation path | Untested promise |
| Evidence link | Contract, invoice, admin page, or decision record | Secret-bearing screenshot |
| Review date | When the record was last verified | Creation date alone |
Editorial analysis. The combination of purpose, access, criticality, and exit route is more useful than a long list of product names. It tells you why the tool matters and what kind of failure must be planned.
Discover tools from evidence, not memory
Do not try to remember the stack in one sitting. Use bounded evidence sources.
1. Start from business capabilities
List the systems needed to:
- receive an inquiry;
- schedule a call;
- agree on scope;
- perform and review work;
- deliver the result;
- invoice and collect payment;
- retain required records;
- run the website and domain;
- communicate during an outage.
Map at least one tool or manual fallback to each capability.
2. Review billing records without copying financial details
Look at recent business statements, invoices, app-store subscriptions, and vendor billing pages. Record the vendor, cadence, plan, renewal date, and evidence location. Do not paste card numbers, bank data, tax information, or full statements into the inventory.
3. Review identity and access lists
Check the business email account, identity provider, password manager, browser extensions, mobile apps, and major cloud services for connected applications and active sessions.
CISA’s small-business MFA guidance recommends enabling MFA across systems such as email, file storage, and remote access, starting with administrative accounts and sensitive data. See Require Multifactor Authentication.
Record whether MFA is required and which role controls recovery. Never copy the authentication secret into the inventory.
4. Trace automation connections
For every scheduled automation, webhook, or integration, record:
- the trigger system;
- the action system;
- the service account or authorized user;
- whether it can read, write, send, publish, delete, or bill;
- the fallback if the connection stops;
- the last verified run.
Use the automation change log and rollback plan for live changes and the automation risk ladder to decide which connections require closer control.
5. Review client-owned access
Create separate rows for client workspaces, repositories, ad accounts, analytics properties, file stores, and communication channels where access remains active.
Record the client owner, your role, intended end date, and revocation path. Do not treat a client’s system as your own asset. The inventory records the dependency and access relationship.
Classify data access without creating a data dump
Use broad categories:
- public business information;
- internal operating information;
- client confidential information;
- personal information;
- financial or payment information;
- authentication and security information;
- regulated or professionally restricted information;
- unknown or mixed.
Then record the access mode:
- stores;
- reads;
- writes or changes;
- sends or shares;
- publishes;
- deletes;
- uses for training or product improvement, if the current terms establish it;
- unknown pending review.
Do not infer vendor behavior from marketing language. Link to the current contract, privacy notice, admin setting, or documented test.
Apply the client-data safety checklist before placing client information into an AI-enabled service.
Score criticality using business consequence
Use four levels:
| Level | Loss scenario | Minimum preparation |
|---|---|---|
| Convenience | Work slows but a normal alternative exists | Record owner and cancellation path |
| Supporting | A recurring process pauses or records become harder to reach | Export location and manual fallback |
| Delivery-critical | A current client commitment may fail | Tested fallback, owner, recovery route, dependency map |
| Business-critical | Identity, domain, money movement, core records, or multiple engagements may be affected | Strong MFA, recovery evidence, independent backup or transfer plan, priority review |
Criticality is not the same as price or usage frequency. A rarely opened domain registrar can be business-critical. A daily writing tool may be replaceable.
For each Delivery-critical or Business-critical service, answer:
- How would you know it failed or access was lost?
- How long can the business operate without it?
- What is the manual or replacement path?
- Where is the latest usable export or authoritative record?
- Who besides the current session can recover ownership, if anyone is authorized?
Separate ownership, administration, billing, and recovery
One person may hold every role, but the roles still matter.
- System owner: decides whether the service remains approved.
- Administrator: manages users, roles, settings, and integrations.
- Billing owner: controls the commercial relationship and cancellation.
- Data owner: decides what information belongs in the service and how long it is retained.
- Recovery owner: controls the authorized recovery method.
Editorial analysis. Writing “me” in every field is less useful than naming the role. During an incident, offboarding, or future handoff, the role shows which authority is actually required.
Do not put shared passwords into the record. If a business continuity arrangement is needed, use the password manager’s emergency-access or delegated-access feature only after reviewing its current behavior and consequences.
Add an exit-readiness field
Use one of four states:
| Exit state | Meaning |
|---|---|
| Ready | Export, replacement or manual fallback, cancellation path, and ownership are documented and recently verified |
| Partial | One useful export or fallback exists, but a material gap remains |
| Trapped | A key record, workflow, ownership path, or integration cannot currently be moved or replaced |
| Unknown | Exit behavior has not been checked |
For Partial, Trapped, and Unknown, record one next test.
Use the AI-tool offboarding worksheet for exports, ownership transfer, access revocation, cancellation evidence, deletion, and residual retention. Use the AI subscription total-cost worksheet when switching work changes the real cost of keeping a tool.
Build the first inventory in 45 minutes
Minute 0–10: business-critical core
Record identity, email, domain, DNS, hosting, file storage, finance, and the authoritative client-work system.
Minute 10–20: recurring charges
Use invoices and billing records to add paid services and renewal dates. Do not copy payment details.
Minute 20–30: access and integrations
Review connected applications, browser extensions, automation platforms, and client workspaces.
Minute 30–40: classify
Assign purpose, data categories, access scope, criticality, MFA state, and exit state.
Minute 40–45: choose the next three actions
Select only:
- one unknown business-critical service to verify;
- one unnecessary permission or stale account to review;
- one renewal or exit gap to resolve.
Do not attempt to clean the entire stack during discovery. Inventory changes the evidence; the quarterly audit changes the stack.
Copyable software and service inventory
INVENTORY REVIEW DATE:
INVENTORY OWNER:
SERVICE NAME:
BUSINESS PURPOSE:
STATUS: Active / Trial / Paused / Exit planned / Client-owned
SYSTEM OWNER ROLE:
ADMINISTRATOR ROLE:
BILLING OWNER ROLE:
DATA OWNER ROLE:
RECOVERY OWNER ROLE:
APPROVED LOGIN ROUTE:
MFA: Required / Optional / Unavailable / Unknown
DATA CATEGORIES:
ACCESS SCOPE: Read / Write / Send / Publish / Delete / Bill / Administer
CLIENT OR THIRD-PARTY SYSTEMS CONNECTED:
CRITICALITY: Convenience / Supporting / Delivery-critical / Business-critical
LOSS-OF-ACCESS IMPACT:
MANUAL FALLBACK:
DEPENDENCIES IN:
DEPENDENCIES OUT:
PLAN OR TIER:
RENEWAL DATE AND CADENCE:
RENEWAL NOTICE SOURCE:
EXIT STATE: Ready / Partial / Trapped / Unknown
EXPORT OR AUTHORITATIVE RECORD LOCATION:
CANCELLATION PATH:
NEXT EXIT TEST:
EVIDENCE LINKS:
LAST VERIFIED:
NEXT REVIEW:
NOTES WITHOUT SECRETS:Start with the free CSV
The Free Solo Business Operations Toolkit includes a software and service inventory CSV. It contains one synthetic example row and deliberately excludes fields for passwords, recovery codes, payment-card data, or other secrets.
Definition of done
The first inventory is usable when:
- every business capability has a named system or manual fallback;
- identity, domain, finance, core records, and delivery systems are present;
- paid, free, installed, cloud, extension, integration, and client-owned surfaces were considered;
- each service has a business purpose and owner role;
- sensitive-data access and action scope are classified;
- MFA state is known for critical systems;
- criticality is based on consequence, not price;
- renewals and exit state are recorded;
- no password, token, recovery code, payment number, or private key is stored;
- the next three remediation actions are explicit.
The inventory is not complete forever. It is complete enough to make the next review evidence-based.
Sources
- NIST, Cybersecurity Framework 2.0: Small Business Quick-Start Guide, reviewed August 25, 2026.
- CISA, Require Multifactor Authentication, reviewed August 25, 2026.
- NIST CSRC Glossary, Risk Register, reviewed August 25, 2026.