Safeguard 15.1: Establish and Maintain an Inventory of Service Providers

Safeguard 15.1 requires you to create and keep current a complete inventory of your organization’s service providers so you can manage third-party risk consistently and prove governance in audits. Operationalize it by defining “service provider,” establishing intake and ownership, centralizing the inventory, and setting a recurring update cadence with evidence capture. ¹

Key takeaways:

• Your inventory must be authoritative, complete enough for risk decisions, and kept current, not a one-time spreadsheet. ²
• Tie inventory entries to business owners, services provided, data access, and criticality so downstream due diligence and monitoring can run. ³
• Build evidence into the process (intake records, change logs, periodic attestations) so you can prove the control operates. ²

A service provider inventory is the starting line for third-party risk management. If you cannot list who provides what service, who owns the relationship, and what access or data flows exist, you will not be able to scope due diligence, enforce contract requirements, monitor ongoing risk, or respond quickly to incidents that originate in your supply chain.

Safeguard 15.1 sits in CIS Control 15 (Service Provider Management) and focuses on one thing: an accurate, maintained inventory of service providers. CIS does not prescribe a specific tool, format, or taxonomy. Auditors and internal stakeholders will still expect the inventory to be consistent, reviewable, and connected to actual procurement and IT realities.

The fastest path is to treat the inventory as a system of record with defined entry criteria, required fields, ownership, and update triggers. Then attach lightweight governance: who approves new providers, how you reconcile finance and procurement sources, and how you prove completeness over time. This page gives requirement-level implementation guidance you can execute quickly and defend during an assessment. ¹

Regulatory text

Framework requirement: “CIS Controls v8 safeguard 15.1 implementation expectation (Establish and Maintain an Inventory of Service Providers).” ¹

Operator interpretation: You must maintain a living list of service providers your organization uses. “Maintain” implies you have (1) a defined process to add/update/remove providers, and (2) evidence the process runs as designed, not just a static document. ²

What the operator must do:

• Define what counts as a “service provider” for your environment (include technology and non-technology providers that touch sensitive processes or data).
• Record each provider in a centralized inventory with enough attributes to support risk decisions and follow-on controls under CIS Control 15.
• Keep it current through intake gates and recurring reconciliation against authoritative sources. ¹

Plain-English interpretation (what “good” looks like)

A compliant implementation is an inventory you can hand to an assessor and say: “This is our authoritative list of third parties providing services. Each entry has an owner, describes the service, shows what data or systems are involved, and indicates how critical the provider is. We can show how new providers are added and how changes are captured.” ²

If your inventory is only “vendors we pay,” you will miss free SaaS, contractors engaged by business units, marketing processors, and outsourced IT support. If it is only “apps,” you will miss consultancies, payroll processors, and managed services that have credentials into your environment.

Who it applies to

Entities: Enterprises and technology organizations implementing CIS Controls v8. ¹

Operational contexts where this becomes urgent:

• You use SaaS, cloud hosting, managed service providers (MSPs), or outsourced IT/DevOps.
• You share customer, employee, or regulated data with third parties (processors, call centers, benefits admins).
• Your procurement is decentralized and business units can buy tools directly.
• You need to respond to questionnaires, audits, or incidents quickly and consistently. ²

Control owner(s): Usually Third-Party Risk Management (TPRM), Procurement, Security GRC, or a shared model. The inventory needs both governance ownership (policy/process) and operational ownership (data accuracy).

What you actually need to do (step-by-step)

Step 1: Define inclusion criteria and scope boundaries

Write a short definition that your organization can apply consistently:

• Include: any third party that provides a service to your organization and (a) accesses your systems, (b) processes or stores your data, (c) provides security/IT services, or (d) supports a critical business process.
• Exclude (if you choose): one-time commodity purchases with no ongoing service and no access/data handling.

Document edge cases up front: cloud marketplaces, open-source support subscriptions, staffing firms, consultants using your tools, and affiliates.

Step 2: Choose the “system of record” and assign inventory stewardship

Pick one place where the inventory “wins” in conflicts:

• A GRC tool, TPRM platform, or even a controlled register in your document system can work, as long as ownership and change control are clear.

Assign:

• Inventory steward (maintains data quality, runs reconciliations).
• Relationship owner per provider (business accountable party).
• Security/Privacy reviewer (triage and risk tiering triggers).

Daydream fits naturally here when you need repeatable evidence capture and clean mapping from Safeguard 15.1 to operational tasks and audit-ready outputs, especially if multiple teams contribute updates.

Step 3: Establish required inventory fields (minimum viable, audit-friendly)

Create mandatory fields that support downstream actions. A practical baseline:

Field	Why it matters in practice
Legal entity name + common name	Contracts and enforcement clarity
Service provided (plain language)	Lets you scope due diligence
Relationship owner (name/role)	Accountability and follow-up
Business unit	Decentralized purchasing control
Data types handled (high-level)	Drives security/privacy review scope
Access type (network, admin, API, none)	Determines technical control needs
Hosting/processing location (if known)	Helps with risk and incident response
Criticality tier (e.g., low/med/high)	Prioritizes assessments and monitoring
Contract status + renewal date	Triggers review gates
Subprocessors (if applicable/known)	Supply-chain visibility

Avoid boiling the ocean. Start with fields that drive a decision: “Do we need to assess this provider, contract for controls, and monitor them?”

Step 4: Build intake gates so new providers cannot bypass the inventory

You need a control point where “new service provider” becomes a trackable event:

• Procurement onboarding (preferred).
• Security review for SaaS (CASB discovery + request workflow).
• IT service request (new managed service, new integration).
• Finance/AP vendor setup (use as backstop, not the only gate).

Minimum intake workflow:

1. Requestor submits provider + service description.
2. Inventory steward creates/updates inventory record.
3. Triage for risk tiering and whether deeper due diligence is required.
4. Contracting and security requirements reference the same inventory ID.

Step 5: Reconcile regularly against authoritative sources (completeness control)

Most inventory failures are “unknown unknowns.” Fix this with reconciliation:

• Pull lists from AP/finance, procurement systems, SSO/SaaS discovery, and IT asset/app catalogs.
• Match and deduplicate.
• Investigate gaps: “We pay them but they’re not in inventory,” and “We have an active app but no contract/owner.”

Define what counts as “active” (paid in last period, active login/integration, or in-force contract). Keep the rule consistent so audits do not turn into debates.

Step 6: Operationalize “maintain” with update triggers and a review cadence

Create triggers that require an inventory update:

• New contract or renewal
• Scope change (new data type, new region, new integration)
• Incident involving the provider
• Ownership change (relationship owner leaves)
• Termination/offboarding

Add a recurring review where relationship owners attest the entry is still accurate. Store the attestations as evidence.

Required evidence and artifacts to retain

Keep artifacts that show both design (what you said you’d do) and operation (proof you did it):

• Service provider inventory export (dated) with required fields populated.
• Inventory procedure (definition of service provider, required fields, ownership, update triggers). ²
• Intake records: tickets/forms showing provider onboarding and inventory creation.
• Reconciliation outputs: source lists, match results, gap remediation notes.
• Periodic review/attestation records by relationship owners.
• Change log/history for adds/updates/removals (system audit trail or controlled versioning).
• Mapping of Safeguard 15.1 to your control operation and recurring evidence capture. ¹

Common exam/audit questions and hangups

Expect these, and prepare answers with artifacts:

• “What is your definition of service provider, and who approved it?”
• “How do you ensure completeness across decentralized purchasing?”
• “Show me how a new provider gets added. Is there a control gate?”
• “Who is accountable for each provider relationship?”
• “How do you know the inventory is current?”
• “How do you handle providers engaged by subsidiaries or business units?”

Hangup pattern: teams present a vendor payment list and call it an inventory. Examiners then ask about SaaS, consultants, and managed services discovered elsewhere.

Frequent implementation mistakes (and how to avoid them)

1. Treating AP/finance as the inventory.
   Fix: use AP as one input; require service description, owner, and access/data attributes in the inventory.

2. No owner per provider.
   Fix: make “relationship owner” mandatory. If nobody will own it, you have a governance problem, not a tooling problem.

3. No process for change.
   Fix: define triggers (renewal, scope change, integration change) and require updates through the same workflow used for onboarding.

4. Inventory exists but is not used.
   Fix: require the inventory ID in contracting, risk assessments, and access approvals so teams cannot route around it.

5. Over-scoping fields and stalling.
   Fix: start with a minimum viable dataset, then expand fields once you can prove the maintenance loop works.

Risk implications (why auditors care)

A weak inventory increases:

• Incident response time when a breach involves a third party (you cannot quickly identify affected providers and integrations).
• Contract control gaps (security requirements applied inconsistently).
• Unassessed critical providers (high-impact dependencies with no due diligence trail).
• Hidden access paths (MSPs, contractors, and SaaS integrations that bypass standard controls).

Safeguard 15.1 is also a dependency control. If you do not have the inventory, you cannot reliably execute risk tiering, due diligence scoping, contract enforcement, or ongoing monitoring under a service provider management program. ²

Practical 30/60/90-day execution plan

First 30 days (stand up the minimum viable inventory)

• Approve the service provider definition and inclusion criteria.
• Choose the system of record and assign the inventory steward.
• Publish required fields and a one-page operating procedure.
• Seed the inventory from procurement/AP and known critical IT providers.
• Create an intake form/ticket type that generates an inventory entry.

Days 31–60 (make it complete enough to trust)

• Add reconciliation feeds: AP, procurement, SSO app list, and security discovery outputs if available.
• Run your first deduplication and gap remediation cycle.
• Assign relationship owners and chase missing owners to closure.
• Add a simple criticality tiering method so you can prioritize follow-on work.

Days 61–90 (prove it operates and generate audit-ready evidence)

• Implement renewal and scope-change triggers (contracting and access requests must reference inventory).
• Run the first owner attestation cycle and store evidence.
• Produce an evidence pack: dated inventory export, procedure, sample intake tickets, reconciliation report, and change log.
• If you use Daydream, configure recurring evidence capture and map Safeguard 15.1 to the control operation so audits become a packaging exercise, not a scavenger hunt. ¹

Frequently Asked Questions

What counts as a “service provider” for Safeguard 15.1?

Use a definition your teams can apply consistently: any third party providing a service that accesses your systems, processes your data, or supports a critical process. Document inclusions/exclusions and apply them through intake and reconciliation. ²

Can we meet 15.1 with a spreadsheet?

Yes, if it is controlled, has defined required fields, an owner, and a way to show change history and periodic review. Most teams outgrow spreadsheets when reconciliation and evidence capture become recurring requirements. ²

How do we handle subsidiaries or business units that buy tools directly?

Add backstop discovery sources (SSO app catalogs, expense/AP feeds) and require each business unit to assign relationship owners for any discovered providers. Then route renewals and integrations through the intake gate.

Do we need to inventory non-IT providers (payroll, benefits, call centers)?

If they provide services that touch sensitive data or critical processes, include them. Keeping them out typically breaks completeness and creates blind spots in incident response and contracting.

What evidence is most persuasive to auditors?

A dated inventory export plus proof of operation: intake records, reconciliation outputs, and periodic owner attestations. Auditors want to see you can detect and correct gaps, not just produce a list. ²

How does Daydream help with Safeguard 15.1 without adding process overhead?

Daydream is most useful where teams struggle with repeatable evidence and mapping the safeguard to an operating control. Set up the inventory as the system of record (or connect to it), then automate evidence capture for reconciliations, attestations, and exports. ¹

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8

2. CIS Controls v8

3. CIS Controls Navigator v8