SORF Project

Standard

Vendor Inventory

The Vendor Inventory standard explains how an organization can document the vendors, services, tools, subscriptions, providers, and outside relationships it depends on.

Small organizations often use many outside services without keeping a clear list of them. A website may depend on a domain registrar, hosting provider, DNS service, email provider, payment processor, analytics tool, design tool, accounting platform, password manager, and several professional contacts. Over time, those services can become scattered across inboxes, cards, personal accounts, spreadsheets, and memory.

A vendor inventory helps make those dependencies visible.

Purpose

The purpose of a vendor inventory is to help an organization understand:

The inventory does not need to be complex. It should make the organization easier to understand.

Core principle

The core principle is:

Keep a clear list of the outside services your organization depends on, why they matter, and who is responsible for them.

A vendor inventory should be practical enough to maintain. If the record becomes too complicated, it is less likely to stay current.

What counts as a vendor or service

For this standard, a vendor or service can include any outside provider, tool, subscription, platform, contractor, or professional relationship that supports the organization.

Examples include:

The inventory should focus on services that matter to operations, continuity, billing, access, communication, or decision-making.

What a vendor inventory is

A vendor inventory is:

It helps answer basic questions such as:

What a vendor inventory is not

A vendor inventory is not:

Some organizations may need formal vendor risk reviews, contract reviews, security reviews, or compliance processes. This standard does not replace those activities.

A basic vendor inventory may include the following fields.

Vendor or service name

Record the name of the vendor, provider, service, platform, tool, or contractor.

Examples:

Use the name people commonly recognize.

Category

Record the type of service.

Examples:

Categories help make the inventory easier to scan.

Purpose

Describe why the organization uses the vendor or service.

Examples:

The purpose should be specific enough to help someone understand the service without needing to ask the original owner.

Importance level

Record how important the service is to the organization.

A simple scale may be enough:

Critical services may include services that affect revenue, customer access, public website availability, legal notices, email, banking, payroll, or core operations.

Responsible owner

Record who owns or maintains the vendor relationship.

This may be:

Examples:

Where possible, use both role and current person.

Contact path

Record how the vendor is contacted.

Examples:

Do not store sensitive account recovery information here. Use access references for access-related details.

Account owner or billing owner

Record who receives invoices, renewal notices, receipts, or billing notifications.

Examples:

This is especially useful when vendor emails go to one person’s inbox.

Renewal or billing cycle

Record the billing or renewal pattern.

Examples:

If the service renews annually, record the renewal month or date if known.

Approximate cost

Record a general cost note if useful.

Examples:

This does not need to be exact accounting. The goal is awareness.

Payment method reference

Record where payment information is managed without exposing payment card details.

Examples:

Do not record full card numbers, bank login information, or sensitive payment credentials.

If the service has an account or admin login, link or refer to the access reference.

Examples:

This helps separate vendor awareness from credential storage.

Record other internal documentation connected to the vendor.

Examples:

Use safe references. Do not store sensitive documents directly in the vendor inventory unless the inventory system is approved for that purpose.

Status

Record whether the vendor is active.

Examples:

Archived vendors may still matter if old records, invoices, or account history need to be retained.

Last reviewed date

Record when the vendor record was last checked.

Review frequency

Record how often the vendor should be reviewed.

Examples:

Notes

Use notes for neutral context.

Examples:

Do not use notes for passwords, API keys, payment details, confidential contracts, or sensitive incident evidence.

A small organization can begin with a simple vendor record.

Field Description
Vendor/service Name of the vendor, platform, tool, or provider
Category Type of service
Purpose Why the organization uses it
Importance Critical, important, useful, optional, or unknown
Owner Person or role responsible
Billing/renewal Monthly, annual, usage-based, or unknown
Access reference Where access is documented safely
Last reviewed Date last checked

This minimum version is enough to create visibility.

Examples

Example: Website hosting

Field Example
Vendor/service Website hosting provider
Category Hosting
Purpose Hosts the public website
Importance Critical
Responsible owner Website maintainer
Contact path Support portal
Billing cycle Monthly
Approximate cost $20/month
Access reference “Website Hosting Admin”
Status Active
Last reviewed 2026-07-08
Review frequency Quarterly

Example: Domain registrar

Field Example
Vendor/service Domain registrar
Category Domain
Purpose Manages primary domain name
Importance Critical
Responsible owner Founder
Contact path Account dashboard
Billing cycle Annual
Approximate cost Varies by domain
Access reference “Primary Domain Registrar”
Status Active
Last reviewed 2026-07-08
Review frequency Quarterly

Example: Accountant

Field Example
Vendor/service Accounting firm
Category Professional service
Purpose Supports bookkeeping and tax preparation
Importance Important
Responsible owner Finance owner
Contact path Professional email
Billing cycle Monthly or project-based
Approximate cost Contract-based
Access reference Not applicable
Status Active
Last reviewed 2026-07-08
Review frequency Annually

Example: Payment processor

Field Example
Vendor/service Payment processor
Category Payments
Purpose Processes customer payments and receipts
Importance Critical
Responsible owner Finance owner
Contact path Support portal
Billing cycle Transaction-based
Approximate cost Varies by transaction volume
Access reference “Payment Processor Admin”
Status Active
Last reviewed 2026-07-08
Review frequency Quarterly

Vendor importance levels

A simple importance scale helps prioritize review.

Critical

A critical vendor is essential to operations, revenue, legal obligations, customer access, communications, or continuity.

Examples:

Critical vendors should usually have clear ownership, access references, billing awareness, and continuity notes.

Important

An important vendor supports meaningful operations but may not stop the organization immediately if unavailable.

Examples:

Important vendors should still be reviewed periodically.

Useful

A useful vendor helps the organization but is not essential.

Examples:

Useful vendors are good candidates for periodic cleanup.

Optional

An optional vendor may not be needed long term.

Examples:

Optional vendors should be reviewed before renewal.

Unknown

Unknown means no one is sure how important the vendor is.

Unknown should not stay unknown forever. It is a signal to review the service.

Review triggers

A vendor inventory should be reviewed when:

Relationship to access references

Vendor records and access references should work together.

The vendor inventory records:

The access reference records:

Do not duplicate passwords or secrets in either record.

Relationship to continuity notes

Vendor inventories are important for continuity.

If a key person becomes unavailable, the organization may need to know:

A basic vendor inventory can make the first hour of a disruption less confusing.

Relationship to incident timeline notes

Vendor records are also useful during incidents.

If a service outage, billing issue, account lockout, domain problem, payment disruption, or vendor mistake occurs, the vendor inventory can help identify:

Incident timeline notes should record what happened. The vendor inventory should help explain what system or service was involved.

Common mistakes

Mistake 1: Only tracking paid subscriptions

Some important services may be free, included, donated, trial-based, or managed by someone else. They may still be operationally important.

Mistake 2: Not recording the owner

A list of vendors is less useful if no one knows who is responsible for each one.

Mistake 3: Confusing vendor records with passwords

Vendor records should not contain passwords, API keys, MFA recovery codes, or payment card details.

Mistake 4: Ignoring renewal dates

Many problems come from forgotten renewals, expired cards, old billing emails, or abandoned subscriptions.

Mistake 5: Keeping cancelled vendors mixed with active vendors

Cancelled or archived vendors can still matter, but they should be clearly marked.

Mistake 6: Overbuilding the inventory

A vendor inventory should be useful, not exhausting. Start with critical services and expand gradually.

Suggested adoption path

A practical adoption path is:

  1. List the organization’s most important services.
  2. Mark each service as critical, important, useful, optional, or unknown.
  3. Add a responsible owner for each service.
  4. Add billing or renewal awareness.
  5. Add access-reference links for services with accounts.
  6. Review unknown and optional services.
  7. Set a review routine.

This approach helps the organization create value quickly.

Public standard status

This standard is an early public draft.

It may be revised as examples, templates, feedback, and implementation notes improve.

Related templates may include:

Related standards include:

Status: Draft · Version: 0.1 · Last updated: 7/8/2026

This standard is provided as a general educational resource. It is not legal, tax, financial, insurance, cybersecurity, compliance, or incident-response advice.