CIS Control 15 asks for a process to evaluate service providers that hold sensitive data or run critical IT platforms, so they protect those platforms and data appropriately. Evidence is a provider inventory with data classes, assessment records at onboarding, and periodic reviews. Engineering supplies the list of tools and the data each touches.
What the control covers
The Center for Internet Security describes Control 15, "Service Provider Management", as developing a process to evaluate service providers who hold sensitive data, or are responsible for an enterprise's critical IT platforms or processes, to ensure these providers are protecting those platforms and data appropriately.
Two triggers define scope: a provider holds sensitive data, or a provider runs something critical. Source hosts, CI services, cloud platforms, registries and monitoring tools often qualify on both counts.
The evidence set
| Element | Artifact |
|---|---|
| Know your providers | Inventory with owner, service, data classes and criticality |
| Evaluate | Assessment record at onboarding, such as questionnaire or report review |
| Agree | Contract or terms with security requirements |
| Monitor | Periodic review, status page and incident notices tracked |
| Exit | Offboarding plan, data return and access removal |
Engineering has special knowledge here. Only the team can say which tools hold source code, secrets or customer data, so ask engineers to keep the provider list accurate.
Steps to run a lean process
- Export tools from billing, identity provider sign ins and cloud marketplace purchases to find providers.
- Classify each by the sensitivity of data it holds and how critical it is.
- Assess in depth only the high ones, and keep a lighter check for the rest.
- Record what you reviewed and what you concluded, including accepted gaps.
- Review high risk providers on a regular rhythm and after notable incidents.
- Remove access and collect data when a provider is retired.
Do not forget providers with embedded access, such as an app that holds a token for your source host.
Worked example for one tool
Take a hosted CI service. It holds your source code in build workspaces, it holds secrets used to deploy, and it can change what reaches production, so it is high on both triggers. Your record might note the data classes it touches, who administers it, how single sign on is enforced and where its audit events go. It would also note what you read when you assessed it, the date you read it and any gap you accepted, such as a region you cannot choose.
Next review, check what changed: new features that widen access, new sub processors, incidents the provider reported and changes in your own use. One page per high risk provider, updated at each review, is plenty. If you can hand an assessor that page and the change history, you have shown evaluation, not just a vendor list.
Cautions
A vendor badge or report is input, not a conclusion. Read the scope and the date. Keep your own record of what you decided. Never repeat a provider's claims as your own in customer answers without checking them.
Where Safeguard fits
Safeguard offers compliance and evidence automation alongside SBOM and dependency scanning, which can help you collect dated records in one place. You can try the free scan at gold.safeguard.sh/scan. The decision on whether evidence is sufficient stays with your assessor.
Quick check
Are open source dependencies service providers?
Not in the CIS wording, which concerns providers of services. They are covered by software controls such as inventory and application security.
How deep should an assessment go?
Scale it to the data held and the criticality. Write the rule and apply it consistently.
Sources
- CIS Control 15: Service Provider Management, Center for Internet Security
- CIS Controls list, Center for Internet Security
- CIS Controls v8.1, Center for Internet Security
Last reviewed: 19 October 2026.
