Safeguard 15.1 service provider inventory: evidence

Safeguard 15.1 service provider inventory: what the CIS inventory must list

An auditor or a customer security questionnaire asks a simple question: who are your service providers, and who inside the company owns each relationship? Safeguard 15.1 exists so that you can answer it from a maintained record rather than from memory. In plain terms, it asks for an inventory that lists all known service providers, the classification or classifications assigned to each, and a designated enterprise contact who is accountable for the relationship. The Assessment Specification scores this with two measures: how complete the list is and how accurate its entries are. It also fails the safeguard outright if no inventory exists, so the first job is simply to have one. The inventory must be reviewed and updated at least annually, and sooner when a significant change, such as a merger or a new platform rollout, could alter the picture.

The inventory matters beyond this one safeguard because 15.2 to 15.7 all depend on it. The policy in 15.2 governs classification, assessment, monitoring and decommissioning, but you cannot apply a classification to a provider you have not recorded, send a contract review to a contract nobody can find, or decommission an account that nobody knew existed. Treat the inventory as the register that every later safeguard reads from. Each entry should carry enough detail to act on: the provider name, the services and data involved, the classification from 15.3, and the named owner who can answer for it.

The hard part is rarely writing the spreadsheet. It is finding what belongs in it. Shadow SaaS is the usual gap: a team signs up for a project tool or an AI assistant with a corporate card, and no contract or procurement record ever reaches the security team. Providers bought by a business unit, a subsidiary or an acquired company often live in a separate finance system or a legacy contract folder. Start by reconciling sources that already exist, including accounts payable vendor lists, single sign-on application catalogs, cloud billing data, expense reports and domain registrations, then ask each business owner to confirm their list. Confirm with your own environment which of these sources you can export, since the right mix depends on how your organization buys and manages software.

Which service providers belong in the 15.1 inventory

Safeguard 15.1 asks for every known service provider to be listed with its classification and an enterprise contact. The hard part is deciding what counts as a provider, because each scoping choice below can grow or shrink the inventory considerably.

Cloud and SaaS providers

Every SaaS application that stores, processes or transmits enterprise data is a provider, and so is each cloud platform hosting workloads. Teams often adopt tools outside central procurement, so the inventory starts with expense reports, single sign-on logs and OAuth grants rather than the contract register. Record the provider, the business owner and the data each tool holds. Confirm that shadow SaaS is included, since unlisted tools fail the completeness measure.

Managed service providers

An MSP that administers servers, networks or endpoints is a provider even when it never touches business data. Its engineers hold privileged access, so it belongs in the inventory with its own classification. Record each managed service separately if the MSP delivers several, such as monitoring, backup and help desk. Ask the MSP to name its subcontractors, because those may also hold access that needs to be listed.

Contractors with system access

Individual consultants and contract staff with accounts on enterprise systems create access paths that a vendor list often misses. List the firm or staffing agency as the provider, and note the named individuals with access in the classification or account records. When a contractor's accounts are provisioned directly by the enterprise, confirm they are linked to the provider entry so removal can be traced later.

Payment and data processors

Payment gateways, payroll bureaus, analytics platforms and other processors that receive personal or financial data on the enterprise's behalf are providers with high classification. These relationships often sit in finance or marketing rather than IT, so ask those teams to nominate them. Confirm each processor's data categories and locations, since these details drive the classification later under Safeguard 15.3.

Providers without enterprise data

Some providers hold no enterprise data but run a process the business depends on, such as an outsourced payroll run, a call center or a hosted DNS service. Their absence would disrupt operations without exposing data, so they still belong in the inventory. Classify them by availability need instead of data sensitivity, and record the business process each one supports so the entry remains meaningful.

Confirming the inventory is complete

The inventory is only as good as the sources behind it. Cross-check it against accounts payable vendor records, the cloud billing accounts, identity provider application lists and firewall egress destinations. Record the date of each cross-check. CIS asks for a review at least annually, and sooner after significant changes such as a merger or a new platform, so schedule the review and assign an owner.

How an assessor tests the 15.1 inventory

This table compares what the CIS Assessment Specification measures for Safeguard 15.1, the evidence an assessor typically asks to see, and where inventories usually fall short. Read it as a test plan: each row shows what the assessor checks and what you should have ready before the review starts.

Test point	What the assessor checks	Evidence to prepare	Where it usually fails
Existence	Whether any service provider inventory exists. No inventory produces a failing score for the Safeguard.	The inventory itself, in a format the assessor can open and sort, such as a register, spreadsheet export or GRC record.	A list of major cloud or SaaS vendors kept by IT, with no owner, no classification and no contact.
Completeness metric	The share of service providers in scope that appear in the inventory. The CAS names this as Completeness of Inventory.	A reconciliation of the inventory against accounts payable, procurement records, corporate card data and the identity provider's application list.	Providers paid through expense claims, free tiers, business unit purchases or subscriptions bought on personal cards are not listed.
Accuracy metric	The share of listed providers whose entries are correct. The CAS names this as Accuracy of Inventory.	Sampled provider records showing the legal name, service description, classification and enterprise contact, each matched to a contract or order form.	Entries use trading names, have contacts who left the company, or carry classifications that no longer match the data the provider holds.
Classification and contact fields	Whether each provider carries at least one classification and a designated enterprise contact, as Safeguard 15.1 requires.	The field definitions, the classification values in use and the contact assignment for each record.	Contacts are a shared mailbox or a team name with no accountable person, or classification fields are blank for older providers.
Currency of the review	Whether the inventory was reviewed and updated within the annual cycle, or sooner after significant enterprise changes.	The date of the last review, the reviewer's name and a log of changes such as mergers, new platforms or exited vendors.	The file shows a creation date but no review history, so the assessor cannot confirm the annual cycle was followed.
Sampled records	Whether the assessor's sample of providers matches the live environment and the contracts on file.	A ready-to-share extract for the sample, with links to the contracts, order forms or ownership records behind each entry.	Records exist but the supporting contract or business owner cannot be produced within the assessor's request window.
Scope of the CAS	The CAS defines what is measured for 15.1. It does not prescribe the tool, the data source or the review workflow.	A written method describing which sources you reconcile and how often, so your approach is clear to the assessor.	Teams assume the specification dictates a particular tool or template, then cannot explain how their own list was built.

How to build a 15.1 inventory that survives an audit

This sequence turns scattered records of who you buy from and who holds your data into one register, with a classification and an accountable owner for each provider, verified by the people who manage those relationships and kept current through an annual review and change triggers.

Gather provider sources from every record system
Pull candidate providers from accounts payable vendor records, identity provider application lists, cloud marketplace subscriptions, network egress and DNS logs, and the contract register held by legal or procurement. Each source catches different providers: finance sees paid vendors, identity logs show SaaS sign-ins, and egress data can reveal hosted services that no one bought through procurement. The output is a raw list per source, with the owner of each source named so questions can be routed later. Confirm with your own teams which of these sources actually exist, since some organizations keep no central contract register.
Consolidate sources into one register
Merge the source lists into a single register, removing duplicates such as the same provider under different legal names or billing accounts. Record for each entry the legal name, the services provided, the systems or data involved and the source that surfaced it. Shadow IT entries that appear only in egress or identity logs should be flagged for review rather than dropped. The output is one consolidated register that is the only authoritative list, with the source of every row retained so an assessor can trace how the inventory was built.
Assign a classification to each provider
Give every provider at least one classification that reflects the characteristics that matter to your enterprise, such as the sensitivity of the data it holds, whether it runs a critical platform or process, and whether it is subject to a regulation you must meet. Classification under Safeguard 15.3 is a separate safeguard, but 15.1 requires that a classification be recorded here, so agree the classification categories with the policy owner before tagging. The output is a register where every row carries a classification value drawn from a defined list, not free text.
Name an enterprise owner for each provider
Designate one enterprise contact per provider. This is normally the business or technical manager who signed the contract or depends on the service day to day, not a shared mailbox. Record the contact's name, role and a way to reach them, and make sure the person knows they are accountable for the relationship. Where a provider has no obvious owner, that gap is itself a finding to resolve before the register is accepted. The output is an owner field completed for every entry, with the owner's acceptance recorded.
Verify accuracy with each owner
Send each owner the rows they are responsible for and ask them to confirm the provider name, services, classification and the systems or data involved, and to add any providers missing from the list. Accuracy is one of the two metrics the CIS Controls Assessment Specification uses for this safeguard, so record corrections and keep the signed or dated confirmation for each owner. Compare the confirmed register against the source lists once more to check completeness. The output is an owner sign-off record and a change log showing what was added, corrected or removed during verification.
Set the annual review and change triggers
Write the review requirement into the service provider management policy: the inventory must be reviewed and updated at least annually, and sooner when significant enterprise changes could affect it, such as a merger, a new cloud platform, a major outsourcing decision or a regulatory change. Assign an owner for the review and a fixed place to store the register. Ask your counsel or internal audit to confirm the wording matches your governance model. The output is a documented review procedure, a named review owner and a dated record of the last review.
Keep evidence ready for the assessor
Store the register version history, source extracts, owner sign-off records, review records and the trigger log together so an independent assessor can trace each provider back to a source and a confirmation. Test the package yourself by picking a sample of providers from the cloud and identity sources and checking that each appears in the register with a classification, an owner and a sign-off. Gaps found here are cheaper to close before an assessment than during one. The output is an evidence folder that supports both the completeness and accuracy measures.

Evidence that passes a 15.1 review and how to keep it current

An assessor testing Safeguard 15.1 looks for an inventory that is complete, accurate and provably current. The six artifacts below show that, and each needs a routine that keeps it true between annual reviews rather than a scramble before an audit.

Dated inventory export

The core artifact is a dated export of the service provider register with classification and owner fields populated for every row. Record the export date, the system of record and who generated it. Check that each provider name, service description and classification matches the contract file, because the Accuracy metric counts correctly listed providers. Schedule the export monthly, so the file an assessor sees is never more than a few weeks from the live register.

Discovery sources and query dates

An inventory built only from memory will miss providers. Keep a short list of the sources you query to find providers, such as accounts payable vendor records, SaaS single sign-on application catalogs, cloud marketplace subscriptions and corporate card merchant reports. Record the date each source was queried. A reviewer can then see that completeness was tested against independent data, not just the list the team already held.

Owner attestation or review record

Each named enterprise contact should confirm, in writing or through a ticket, that the provider entry they own is correct and still in use. Keep the attestation with its date and the contact's name. Stale ownership is a common failure, so a departed employee's name on an active provider is a finding to fix before the review. Ask owners to confirm at the same cadence as the export, so attestations do not lapse between annual cycles.

Change log of additions and removals

Keep a log that records each provider added, reclassified, transferred to a new owner or removed, with the date and the trigger. Useful triggers include a new purchase order, a contract renewal, a change in data scope, or a provider acquisition. The log proves the inventory moves with the business, which CIS expects when significant enterprise changes could affect the safeguard. Removals should cite the decommissioning record under Safeguard 15.7.

Procurement and onboarding triggers

Most drift starts when a team signs a provider outside the normal purchase path. Route new contracts, free trial sign-ups above an agreed threshold, and cloud marketplace purchases through a step that requires an inventory entry before activation. Keep a record of the trigger rules and a sample of onboarding tickets showing the entry was made. The evidence is the rule itself plus proof it ran, and a reviewer will ask for both.

Annual review sign-off

CIS asks for the inventory to be reviewed and updated annually, so keep a signed review record from an accountable owner, typically the security or third-party risk lead. The sign-off should cite the export version reviewed, the exceptions found and their closure dates. Confirm with your own assessor which sign-off format they accept, since CIS does not prescribe one. Calendar the review so it falls before any external assessment window.

What a service provider inventory costs in money and effort

This table breaks the cost of building and keeping a Safeguard 15.1 inventory into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written scope and to compare quotes, since no fee figure is given here. The main takeaway is that most of the recurring effort comes from keeping the register accurate as the provider base changes, not from creating the first list.

Cost component	One-time or recurring, and who is paid	What drives it up	What keeps it down
Tooling or licenses	Recurring if a subscription is used. Paid to the software vendor, or none if a spreadsheet or open-source register is kept.	Number of providers, number of data sources to import, and reporting features needed for the annual review.	Using an existing procurement, finance or GRC system of record, or a self-hosted open-source register.
Internal engineering or procurement time to consolidate sources	One-time for the first build, then recurring for new sources. Internal staff time, or partner time if scoped in writing.	Number of systems holding vendor data (accounts payable, contracts, identity, cloud billing, SaaS admin consoles) and their inconsistency.	Naming one authoritative source per data type and agreeing how vendor names are normalized before import.
Owner time to validate entries	One-time for the baseline, then recurring. Internal business owners of each relationship.	Number of providers with unclear business owners and unclear classification.	Recording a named enterprise contact and owner for each provider at onboarding, not after the fact.
Shadow IT discovery	One-time for the first sweep, then recurring. Internal staff, or partner time if specified in scope.	Decentralized purchasing, free trials, personal accounts used for work, and unmanaged SaaS.	Routing all new vendor purchases through one intake path and reviewing expense and SSO logs on a set cadence.
Evidence upkeep for the annual review	Recurring, at least annually under the Safeguard's review expectation. Internal compliance staff time.	Frequency of enterprise changes, such as mergers, reorganizations or new regulated services, which can trigger earlier updates.	Tying register updates to change management and contract renewal dates so updates happen as events occur.
External review of the register	Optional, recurring if chosen. Paid to an independent reviewer or consultant under a written scope.	Scope breadth, number of entries sampled, and whether the reviewer must reconcile against source systems.	Limiting the review to a defined sample and asking for a fixed-scope deliverable with agreed outputs.
Auditor sampling time	Recurring at each audit cycle. Paid to the independent auditor or assessor, not to the implementation partner.	Number of providers sampled, number of separate sources the auditor must reconcile, and gaps found in earlier cycles.	Keeping one reconciled register with a clear change history so the sample can be traced quickly.

How open-source tooling can hold the 15.1 inventory

A self-hosted register of service providers can live in an open-source compliance platform, and CISO Assistant is a candidate worth evaluating for the 15.1 inventory. The platform ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and it runs audits and compliance assessments against them with automatic mapping between frameworks. For a 15.1 record, the practical benefit is that a provider entry can be linked once and reused as evidence for the other frameworks your organization must answer to, instead of being copied into separate spreadsheets. The mapping is a convenience for your own work, not a finding by any assessor, so check each cross-reference against the framework text before relying on it in an audit.

CISO Assistant is licensed under the AGPL-3.0-only license. For internal use, this generally means you can deploy, run and modify the software inside your own infrastructure without paying a license fee. The obligations change if you distribute a modified version or offer it to others over a network, because the AGPL requires the corresponding source to be made available to those users. Have your legal counsel confirm how the license applies to your planned deployment, particularly if a partner will customize the platform or if you plan to expose it to external parties such as providers who log in to update their own records.

Before you commit, confirm the platform's current inventory and provider-record features in its documentation and the project repository linked from the CISO Assistant README on GitHub. Specifically, check whether it stores the provider name, each classification, and a named enterprise contact, whether it records a review date to support the annual review that 15.1 expects, and how it handles the completeness and accuracy measures in the assessment specification. If a feature is missing, decide whether to record it in a linked spreadsheet or to request it through the project's own channels, and document that decision in your 15.2 policy.

Who does what: your team, an implementation partner and the auditor

Your organization owns the service provider inventory. That means deciding which third parties count as service providers for the enterprise, assigning a named enterprise contact to each one, confirming each provider's classification, and approving the register. Those decisions carry business and risk judgment that cannot be delegated to a consultant, because the people accountable for each relationship must stand behind the entries.

Provider ownership decisions: Name the accountable business owner and the enterprise contact for every provider, and record who approves changes.
Scope and classification sign-off: Confirm which providers hold sensitive data or run critical platforms, and approve their classifications.
Annual review: Review and update the inventory yearly, or sooner after significant changes such as a merger, a new platform or a major outsourcing decision.
Records of review: Keep signed or dated approvals so an assessor can see who reviewed the inventory and when.
Governing policy: Tie the inventory to the service provider management policy that defines who is responsible.

Before engaging anyone, confirm internally who will sign the review, because that signature is the evidence an assessor will ask for first.

Where 15.1 inventories usually fall short

Most service provider inventories fail in predictable places rather than in the list itself. The gaps below cluster around ownership, classification, currency and discovery, and each one can be closed with a specific action that an assessor will look for.

Providers with no enterprise contact

A provider can appear in the inventory with a name and a service description, yet no one inside the enterprise is accountable for the relationship. Safeguard 15.1 requires a designated enterprise contact for each provider, so a blank or departed owner is a gap in its own right. Check every row for a named person or role, and set a rule that a provider without an owner cannot be renewed or onboarded.

Classifications never assigned

Many inventories list providers but leave the classification column empty, or fill it with a default that nobody reviewed. Safeguard 15.1 expects each provider's classification to be recorded, and the later safeguards in Control 15 depend on that field to decide how deeply each provider is assessed and monitored. Sort the list by classification, then assign one to every unclassified row before the next review.

Inventory last updated before a reorganization

Mergers, divestments, new business units and outsourcing decisions often add or retire providers without anyone updating the register. The Safeguard asks for the inventory to be reviewed at least annually and sooner when significant enterprise changes could affect it. Treat any reorganization, acquisition or major platform change as a trigger for a targeted review, and record the date of the last review on the inventory itself.

Providers found only through finance

Accounts payable is often the most complete source of providers, yet it misses free tiers, cloud marketplace subscriptions, departmental credit cards and open-source hosted services that a team adopted without a purchase order. Reconcile the inventory against payment records, identity provider application lists, single sign-on logs, and DNS or egress records for data flowing to outside services. Each discovered provider then needs a classification and an owner.

Entries that do not match the real provider

Inventories sometimes list a parent brand, a reseller or a legacy company name, while the entity that actually holds enterprise data is a subsidiary or subprocessor. The completeness and accuracy metrics in the assessment specification check whether each listed provider is correctly identified. Compare each entry against the signed contract and the provider's legal name, and record subprocessors separately where they handle sensitive data.

Platforms run by internal teams

Self-hosted platforms operated by an internal group may be treated as internal systems and left out of the register, even when a managed hosting company, an outsourced operator or a contracted consultant supports them. Confirm whether each platform has an external party with access to enterprise data or administrative control, and list that party if so. Ask platform owners to declare every outside organization that touches their systems.

Questions buyers ask about the 15.1 inventory

How long does it take to build the first service provider inventory?

No researched figure exists for the duration, so confirm it against your own environment rather than a generic estimate. The time is driven mainly by how many suppliers you have, how scattered the records are across finance, procurement, IT and business units, and whether each provider's data sensitivity and enterprise contact can be found quickly. Organizations with a central contract register usually start further along than those reconstructing relationships from invoices and email. Ask any partner to break the estimate into discovery, validation with owners and loading into the inventory tool, and to state which of those steps depends on your records.

Can our own team build the 15.1 inventory without outside help?

Yes, in principle. Safeguard 15.1 asks for a list of all known service providers, their classification and a designated enterprise contact for each, and it has no prerequisite safeguards in the Assessment Specification. The harder part is discovery, because providers often sit outside procurement, such as software bought on a corporate card or tools adopted by a single team. Internal staff who know the business can complete the list, while an outside partner may help with structured discovery, tooling and reconciliation if the team lacks the time or capacity. Either way, the organization owns the inventory.

What does building the inventory need from finance and procurement?

Finance and procurement hold the most complete record of who you pay and under which contract, so they are the main source for discovery. Procurement can provide contract registers and supplier onboarding records, while finance can supply accounts payable vendor lists and recurring card or subscription spend. Both teams should agree on what counts as a service provider for the inventory and how new suppliers will be added. Ask for a named owner in each function and a written data extract that you can reconcile against the list.

Does a service provider inventory alone satisfy CIS Control 15?

No. Safeguard 15.1 is the starting point for Control 15, but the other safeguards depend on it and cover the work that follows: a service provider management policy (15.2), classification (15.3), security requirements in contracts (15.4), assessment (15.5), monitoring (15.6) and secure decommissioning (15.7). Under the Assessment Specification, the 15.1 score is based on the completeness and accuracy of the list, and a missing inventory fails the safeguard. An inventory is necessary evidence, not the whole control, and it does not stand in for any regulatory or contractual scheme you are subject to.

How often must the service provider inventory be reviewed?

CIS asks that the 15.1 inventory be reviewed and updated annually, or sooner when significant enterprise changes could affect it, such as a merger, a new platform or the loss of a major provider. Annual review is a minimum. In practice, teams add a trigger to the procurement process so new providers enter the inventory when they are onboarded, and they check contacts whenever a named owner leaves. Confirm with your assessor how they will sample the inventory and what dated records they expect to see.

What should we ask an implementation partner for in a written quote?

DeployOpen does not publish a price list, and a quote follows from a written scope. Ask any partner for the following in writing: the systems and data sources in scope, the discovery method and who performs it, the fields the inventory will hold (classification, enterprise contact, and the other attributes you need), the validation step with business owners, the deliverables and an agreed timeline, and which tasks you must do yourself. Also ask how the inventory will be handed over and maintained, and whether ongoing review is a separate retainer. Remember that an independent auditor or assessor, not the partner, issues any report or certificate.

How DeployOpen builds and documents a 15.1 inventory

DeployOpen helps organizations set up the systems, records and evidence behind Safeguard 15.1, the service provider inventory, while the organization keeps ownership of its provider list and decisions. We scope the work in writing, build the inventory in the client's own infrastructure with open-source tooling, and hand over documentation that an internal owner and an independent assessor can review.

How we scope

Engagements are fixed-scope, with the provider population, data sources and systems agreed in writing before work starts.
We confirm which business units, subsidiaries and platforms the 15.1 inventory must cover.
Scope names the internal owner who maintains the inventory and the annual review cadence.

How we build

We configure an inventory of all known service providers, with a classification field and a named enterprise contact for each entry.
We reconcile the list against finance, procurement, identity and contract records to test completeness.
We check each entry for accuracy against source records, since CIS measures both completeness and accuracy.

How we hand over

You receive the inventory, its data dictionary, the reconciliation method and the review procedure as written documentation.
Deliverables show how the inventory supports Safeguard 15.2 policy and the classification work in 15.3.
An independent auditor or assessor, not DeployOpen, reviews the evidence and issues any report or certificate.

How we support

Ongoing support, upgrades and reviews are available as a retainer after the fixed-scope work is complete.
Retainer support can cover the annual review and the updates triggered by significant enterprise changes.
Ask any partner to confirm in writing who owns the inventory after handover and how changes are approved.