CIS Control 15: Service Provider Management, IG1 to IG3 in Practice

Every other framework on this blog tells you to manage third-party risk; CIS Controls v8.1 tells you the order to do it in. Control 15, Service Provider Management, is seven safeguards laid out across Implementation Groups 1 to 3, so the standard itself answers the question the others leave open: what do I do first, and what can wait until I am more mature? That sequencing is why CIS is the layer practitioners actually build from, and why the same seven safeguards sit underneath a NIS2, ISO 27001, or NIST CSF supplier program.

The starting point is a single IG1 safeguard, 15.1, the service-provider inventory. Get that right and the other six have somewhere to attach. This is Control 15 as an implementation path, not a list, with the evidence each safeguard produces.

The seven safeguards, in the order CIS gives them

Safeguard	What it requires	IG
15.1 Inventory of service providers	Establish and maintain an inventory of service providers	IG1
15.2 Service provider management policy	Establish and maintain a policy governing the lifecycle	IG2
15.3 Classify service providers	Classify by data sensitivity, criticality, or risk	IG2
15.4 Security requirements in contracts	Ensure contracts include security requirements	IG2
15.5 Assess service providers	Assess providers against the policy and requirements	IG3
15.6 Monitor service providers	Monitor for compliance and change over the relationship	IG3
15.7 Securely decommission service providers	Terminate access and handle data on offboarding	IG3

The IG column is the roadmap. IG1 (essential cyber hygiene, appropriate for every organisation) asks only for 15.1, the inventory. IG2 adds the policy, classification, and contractual requirements. IG3 adds the resource-intensive assessment, monitoring, and secure decommissioning. You do not jump to 15.5 assessment before 15.1 inventory exists, there is nothing to assess.

Building the 15.1 inventory on a real estate

The safeguard is short; doing it completely is not, because the hard part is finding the providers, not recording them. Three sources, reconciled, get you a real inventory:

1. Procurement and accounts payable give you the paid providers, the obvious tier.
2. Microsoft 365 and Entra ID surface the ones procurement never saw: enumerate enterprise applications (OAuth-consented and federated apps) in Entra ID and you will find SaaS in daily use that no one bought through a PO. This is where shadow providers live.
3. Egress and DNS logs catch the rest, external services your systems actually talk to that appear in neither of the above.

Record, per provider: name, the service, a classification (populated once 15.3 exists), the data or systems it can access, a contact, the contract reference and dates, and an owner. Keep it one row per service where a provider delivers several, because the risk is in the service, not the company name.

IG2: policy, classification, and contract terms

15.3 classification is the highest-leverage IG2 safeguard, because it makes everything above it proportionate. Classify by data sensitivity and business criticality, in Microsoft 365 you can lean on Purview sensitivity labels to inform which providers touch regulated or confidential data. A provider handling labelled-confidential data is a different risk tier from a marketing widget, and the classification is what tells 15.4 how hard the contract needs to push and 15.5/15.6 how deeply to assess and how often to monitor.

15.4 puts security requirements into the contract, proportionate to the classification: security standards to meet, incident-notification duties, data handling and return, sub-processor disclosure, and the right to evidence or audit. 15.2 is the policy that ties the lifecycle together, who owns the inventory, how providers are onboarded, classified, assessed, and offboarded.

IG3: assess, monitor, decommission

The IG3 safeguards are where cost concentrates, which is why CIS defers them. 15.5 assessment does not mean auditing every provider from scratch; for most, accepting a current SOC 2 Type II or ISO 27001 certificate on file is the assessment, with questionnaires reserved for higher-classification providers without third-party attestation. 15.6 monitoring is a cadence tied to classification plus trigger events (a provider breach, a service change, an expiring certification). 15.7 secure decommissioning is the most-forgotten safeguard in the whole control: when a provider relationship ends, revoke their access (including the OAuth grants and federated trust you enumerated for 15.1), confirm data return or destruction, and record it. A terminated provider that still holds a valid token or a copy of your data is a live exposure that no monitoring will catch, because you stopped looking.

Common mistakes

1. Chasing IG3 assessment and monitoring while the 15.1 inventory is still incomplete, securing a list that is missing its riskiest entries.
2. Building the inventory from procurement only, so shadow SaaS and OAuth-connected apps never appear.
3. Skipping 15.3 classification, so every provider gets the same treatment and effort is misallocated.
4. Re-auditing providers under 15.5 instead of accepting SOC 2 / ISO attestations for the routine ones.
5. Treating 15.7 decommissioning as a procurement step, leaving tokens, access, and data behind.
6. Picking an IG above your resourcing and operating none of it well, better to fully land IG1–IG2 than fake IG3.

What an assessor looks for

CIS Controls are typically self-assessed (CIS-CAT, the CIS Controls Self Assessment Tool, or a WorkBench-based review), and increasingly used as the practical evidence layer beneath an ISO, NIST, or NIS2 program. The assessment of Control 15 follows the safeguards:

1. Does a complete 15.1 inventory exist, and can you show how it is kept current, including the non-procurement discovery?
2. At IG2, is there a policy (15.2) and a classification scheme (15.3) that actually drives differentiated treatment?
3. Do contracts carry security requirements (15.4) proportionate to classification?
4. At IG3, is there assessment (15.5) and monitoring (15.6) evidence, with attestations on file?
5. Is decommissioning (15.7) actually performed, access revoked and data handled, with a record?

Declaring an IG you cannot evidence is worse than declaring a lower one honestly; the assessment is against the safeguards you claim.

Evidence and documentation to keep

• The service-provider inventory (15.1) with classification and owners, plus the discovery method that keeps it complete.
• The service-provider management policy (15.2) and the classification scheme (15.3).
• Contract security clauses (15.4) mapped to classification.
• Assessment artefacts, SOC 2 / ISO certificates on file, questionnaire results (15.5), and the monitoring cadence with records (15.6).
• Decommissioning records (15.7): access revocation, data return/destruction confirmation, dates.

The same discipline across frameworks

Control 15 is the most prescriptive, sequenced expression of a discipline every framework shares: know your providers, classify them, put requirements in contracts, assess, monitor, and decommission. The 15.1 inventory is the same register that satisfies the others; build it once and map it outward. Mappings are approximate and directional.

Framework	Control	Posture
DORA	Art 28(3) + ITS (EU) 2024/2956	Prescriptive, machine-validated register (financial entities)
NIS2	Art 21(2)(d)	Outcome-based directive; direct suppliers; no format
ISO/IEC 27001:2022	A.5.19–A.5.23	Certifiable; justified in the Statement of Applicability
NIST CSF 2.0	GV.SC	Outcome-based; profiles and tiers
CIS Controls v8.1 (this article)	Control 15	Prescriptive safeguards, IG1→IG3

Key takeaways

• Control 15's IG structure is the sequencing answer the other frameworks don't give, do 15.1 first, add the rest by maturity.
• Build 15.1 from procurement plus Entra enterprise apps plus egress/DNS, or the inventory misses its riskiest entries.
• 15.3 classification is the leverage point; it makes contracting, assessment, and monitoring proportionate.
• 15.5 assessment mostly means accepting SOC 2 / ISO attestations, not re-auditing everyone.
• 15.7 secure decommissioning is the most-forgotten safeguard; revoke tokens and access, confirm data handling, record it.

References and further reading

• CIS Critical Security Controls v8.1, Control 15 Service Provider Management and its safeguards.
• CIS Controls Implementation Groups (IG1–IG3) guidance, for matching safeguards to organisational maturity.
• Provider trust portals for the SOC 2 and ISO 27001 attestations relied on under safeguard 15.5.

Frequently Asked Questions

Which Control 15 safeguards apply to us?

It depends on your Implementation Group. IG1, appropriate for every organisation, requires only 15.1, the service-provider inventory. IG2 adds 15.2 policy, 15.3 classification, and 15.4 contractual requirements. IG3 adds 15.5 assessment, 15.6 monitoring, and 15.7 secure decommissioning. Match your IG to your risk and resources rather than claiming more than you can operate.

What goes in the 15.1 service-provider inventory?

Per provider and service: name, the service delivered, a classification, the data or systems it can access, a contact, the contract reference and dates, and an internal owner. Build it from procurement, Entra ID enterprise applications, and egress/DNS logs together, since procurement alone misses shadow SaaS and OAuth-connected apps.

Do we have to audit every service provider for 15.5?

No. For most providers, holding a current SOC 2 Type II or ISO 27001 certificate on file satisfies the assessment; reserve security questionnaires for higher-classification providers that lack third-party attestation. The classification you set under 15.3 determines how deep 15.5 assessment and 15.6 monitoring need to go.

What does secure decommissioning (15.7) actually involve?

When a provider relationship ends: revoke all access including OAuth grants and federated trusts, confirm return or destruction of your data, remove any remaining integrations, and record that it was done with a date. It is the most-skipped safeguard, and a terminated provider that retains a valid token or a data copy is an exposure ongoing monitoring will not catch.

---