Safeguard 15.3 Classify service providers

Safeguard 15.3 asks you to classify each service provider so assessment and monitoring effort follows the risk. This page explains what an assessor tests, which evidence passes, and what the work costs in-house or with a partner.

On this page

What Safeguard 15.3 asks you to do with service provider classification

If you are a compliance lead or engineer who has to show that service providers are classified and that those classes drive how deeply each provider is assessed, Safeguard 15.3 asks for exactly that. It requires the enterprise to classify its service providers by characteristics such as data sensitivity, data volume, availability requirements, applicable regulations, inherent risk and mitigated risk, and to review those classifications at least annually, or sooner when a significant enterprise change could affect them. The safeguard sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1, and it is assigned to the Users asset class and the Govern security function.

Safeguard 15.3 cannot stand alone. The CIS Controls Assessment Specification treats Safeguards 15.1, the service provider inventory, and 15.2, the service provider management policy, as prerequisites for measuring it. In practice that means every provider you classify must already appear in the inventory with an enterprise contact, and the policy must describe the classification process itself. If the policy has no classification process, the assessment specification scores 15.3 as failing regardless of how carefully individual providers were rated, so the policy wording is the first thing to confirm.

Three problems make this safeguard hard in practice. First, many organizations have no agreed criteria, so one team rates a provider as high risk for reasons another team would not accept. Second, no one owns the classification, so it drifts after the first exercise. Third, the classes never reach the assessment schedule, so a provider marked critical is still assessed on the same cycle as a low-impact vendor. The useful test is whether a class change alters the assessment method, frequency or monitoring depth for that provider. If it does not, the classification is a label rather than a control, and the assessment specification's Coverage measure, the share of providers with a classification, will look healthy while the safeguard delivers little.

Which service providers and classifications fall in scope for 15.3

Safeguard 15.3 applies to IG2 and IG3 enterprises and only to providers already recorded in the 15.1 inventory. The cards below separate the parallel decisions that determine which providers receive a classification and how the classification is recorded, so that assessment and monitoring effort can follow it.

Providers that hold sensitive data

Start with every provider that stores, processes or can reach sensitive enterprise data, including SaaS tools holding customer records, backup vendors holding copies of production data and analytics platforms receiving data extracts. Classify these on data sensitivity and data volume together, since a provider holding a small set of regulated records can still warrant a higher class than one holding large volumes of public material. Confirm the data types each provider actually receives, not only those named in the contract.

Providers that run critical IT platforms

Second, classify providers that host or operate systems the business cannot function without, such as cloud hosting, managed networks, identity services and payment processing platforms. For these, availability requirements carry as much weight as data sensitivity. Record the recovery expectations the business depends on, and check whether the provider's own dependencies, such as upstream hosting or DNS, would extend an outage beyond the provider itself.

Providers with operational dependence but no data access

Some providers never see enterprise data yet still shape operations, for example a facilities contractor who controls building access systems, a telecom carrier supplying links or a vendor whose software updates run on internal hosts. Classify them on inherent risk and the impact of their failure or compromise, not on data alone. Ask each one what privileged access, network paths or update channels it holds, because those determine the risk even where no data is involved.

Providers acquired through business units

Providers bought directly by departments, often on corporate cards or through free trials, are the most likely to be missing from the inventory and therefore unclassified. Search expense records, single sign-on logs and procurement tickets for these providers, then bring each into the 15.1 inventory before assigning a class. Decide in the policy whether business-unit providers receive the same classification process as centrally procured ones, and who in the enterprise is accountable for their classification.

Confirming the inventory before classifying

Classification follows the inventory. A provider that is not recorded in the 15.1 inventory with an enterprise contact cannot be classified, and the Coverage measure for 15.3 counts only classified providers. Before scoring, reconcile the inventory against contracts, payables and identity provider application lists, then mark any gaps for correction. Keep the policy definition of a service provider consistent with the inventory so the two sources do not disagree.

How to build classification criteria that an assessor can check

Safeguard 15.3 is only as strong as the criteria behind each classification. An assessor scoring the Coverage metric will ask whether every service provider has a class, but a stronger question is whether two people classifying the same provider would reach the same tier. The practical step is to turn the six named characteristics (data sensitivity, data volume, availability requirements, applicable regulations, inherent risk and mitigated risk) into a short tier model, typically three or four tiers, where each tier has a written threshold. For example, an illustrative rule might say that any provider holding personal or payment data in production is Tier 1, that a provider whose outage stops a customer-facing process beyond an agreed recovery window is Tier 1 on availability, and that a provider with no regulated data and no critical dependency is Tier 3. Write the thresholds in your policy under Safeguard 15.2, define terms such as sensitive data with the glossary wording you already use, and record which characteristic drove the final tier so the decision can be reproduced.

Each tier should set two things that an assessor can verify: the depth of assessment under Safeguard 15.5 and the monitoring cadence under Safeguard 15.6. A Tier 1 provider might require a current independent report, a completed questionnaire and a review of contract security terms before onboarding, with reassessment at least annually, while a lower tier might accept a self-attestation with spot checks. The reader should decide these depths before the first assessment, not after, because a classification that does not change the work is hard to defend. Confirm that the classification is reviewed at least annually, and sooner after significant enterprise changes such as a new regulated product, an acquisition or a move of a critical workload to a new provider, since the assessment specification expects that trigger.

Tracking this in a tool can reduce manual effort, but it does not replace the criteria. CISO Assistant, licensed under AGPL-3.0-only, ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and can run audits and compliance assessments with automatic mapping between frameworks, which can help when one provider serves several regulated obligations. Before relying on it, confirm with the vendor and in your own environment whether it can store your tier definitions, attach per-provider classifications with a review date, and produce the assessment depth each tier requires. If a feature is missing, a spreadsheet with the same fields and a documented review record will still meet the requirement, provided the evidence is consistent and retrievable for an assessor.

How an assessor tests the classification in Safeguard 15.3

This table walks through the test steps an assessor would likely follow for Safeguard 15.3, from reading the policy to checking reviews, with the evidence requested at each step and the findings that usually cause a gap. Read it as a preparation checklist: each row is something to verify in your own records before an assessor asks for it.

Test stepWhat the assessor asks forEvidence requestedCommon findings
Read the policy for a classification processConfirm the service provider management policy defines how providers are classified, which characteristics count and who approves the resultThe approved policy version, its approval record and the classification procedure or criteria it referencesNo classification process in policy, which the assessment specification scores as failing; criteria that name no characteristics
Check the named characteristicsConfirm the classification considers data sensitivity, data volume, availability requirements, applicable regulations, inherent risk and mitigated riskThe classification criteria, scoring scale or tiering model, and a worked example for at least one providerCriteria cover only one or two characteristics, such as data sensitivity alone; inherent and mitigated risk are not separated
Sample providers from the inventoryPull a sample from the service provider inventory from Safeguard 15.1 and check each sampled provider has a classificationThe inventory extract, the sample selection method and the classification record for each sampled providerClassifications missing for inventoried providers, especially recent or low-profile suppliers; inventory and classification records that do not match
Measure coverageCalculate the share of service providers that carry a classification, the Coverage metric the assessment specification usesCoverage calculation from the inventory and classification register, with the date of the countCoverage below full because unclassified providers were left out of the count; providers classified on paper but not recorded in the register
Check the classification drives effortConfirm assessment and monitoring depth for each tier follows from the classification, as the policy requiresAssessment or monitoring records for a high and a low tier provider showing different depth or frequencyClassification recorded but never used; every provider assessed the same way regardless of tier
Check the annual reviewConfirm classifications are reviewed and updated at least annuallyReview dates, review minutes or sign-off records, and the list of providers reviewed in the last cycleReviews that never happened; annual review logged but classifications unchanged; review dates older than the last cycle
Check event-driven updatesConfirm classifications are updated sooner when significant enterprise changes could affect them, such as a new data type, a new regulation or a mergerChange records or tickets that link a significant change to a reclassification, with datesNo trigger defined in policy; significant changes such as new data flows or acquisitions with no reclassification
Confirm prerequisites are in placeConfirm Safeguards 15.1 and 15.2 exist, since the assessment specification treats them as prerequisites for measuring 15.3The inventory from 15.1 and the policy from 15.2, both current and approvedClassification attempted without an inventory or governing policy, so the results cannot be traced to a provider list

Implementing Safeguard 15.3 step by step

This sequence takes an enterprise from a provider list and policy to a classified provider population, with each tier tied to a defined depth of assessment and monitoring and a review cycle that stays current. Each step closes with a named output that an assessor can inspect.

  1. Confirm the 15.1 inventory and 15.2 policy exist

    Before classifying anything, confirm that the service provider inventory required by Safeguard 15.1 and the service provider management policy required by Safeguard 15.2 are in place. The assessment specification treats both as prerequisites for measuring 15.3, so gaps here will carry into the classification. Check that the inventory lists each provider with an enterprise contact, and that the policy names classification as a required process. The output is a short gap list signed off by the owner of the policy. Confirm the gaps are closed or scheduled before moving on.

  2. Agree the classification criteria and tiers

    Define the characteristics that will drive each provider's classification. Safeguard 15.3 names data sensitivity, data volume, availability requirements, applicable regulations, inherent risk and mitigated risk, so each criterion should have a defined scale and a clear question to answer. Decide how many tiers the enterprise will use and what separates them. Security, privacy, compliance and the business owners of critical services should agree on the wording, because the criteria will be applied to every provider. The output is a criteria document that lists each characteristic, its scale, its tier thresholds and the approver.

  3. Classify the current provider population

    Apply the criteria to every provider in the inventory, one record at a time. Record the answers and the reason for each tier so a reviewer can trace the result. Where a provider holds several data types, classify it at the level of its most sensitive or most critical service, and note any provider whose data flows are unclear so it can be checked with the business owner. Each provider should carry one current classification. The output is a classified inventory that shows the tier, the date and the person who approved it. The coverage measure in the assessment specification is the share of providers with a classification, so this output should reach full coverage of the inventory.

  4. Link each tier to assessment and monitoring depth

    Classification only reduces effort if it changes what happens next. For each tier, define the depth of assessment under Safeguard 15.5 and the monitoring activity under Safeguard 15.6, such as the type of evidence requested, whether an independent report is expected, and how often reassessment occurs. Higher tiers receive more scrutiny and lower tiers less, but every tier should have a defined minimum. Confirm with the team that will run assessments whether they can staff the planned depth. The output is a tier-to-assessment mapping that the policy references, so the assessment and monitoring work can be traced back to the classification.

  5. Set the annual and event-triggered review

    Schedule the classification review at least once a year, and add a trigger for reviews when significant enterprise changes could affect the safeguard. Typical triggers include a new regulation that applies to the business, a change in the data a provider holds, a material change in a provider's service, an acquisition or a major incident involving a provider. Assign an owner for the review and a method for raising triggers from other teams. Confirm the annual interval and the trigger list against the policy approved under Safeguard 15.2. The output is a review schedule and trigger list written into the policy.

  6. Record the outputs for audit evidence

    Keep the records that show the classification process works and is maintained. This includes the approved criteria document, the classified inventory with change history, the tier-to-assessment mapping, and a review log that records each annual review and each event-triggered review, with the date, the reviewer, the changes made and the approval. Store these in a system that keeps version history and access control, so an independent assessor can see how classifications changed over time. Ask the team to walk through the log with a sample of providers to confirm the records match the inventory. The output is an evidence set that a reviewer can test against the Safeguard 15.3 measures.

Evidence that shows a service provider classification passes

Safeguard 15.3 is tested by what the enterprise can show, not by what it says it does. The six artifacts below connect the classification criteria in the policy, the register that applies them, and the review and change records that keep the register accurate between assessments. Each card names what to keep current and how an assessor will check it.

Approved classification criteria

The written criteria that sort providers into tiers sit in the service provider management policy governed by Safeguard 15.2. Assessors look for the characteristics the enterprise weighs, such as data sensitivity, data volume, availability requirements, applicable regulations, inherent risk and mitigated risk, and for evidence that an accountable owner approved them. Check that each criterion has a defined scale or decision rule, so two reviewers reach the same tier for the same provider. Record the approval date and version of the policy.

Classified provider register

The register lists every provider from the 15.1 inventory with its assigned tier, the date the tier was set and the enterprise contact responsible for it. The Coverage metric in the assessment specification is calculated directly from this list, so a provider without a tier is a visible gap. Keep the register in a controlled system with change history turned on, and reconcile it against procurement and accounts payable records at each review so that new providers do not appear in only one of them.

Tier-to-assessment mapping

This document shows what each tier requires in assessment depth and monitoring frequency, for example which tiers accept an independent attestation such as a SOC 2 report and which require a questionnaire or onsite review. It is the link that proves classification drives effort, which is the purpose of Safeguard 15.3. Assessors will compare a sample of high-tier providers against their assessment records. Confirm the mapping matches the provider management policy as approved, and date each revision.

Dated review records

The assessment specification expects classifications to be reviewed at least annually and sooner after significant enterprise changes. Keep signed or system-recorded review minutes that list the providers reviewed, the tier confirmed or changed, and the reviewer. Tie each review date to the register so the register shows when every tier was last confirmed. An empty or missing review cycle is the most common reason a classification that exists on paper fails on evidence.

Change records that triggered reclassification

Significant changes to the enterprise or to a provider, such as a new data category, a move into a regulated activity, a merger, or a provider's expansion into new regions, should produce a reclassification record. Log the trigger, the date it was identified, the old and new tier, and the approver. Assessors use these records to test whether the event-driven part of the requirement is working between scheduled reviews. Keep prior tier versions instead of overwriting them, so the history of each provider can be reconstructed.

Coverage calculation

The Coverage metric is the share of service providers that hold a classification. Keep a dated calculation showing the count of providers in the 15.1 inventory, the count with a current tier, and the resulting percentage, generated from the register rather than typed by hand. Ask the team to confirm which providers are excluded and why, because unexplained exclusions are the first thing an assessor will question. Repeat the calculation at each review so the trend is visible.

What meeting Safeguard 15.3 costs in money and effort

This table compares each cost component of classifying service providers, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use it to decide where to spend effort and what to request in a quote, since no price is published for this safeguard.

Cost componentOne-time or recurringWhat drives it up or downWhat to ask for in a quote
Classification criteria and policy designOne-time, then revised when criteria changeNumber of business lines, regulations in scope and how many classification levels the enterprise wants; a narrow set of criteria keeps design time shortNamed deliverable for the criteria matrix, the classification process text for the 15.2 policy and a review session with risk and legal owners
Initial classification of the existing provider populationOne-timeNumber of providers already in the 15.1 inventory, quality of contract and data-flow records, and how many providers hold sensitive dataEffort per provider, assumptions about records the client supplies and a list of providers the partner cannot classify without client input
Register and review tooling or licensesRecurring if commercial, one-time setup if self-hostedWhether the register lives in a spreadsheet, a GRC platform or a self-hosted tool; per-user or per-entity licensing raises recurring costLicensing model, support terms and whether the tool can hold classification fields, owners and review dates. Confirm each open-source tool's license terms before adoption
Annual classification reviewRecurring, at least once a yearProvider count, number of reclassifications since last review and whether significant enterprise changes trigger extra reviewsReview scope per cycle, who signs off each classification and how the partner records changes for the auditor
Upkeep when providers or services changeRecurring, event-drivenFrequency of new vendors, mergers, new data types and new regulations; clear intake triggers reduce reworkIntake form, change triggers and a turnaround expectation agreed in writing before work starts
Auditor sampling and evidence walkthroughRecurring, usually at each assessmentNumber of providers the auditor samples, how current the classification records are and how well the rationale for each class is documentedEvidence pack listing classifications, rationale, review dates and sign-offs, and an agreed format the independent auditor accepts
Partner preparation supportOne-time or retainerWhether the partner prepares evidence only or also runs the reviews; retainers add recurring costWhether the scope is fixed and written, which deliverables are included and which are optional

Who owns classification, who can help, and where the auditor stops

Your organization owns the classification scheme from start to finish. Staff who understand the business, the data each provider touches and the regulations that apply decide which characteristics matter and where each provider belongs. Those decisions carry the organization's accountability, so they cannot be delegated to a vendor or consultant.

  • Criteria: Define the characteristics the policy uses, such as data sensitivity, data volume, availability requirements, applicable regulations, inherent risk and mitigated risk, and agree what each tier level means.
  • Tier decisions: Assign each provider to a tier, record the reasoning and name the person accountable for the decision.
  • Annual review: Re-check classifications at least once a year, and sooner after significant enterprise changes such as a new regulated business line, a merger or a major data migration.
  • Coverage: Confirm that every provider in the inventory from Safeguard 15.1 carries a classification, because the assessment measures the share that does.

Check that the policy in Safeguard 15.2 names who approves tiers and that each review date is recorded somewhere an assessor can see.

Where organizations fall short on service provider classification

Safeguard 15.3 is simple to state and easy to fake. Most gaps come from classification that exists in one place but is never used by the people who assess, monitor and approve providers. The cards below cover the failure points that assessors tend to find first, with a fix for each.

Classification lives in a procurement spreadsheet

Many enterprises tag providers as critical or low risk in a procurement tracker that the security assessment team never opens. Safeguard 15.3 asks for providers to be classified, and the classification only matters if assessment and monitoring follow it. Check whether the security team can see every provider's tier, owner and last review date in the same system used to schedule assessments. Ask one question during testing: who would be notified if a high-tier provider changed its hosting region.

Criteria exist only as a verbal rule

Teams often say that anything touching customer data is high tier, but the rule is not written down and two managers apply it differently. The Assessment Specification scores Safeguard 15.3 as failing when the enterprise has no classification process in its policy, so an unwritten rule does not count. Write the criteria as a short table covering data sensitivity, data volume, availability requirements, applicable regulations, inherent risk and mitigated risk, and record who approved it.

No link between tier and assessment depth

A provider can be labeled critical while still receiving the same questionnaire as a low-impact vendor. Classification only reduces effort when each tier sets what is required, such as which attestation reports to request, how deep reassessment goes and who signs off. Map each tier to a minimum assessment set in the policy. During testing, pick a high-tier provider and confirm its assessment matches the tier's required set rather than a generic form.

Reviews happen only at renewal

Classifications made at contract signing often outlast the facts behind them. Safeguard 15.3 calls for classifications to be reviewed and updated annually, or sooner after significant enterprise changes that could affect the Safeguard, such as a merger, a new data category or a move to a different cloud region. Check the date each classification was last confirmed, and confirm that a trigger list exists so changes prompt a reclassification rather than waiting for the contract to expire.

Frameworks mapped separately

Teams often classify providers once for ISO/IEC 27001, again for PCI DSS and again for NIST work. The CIS Controls Navigator links Safeguard 15.3 to NIST CSF 2.0 GV.SC-04, NIST SP 800-53 Rev. 5 AC-20 and SR-6, ISO/IEC 27001:2022 Annex A 5.19 and PCI DSS v4.0 12.8.5. One well-defined classification can therefore support several frameworks. Confirm that the same record feeds each framework's evidence, and that the mapping is checked against the current Navigator version before an audit.

Questions buyers ask about Safeguard 15.3 cost, effort and help

How much effort does classifying service providers take?

Effort depends mostly on how many providers you have, how much data each one holds, and how complete your existing records are. The work has three parts: agreeing the classification criteria in your policy, gathering facts about each provider (data types, record volumes, availability needs, applicable regulations, and inherent and mitigated risk), and assigning each provider to a tier. The first pass is the heaviest. Later reviews are lighter because they only check changes. Expect the largest share of time to go into collecting facts that nobody has written down, such as which systems a provider can reach and what data it stores. Ask any partner to show how they will estimate effort from your provider count and the depth of your records before agreeing a fixed scope.

Can we classify our service providers without outside help?

Yes. CIS Controls content is free for organizations to use to improve their own cybersecurity, and the classification work is a governance exercise that your own staff can perform. The main requirements are a written classification process in your service provider management policy, a current inventory (Safeguards 15.1 and 15.2 come first), and a named owner who reviews the results. Outside help is most useful when the internal team lacks time, has no shared view of data sensitivity, or needs someone to challenge the tiers before an auditor sees them. A partner can prepare the workbook, facilitate the review and document the decisions, but the organization remains responsible for the classifications it adopts.

What does the work need from our own staff?

The work needs people who know the business and the data, not only security staff. Typically this includes a service provider or vendor manager who owns the inventory, a data owner who can state what information each provider handles, a compliance or legal contact who can identify the regulations that apply, and an IT or security lead who can describe system access and availability needs. Each person should expect to answer questions and review drafts rather than run the project. Confirm named individuals and their availability before the start date, because missing data owners are one of the most common reasons classification stalls.

How long does it take to reach a first defensible classification?

The duration depends on the number of service providers in scope, how current your inventory is, and how many people must review the results. No duration is fixed in the CIS material for this Safeguard, so treat any timeline as an estimate to confirm in writing. A small, well-documented provider list can be classified much faster than a large list spread across business units with incomplete records. Ask for the planned phases, the number of review cycles and the point at which the tiers are signed off by a named owner. A defensible first classification is one where every provider has a tier, the criteria are written down, and the reasons for each tier can be traced to documented facts.

Does Safeguard 15.3 apply to IG1 organizations?

No. Safeguard 15.3 is placed in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1. IG1 organizations still benefit from the service provider inventory in Safeguard 15.1, which is the only Control 15 Safeguard in IG1. If you are an IG1 organization, focus on building that inventory first. If you are an IG2 or IG3 organization, classification is required, and the annual review applies, with an earlier review when significant enterprise changes could affect the Safeguard. Confirm your Implementation Group against the CIS Implementation Groups pages before you scope the work.

What can a partner do for the auditor's review, and what can't it do?

A partner can prepare the classification criteria, the provider tiers, the supporting facts and the records that show how decisions were made, so your evidence is organized and traceable. It can also run walkthroughs with your staff so they can explain the process to an assessor. A partner cannot issue an assessment result, a report or a certificate, and it cannot decide whether your classifications meet the Safeguard. Only the independent assessor or certification body you engage can reach that conclusion. Agree in writing which artifacts the partner will produce, who approves them, and how questions from the assessor will be routed back to your team.

How DeployOpen works on this

DeployOpen helps organizations prepare the systems, records and evidence behind Safeguard 15.3 Classify service providers, inside the client's own infrastructure. The organization keeps ownership of its classification decisions, and an independent auditor or assessor reviews the result, since DeployOpen does not issue reports or certifications.

How we scope

  • Agree in writing which service providers, data types and systems fall under the classification process.
  • Define the classification criteria: data sensitivity, data volume, availability needs, regulations, inherent and mitigated risk.
  • Confirm the review cycle, which must be at least annual and sooner after significant enterprise changes.

How we build

  • Configure the service provider inventory and classification fields so each provider carries its assigned class and owner.
  • Set up the classification workflow in a self-hosted tool, such as CISO Assistant, to record decisions and review dates.
  • Test that each provider has a classification, so coverage can be measured against the assessment specification.

How we hand over

  • Document the classification method, roles and the criteria used, in language the organization's owners can maintain.
  • Deliver the coverage evidence, decision records and review history that an assessor would ask to see.
  • Walk the internal owners through the process so classification stays current after the engagement ends.

How we support

  • Offer ongoing support as a retainer for reclassification after changes in providers, data or regulations.
  • Keep the workflow and evidence current across upgrades to the self-hosted tooling.
  • Confirm with your auditor or assessor which evidence formats and sampling they expect before work starts.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.