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 step | What the assessor asks for | Evidence requested | Common findings |
|---|---|---|---|
| Read the policy for a classification process | Confirm the service provider management policy defines how providers are classified, which characteristics count and who approves the result | The approved policy version, its approval record and the classification procedure or criteria it references | No classification process in policy, which the assessment specification scores as failing; criteria that name no characteristics |
| Check the named characteristics | Confirm the classification considers data sensitivity, data volume, availability requirements, applicable regulations, inherent risk and mitigated risk | The classification criteria, scoring scale or tiering model, and a worked example for at least one provider | Criteria cover only one or two characteristics, such as data sensitivity alone; inherent and mitigated risk are not separated |
| Sample providers from the inventory | Pull a sample from the service provider inventory from Safeguard 15.1 and check each sampled provider has a classification | The inventory extract, the sample selection method and the classification record for each sampled provider | Classifications missing for inventoried providers, especially recent or low-profile suppliers; inventory and classification records that do not match |
| Measure coverage | Calculate the share of service providers that carry a classification, the Coverage metric the assessment specification uses | Coverage calculation from the inventory and classification register, with the date of the count | Coverage 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 effort | Confirm assessment and monitoring depth for each tier follows from the classification, as the policy requires | Assessment or monitoring records for a high and a low tier provider showing different depth or frequency | Classification recorded but never used; every provider assessed the same way regardless of tier |
| Check the annual review | Confirm classifications are reviewed and updated at least annually | Review dates, review minutes or sign-off records, and the list of providers reviewed in the last cycle | Reviews that never happened; annual review logged but classifications unchanged; review dates older than the last cycle |
| Check event-driven updates | Confirm classifications are updated sooner when significant enterprise changes could affect them, such as a new data type, a new regulation or a merger | Change records or tickets that link a significant change to a reclassification, with dates | No trigger defined in policy; significant changes such as new data flows or acquisitions with no reclassification |
| Confirm prerequisites are in place | Confirm Safeguards 15.1 and 15.2 exist, since the assessment specification treats them as prerequisites for measuring 15.3 | The inventory from 15.1 and the policy from 15.2, both current and approved | Classification 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.
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.
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.
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.
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.
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.
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 component | One-time or recurring | What drives it up or down | What to ask for in a quote |
|---|---|---|---|
| Classification criteria and policy design | One-time, then revised when criteria change | Number of business lines, regulations in scope and how many classification levels the enterprise wants; a narrow set of criteria keeps design time short | Named 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 population | One-time | Number of providers already in the 15.1 inventory, quality of contract and data-flow records, and how many providers hold sensitive data | Effort 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 licenses | Recurring if commercial, one-time setup if self-hosted | Whether the register lives in a spreadsheet, a GRC platform or a self-hosted tool; per-user or per-entity licensing raises recurring cost | Licensing 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 review | Recurring, at least once a year | Provider count, number of reclassifications since last review and whether significant enterprise changes trigger extra reviews | Review scope per cycle, who signs off each classification and how the partner records changes for the auditor |
| Upkeep when providers or services change | Recurring, event-driven | Frequency of new vendors, mergers, new data types and new regulations; clear intake triggers reduce rework | Intake form, change triggers and a turnaround expectation agreed in writing before work starts |
| Auditor sampling and evidence walkthrough | Recurring, usually at each assessment | Number of providers the auditor samples, how current the classification records are and how well the rationale for each class is documented | Evidence pack listing classifications, rationale, review dates and sign-offs, and an agreed format the independent auditor accepts |
| Partner preparation support | One-time or retainer | Whether the partner prepares evidence only or also runs the reviews; retainers add recurring cost | Whether 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.
An implementation partner can reduce the drafting and administrative load, but it prepares material and systems for your decisions. The partner does not set the tiers. Its work is to make the process consistent and easy to evidence once your staff have approved the approach.
- Criteria draft: Prepare a first draft of the classification criteria and tier definitions for your review and approval.
- Register build: Build the register that links each provider to its tier, data types, enterprise contact and next review date.
- Tooling configuration: Configure the tooling you choose to hold the register and report coverage, such as a self-hosted governance platform running in your own infrastructure.
- Evidence organization: Collect and organize the approvals, review records and change logs that show the classification process actually ran.
- Ownership boundary: Your organization still makes and owns the tier decisions and signs off the criteria and register. DeployOpen prepares systems and evidence but does not issue assessment reports.
Ask any partner to state in writing which deliverables it produces and which decisions stay with your staff, and to confirm that the scope is fixed before work starts.
An independent auditor or assessor tests whether the classification process works and forms findings from the evidence. It does not decide the tiers. An assessor cannot design the controls it tests, so the people who wrote the criteria cannot also be the ones who certify them. The CIS Controls Assessment Specification for Controls v8.1: Safeguard 15.3 describes what is measured.
- Independent testing: Select a sample of providers, compare each assigned tier with its recorded characteristics and check that the criteria were applied as written.
- Process checks: Confirm the policy contains a classification process, since the specification gives a failing score when that process is missing.
- Coverage measurement: Calculate the share of providers with a classification, following the Coverage metric in the specification.
- Findings: Record findings and issue any assessment report in the auditor's own name. Only the auditor issues the report.
- Limits: An assessor cannot write your criteria or select tiers without losing the independence that gives its findings value.
Before fieldwork begins, confirm which reports, which sample and which evidence dates the engagement covers, and agree the scope in writing.
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.

