Safeguard 15.2 Service provider management policy

Safeguard 15.2 Service provider management policy: what it asks for and why it matters

When an auditor or a customer questionnaire asks for your service provider management policy, you either hand over a current, approved document or you do not. Safeguard 15.2 asks for exactly that document: a written policy that sets out how service providers are classified, inventoried, assessed, monitored and decommissioned. It is the governing document behind Safeguards 15.3 to 15.7, so each of those later safeguards should be traceable to a rule in this policy. Under the CIS Controls Assessment Specification, an enterprise with no service provider management policy receives a failing score for this safeguard, and that failure is immediate because there is no partial credit for a document that is still in draft. Safeguard 15.2 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises and not to IG1 organizations, which start Control 15 with the provider inventory in Safeguard 15.1.

The assessment specification measures this safeguard with a Completeness of Policy metric, which is the share of required components that the policy actually includes. In practice, that means the policy must address classification, inventory, assessment, monitoring and decommissioning, and each of those topics needs a stated rule, an owner and a trigger. Ask who approves the policy, which roles perform each step, and what happens when a provider falls into a higher risk class. The specification lists no prerequisite safeguards for measuring 15.2, so you can draft the policy first, but the policy will only be credible if the later safeguards can follow it. The policy must also be reviewed and updated annually, or sooner after significant enterprise changes such as a merger, a new cloud platform or a large outsourcing decision.

The policy itself is the easy part. Most enterprises can produce a document that lists the right headings within a few weeks, and the difficulty appears afterward, when the written rules drift away from practice. The classification scheme says that critical providers get annual reassessment, but the contract register shows that some were never assessed. The policy names an owner for each provider, but the inventory has blank contacts. Before you present the policy to an assessor or a customer, run a short reconciliation: pick several providers, trace each one from its classification through its contract, assessment, monitoring and exit record, and note every place where the policy and the evidence disagree. Those gaps, not the absence of headings, are what an assessor will find.

Which service providers and teams the 15.2 policy must cover

The policy is only as useful as its scope. The decisions below determine which providers, data and business relationships the policy governs, and they shape how much assessment and monitoring work follows. Safeguard 15.2 has no prerequisite safeguards in the assessment specification, so the policy can be drafted early, but its scope should be confirmed against the 15.1 inventory once that inventory exists.

Defining what counts as a service provider

Decide whether the policy covers only providers that handle enterprise data, or also providers that run processes or platforms the business depends on. SaaS applications, managed services, cloud platforms and consultants with system or data access usually belong in scope, while utilities and office suppliers with no access often do not. Write the test as a set of questions a business owner can answer, such as whether the provider stores, processes or can reach enterprise data or systems. Confirm the definition with legal and procurement before the policy is approved.

Mapping providers to sensitive data and critical platforms

List the data classes and critical platforms the policy must protect, then identify every provider that touches them. A provider holding customer records, payment data or production credentials carries more risk than one holding public marketing material. Use the data classification already in place for Control 3 where it exists. Note that providers touching the same platform may reach it through different paths, such as direct API access, shared administrator accounts or support tooling, and each path should be captured.

Assigning ownership across business units

Most provider relationships are created by business units rather than IT, so the policy must name who owns each relationship and who approves changes to it. Identify the business units that sign contracts, pay invoices and configure provider accounts, and state their duties under the policy. Without named owners, reassessment and decommissioning tend to stop when a contract renews automatically. Ask each unit to confirm which providers it manages before the policy assigns it responsibilities.

Setting the scope by implementation group

Safeguard 15.2 applies to IG2 and IG3 enterprises, not IG1. An IG2 enterprise should write a policy that addresses classification, inventory, assessment, monitoring and decommissioning. An IG3 enterprise, which faces more sophisticated and targeted threats, should expect a more detailed policy and more demanding evidence of how it is applied. Confirm the implementation group from the CIS Controls Implementation Group definitions before setting the depth of the policy.

Deciding how the inventory sets the boundary

Safeguard 15.1 requires a service provider inventory, and the policy scope should follow that inventory once it exists. Drafting the policy first is acceptable because 15.2 has no prerequisite safeguards, but the policy should state that the inventory is the authoritative list of providers in scope. Define how new providers enter the inventory, such as through procurement or a onboarding request, so the policy boundary does not drift from the actual provider population.

Identifying providers with hidden access

Some providers reach enterprise systems without appearing in a procurement record, including outsourced developers, contractors using their own tools, and software that connects through integrations or browser extensions. Review identity logs, cloud billing and integration registers to find these relationships. Where a provider can administer a platform or reach sensitive data, the policy should treat it as in scope regardless of contract type. Ask the security team to report the discovery method used so the scope can be defended in an assessment.

How an assessor tests the 15.2 policy

This table compares what an assessor does, what they ask for and where findings usually arise when testing Safeguard 15.2. Read it as a checklist for preparing the policy document, its review record and the staff interviews that follow.

Test element	What the assessor checks	What to prepare
Test approach	Reads the policy against the five required components: classification, inventory, assessment, monitoring and decommissioning of service providers	A single policy document that names each component and says how it is carried out
Completeness of Policy metric	Scores the share of required components the policy includes; a missing component lowers the score, and no policy at all fails the Safeguard	A component map showing which section covers each of the five components
Evidence requested	The current approved policy, prior versions where relevant, and proof that the policy is available to staff who run provider reviews	Policy file with version number, owner, effective date and a published location
Approval and review record	Confirms the policy was reviewed and updated at least annually, or after a significant enterprise change, and that an accountable owner approved it	Dated approval record, review log and a list of changes made at each review
Staff interviews	Asks owners of procurement, security and business units whether the process in the policy is what they actually follow	Named roles who run provider intake, classification and reviews, ready to explain their steps
Common findings	Policy exists but omits decommissioning or monitoring, has no review date, or describes a process no one follows	Gaps closed before the assessment, with the review record showing when each was fixed
Assessor output	A finding recorded in the assessor's report, which states whether the Safeguard is met or not met	Confirm the assessor's report format and scope with the assessor before fieldwork begins
Ownership	The organization owns the policy and its content; the assessor tests it and does not write or certify it	Internal sign-off on the policy, with any outside help documented as preparation support only

Writing and adopting the 15.2 policy in six steps

This sequence turns Safeguard 15.2 from an idea into an approved, published policy with named owners, a stage-by-stage lifecycle and a review cycle that an assessor can test. Each step ends with a document or record you can show.

Confirm scope and policy owners
Decide which service providers the policy covers, which business units and systems are in scope, and who owns the policy. Typically a security or risk lead drafts it, with procurement, legal and IT operations as contributors. Record the scope in a short scope statement that names the included provider types, such as those holding sensitive data or running critical platforms, and the exclusions you have justified. The step is complete when the scope statement and a named policy owner are agreed in writing by the sponsoring executive.
Define the provider lifecycle stages
Set out the stages every provider passes through: onboarding and inventory, classification, contracting, assessment, ongoing monitoring, and decommissioning. These stages map directly to Safeguards 15.1 and 15.3 to 15.7, so keep the names consistent with those safeguards. Write a one-line entry for each stage describing its trigger and its exit condition. The output is a lifecycle diagram or table that the policy will reference, and it is complete when every sibling safeguard has a stage it belongs to.
Map each stage to a responsible role
Build a RACI table that assigns each lifecycle stage to a responsible, accountable, consulted and informed role. Procurement may own onboarding, the security team may own assessment, and the business owner may own the decision to continue or exit a provider. Check that every stage has exactly one accountable role and that the roles exist in your organization chart. The output is an approved RACI table, and the step closes when each role holder has confirmed their responsibilities in writing.
Draft the policy with all five components
Write the policy so that classification, inventory, assessment, monitoring and decommissioning each appear as a named section with its own requirements, owner and record. Reference the lifecycle stages and the RACI table rather than repeating them. Add a short statement of purpose, the scope, and the exceptions process. Because the assessment specification scores Safeguard 15.2 on how completely the policy covers its components, include a checklist mapping each component to its section. The output is a draft policy document with a completed component checklist.
Obtain executive approval and publish
Send the draft to the executive who owns third-party risk for review and formal approval. Record the approval with the approver's name, the date, the version number and any conditions. Then publish the approved version in the place staff already use for policies, with access rights that let the intended readers find it and limit edits to the policy owner. The step is complete when the approval record is filed and the published link is confirmed to work for the people who must follow the policy.
Set the annual review and trigger-based updates
CIS asks that the Safeguard 15.2 policy be reviewed and updated annually, or sooner when significant enterprise changes could affect it. Create a review calendar entry for the annual review, and write down the change events that trigger an early review, such as a merger, a new regulated service line, or a major provider incident. Assign the reviewer and record the outcome of each review, even when no change is made. The step is complete when the calendar entry, the trigger list and the review log template exist and the policy owner has accepted them.

Which policy evidence passes and how to keep it current

An assessor testing Safeguard 15.2 looks for a policy that exists, is approved, covers the required components and stays current. The artifacts below connect to one another, so each one should point to the others and to the procedures they govern.

Approved policy with version history

The policy document itself is the primary evidence that the enterprise has a service provider management policy. Keep it in a controlled repository where each revision records what changed, when and by whom, so an assessor can see the text that was in force on any given date. Check that the policy names an owner, states its scope (which providers are covered) and addresses classification, inventory, assessment, monitoring and decommissioning. A policy that exists only as an unversioned file on a shared drive is hard to defend.

Approval record for the policy

An approval record shows that someone with authority accepted the policy, which is different from its author simply publishing it. Record the approver's name and role, the date, the version approved and any conditions attached. Confirm with your governance team which role must sign off, since many enterprises place this with the CISO or a risk committee. Without a dated approval, an assessor may treat the document as a draft.

Component checklist for completeness

The assessment specification scores Safeguard 15.2 with a Completeness of Policy metric, which measures the share of required components the policy includes. Maintain a checklist that maps each component (classification, inventory, assessment, monitoring, decommissioning, roles and exceptions) to the section of the policy that addresses it. Re-run the checklist after every revision so that a removed section is caught before an assessor finds it.

Review log for annual and event-driven reviews

CIS asks for the policy to be reviewed and updated annually, or sooner when significant enterprise changes could affect the safeguard. The review log records each review date, the reviewer, whether the policy changed and the reason for any change. Keep entries even when a review finds no change, because an empty review is still evidence that the review happened. Set a standing review date in the calendar and assign an owner who is accountable for it.

Distribution and acknowledgment records

A policy that people responsible for vendor decisions never read does not operate. Record who received each version, when it was published and which procurement, IT, security and business owners acknowledged it. Tie acknowledgments to role-based access so that only the people who manage providers can see and sign the policy, and retain acknowledgments for each version. Confirm how your platform tracks read or acknowledge status before relying on it as evidence.

Cross-references to 15.1 and 15.3 to 15.7

The policy governs the procedures behind Safeguards 15.3 to 15.7, so each section should link to the operating record it controls: the provider inventory under 15.1, classification criteria under 15.3, contract clauses under 15.4, assessment reports under 15.5, monitoring logs under 15.6 and disposal records under 15.7. Test the links during each review. A policy that promises a procedure no one can find is weaker evidence than a shorter policy that points to working records.

What the 15.2 policy costs in money and effort

This table compares the main cost components of writing, approving and maintaining a Safeguard 15.2 policy, showing whether each is one-time or recurring and what changes its size. No figures are given because none were supplied, so use the drivers and quote requests to build your own estimate. The main takeaway is that most of the recurring cost comes from annual review and approval layers, not from the first draft.

Cost component	One-time or recurring	What drives it up	How to keep it down
Drafting effort	One-time, then revised when scope changes	Number of provider types, number of business units with their own vendor processes, and how many existing procurement or security documents must be reconciled	Start from an existing vendor or third-party risk policy, limit the first version to the components 15.2 names, and assign one drafter who owns the text
Legal or contract review	One-time, with recurring checks when contract templates change	Regulated provider categories that need specific clauses, multiple jurisdictions, and separate review of exit and data disposal terms	Ask counsel to review the policy once against a standard contract template, and agree which clauses are reviewed each cycle
Executive approval time	One-time, then repeated at each annual review	Number of approval layers, the need for board or risk committee sign-off, and disputes between business units over ownership	Name the approving executive in the policy, define which changes need full approval, and bring minor updates to a single sign-off
Document tooling or licenses	Recurring if commercial, one-time setup if self-hosted	Number of users who edit or approve, need for version history and audit trails, and integration with existing governance tools	Use a self-hosted wiki or document platform with version history and role-based permissions, and confirm license terms with each vendor
Annual review effort	Recurring, at least once a year	Frequency of significant enterprise changes such as mergers, new cloud regions or new regulated services, and how many policy components must be re-checked	Keep a dated change log, tie reviews to the annual cycle plus change triggers, and reuse the previous year's completeness checklist
External review or readiness support	Usually one-time, with recurring retainers if chosen	Scope of the review, whether the policy must map to ISO 27001, SOC 2 or PCI DSS controls, and how many evidence samples the assessor expects	Ask for a fixed-scope review of the policy only, and request the cost of each additional framework mapping separately in the quote

Open-source tools that hold the 15.2 policy and its evidence

Three open-source tools cover the jobs behind Safeguard 15.2: keeping a dated history of the policy, controlling who can edit it, and mapping it to the other frameworks your organization answers to. They do not write the policy or decide what it requires. Your organization owns those decisions, and an independent assessor judges the evidence.

XWiki page version history

XWiki keeps every change to a page under version control, recording what changed, when and by whom. Reviewers can compare any two versions and roll back to an earlier one. For Safeguard 15.2, this gives an assessor a dated history showing when the provider management policy was reviewed, what each annual review changed and who approved each revision. Check who is allowed to publish, and confirm how the wiki is backed up, since the history is only as durable as the storage behind it. XWiki is licensed under LGPL-2.1-or-later, so confirm with your legal team that this license fits your deployment and approval process.

BookStack role-based access

BookStack assigns abilities through the roles given to each user, and permissions can be overridden per role at the shelf, book, chapter or page level. For the 15.2 policy, this lets the security team edit the policy book while business owners and procurement keep read-only access. Restrict the page where classification tiers are set in the same way. Test the setup before relying on it: sign in as a read-only user and confirm they cannot edit or delete content. BookStack is MIT licensed, so confirm with your approval process that hosting it is permitted and that administrator accounts are tightly controlled.

CISO Assistant framework mapping

CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks, including ISO 27001, SOC 2, PCI DSS, NIS2 and DORA, and runs assessments against them with automatic mapping between frameworks. Use it to record the 15.2 policy once and track how it answers related requirements, such as ISO/IEC 27001:2022 Annex A control 5.19 and PCI DSS v4.0 requirement 12.8. Confirm that the mappings match your own reading before an auditor sees them. The AGPL-3.0-only license carries network-use obligations, so ask counsel whether your deployment and any modifications trigger them.

Confirm licenses before adoption

The three tools carry three different licenses: AGPL-3.0-only for CISO Assistant, LGPL-2.1-or-later for XWiki and MIT for BookStack. Each sets different obligations when you modify, distribute or host the software. Ask your legal or procurement team to review the license text against your deployment model, and record the decision in the policy's approval trail so an assessor can see it was made. Do not assume that an open-source license removes the need for vendor review, because your own policy may require one for any tool that holds provider data.

Who writes, approves and audits the policy

Your organization owns Safeguard 15.2. The policy is an internal governance document, so its content, its approval and its enforcement sit with your leadership and the people who buy and run third-party services. Someone in security or risk usually holds the pen, but the policy only works if legal, procurement and the business owners of each provider accept what it asks of them.

Policy owner: A named role, often in security governance or third-party risk, who maintains the document, runs the annual review and answers auditor questions about it.
Legal and procurement reviewers: They check that classification tiers, contract clauses and offboarding steps match the contract templates and purchasing workflow you actually use.
Executive approver: A senior owner, such as the CISO or CIO, who formally approves the policy and records the approval date and version.
Business owners: The managers who sign up providers and must follow the assessment, monitoring and exit steps for them.

Confirm that each role has a named person, a deputy and a documented approval record before any outside party starts drafting, because the auditor will ask who approved each version.

Where the 15.2 policy usually falls short

What happens when a 15.2 policy skips one of the five required components?

The policy loses completeness, and the gap usually shows up in assessment. Safeguard 15.2 asks the policy to address classification, inventory, assessment, monitoring and decommissioning of service providers. The CIS Controls Assessment Specification scores the policy with a Completeness of Policy metric, which measures the share of components the policy includes, so a missing topic lowers the score. Missing topics often correspond to procedures nobody runs, such as offboarding. To close the gap, map each of the five topics to a named section of the policy, state the procedure in a few sentences, and name the role that performs it. Evidence is a cross-reference table linking each topic to its policy clause, plus the approved version that contains it. Confirm with your assessor how they score partial coverage before you finalize the document.

Who should own and approve the service provider management policy?

A single accountable owner and a dated approval from an executive should be on record. The owner is usually the CISO, the head of third-party risk or the equivalent role, and the approver is someone with authority to accept the risk the policy manages. A committee can advise, but without one named owner nobody answers for enforcement, and assessors ask for evidence of who approved the document and when. To close the gap, name the owner in the document header, record the approval in your governance system or as a signed ticket, and keep the approved version separate from drafts. Evidence includes the approval record, the owner field in the document, and the version history. If your team uses XWiki, its version control keeps a record of each change, when it happened and who made it, which supports this evidence.

Why does an overdue review date on a service provider policy matter?

An overdue review shows that the safeguard is not operating as written. Safeguard 15.2 asks for the policy to be reviewed and updated annually, or sooner when significant enterprise changes could affect it, such as an acquisition, a move to a new cloud platform, a new regulation or a large change in provider count. A document with a review date in the past tells an assessor that the policy may no longer match how the enterprise works. To close the gap, write the next review date into the document, assign the owner a recurring reminder, and define the change triggers in the policy itself. Keep a review record even when the review finds no changes. Evidence includes dated review records, meeting notes or sign-offs, and change history that shows what was updated and why.

Why do business owners ignore a service provider policy written only for procurement?

Business owners ignore it when the policy reads as a purchasing rule that ends at contract signature. Such a policy covers onboarding but says little about the ongoing duties that follow, such as reassessment, monitoring and exit. Business owners who manage the relationship day to day then run their own tools, renew contracts and change scope without telling security. To close the gap, review the policy with business owners before approval, assign a named relationship owner to each provider as a written duty, and add reassessment, monitoring and offboarding to that role. Training helps, but the duties must appear in the policy and in each provider record. Evidence includes signed acknowledgments from relationship owners, provider records showing reassessment dates they set, and completed offboarding tickets for providers that have exited.

How do I check that the 15.2 policy matches our provider inventory?

Compare the policy's terms and required actions against the fields in your 15.1 inventory and the procedures used for 15.3 to 15.7. Mismatches are common. A policy may define three classification tiers while the inventory uses five labels, or it may require annual assessment while the tracker has no due date field. Safeguard 15.1 is the starting point because it records each provider and its enterprise contact, and the policy should use the same identifiers and classification values. To close the gap, align the tier names and inventory fields, record the policy tier on every provider record, and trace each procedure back to a policy clause. Evidence is a traceability matrix that links policy clauses to inventory fields and procedure documents, plus a sample of provider records that shows the policy applied in practice.

Does Safeguard 15.2 apply to organizations in Implementation Group 1?

No. CIS assigns Safeguard 15.2 to Implementation Group 2, so it applies to IG2 and IG3 enterprises and is not part of the IG1 set. IG1 organizations still need the 15.1 provider inventory, which CIS treats as the starting point for the rest of Control 15. If your enterprise is IG2 or IG3, the policy is required, and the scope decision should be documented. If you are IG1 and work with providers that hold sensitive data, a short written policy can still help your team, but it does not carry the 15.2 requirement. Confirm your Implementation Group against the CIS Implementation Groups guidance and the enterprise profile your assessor will use. Evidence is a scope statement that records the Implementation Group decision and the reasons behind it.

How Safeguard 15.2 maps to other frameworks

The CIS Controls Navigator maps Safeguard 15.2 to NIST CSF 2.0 subcategories DE.CM-06 and GV.SC-01, to NIST SP 800-53 Rev. 5 controls AC-21, CP-8(3), PM-30, SA-9, SA-9(2) and SR-1, to ISO/IEC 27001:2022 Annex A controls 5.1, 5.10, 5.19, 5.20 and 5.23, to AICPA SOC 2 criteria CC3.2 and CC3.4, and to PCI DSS v4.0 requirement 12.8. Because these mappings all point at the same underlying question, one written service provider management policy can often serve several frameworks at once. The policy needs to define how providers are classified, inventoried, assessed, monitored and decommissioned, and each framework then looks for different proof that those rules exist, are approved and are followed. The practical work is to map your policy's sections to each framework's expectations and record where each one is satisfied. For example, the supplier-related Annex A controls in ISO/IEC 27001:2022 and the SOC 2 criteria on communication and risk management will each ask for evidence of approval, communication and review, while PCI DSS v4.0 requirement 12.8 focuses on the list of third-party service providers and their responsibility matrix. Your policy should name the owner, the approval body and the review cycle so the same document answers each auditor's question without a separate rewrite. Before relying on any mapping, confirm it against the current CIS Controls Navigator for v8.1, since mappings can be revised between releases. Then ask your own assessor, whether an accredited certification body, a CPA firm or a QSA, how they expect the policy to be evidenced in your scope. Mappings show where a control is related, but they do not tell you that an assessor will accept a single document for every framework, so treat that acceptance as something to verify, not assume.

Common questions about the 15.2 policy and outside help

How much effort does a service provider management policy take to write?

Writing the Safeguard 15.2 policy is usually a document-drafting effort rather than a large technical project, but the effort depends on how many provider types the organization has and how many teams already hold provider records. The main work is agreeing the classification categories, the assessment and monitoring triggers, and the decommissioning steps with the business owners who will follow them. The policy itself has no CIS-published duration or cost, so ask any partner to break the estimate into drafting, review and approval steps in a written scope. Once approved, the policy also needs an annual review, which is a recurring effort rather than a one-time cost.

Who should own the service provider management policy?

The policy should be owned by a named executive or governance owner, with day-to-day drafting usually led by security or third-party risk staff and approval by legal, procurement and the business units that manage providers. The CIS Controls Assessment Specification checks whether the policy exists and how complete it is, so the owner must be able to keep it current. Ownership matters more than authorship because the annual review and significant-change updates require someone with authority to make them.

Can we write the 15.2 policy in-house using the CIS assessment specification?

Yes, an organization can write the policy in-house. The CIS Controls Assessment Specification defines the measure for Safeguard 15.2 as the completeness of the policy, meaning the share of required components it includes, so the in-house team can use that measure as a checklist. The harder part is making the policy match real practice, which requires input from procurement, legal and system owners. Organizations with limited governance staff often bring in outside help to draft and review the document, while keeping ownership and approval internal.

How long does the 15.2 policy work take?

The duration depends on scope: the number of business units, provider types, existing policies and approval bodies all change the timeline. No fixed duration is supplied for this safeguard, so ask any partner or internal team to confirm a timeline in a written plan before work starts. The plan should show when business owners review drafts, when the policy is approved and when the first annual review is scheduled.

What does the policy need from business owners?

The policy needs business owners to confirm which providers they use, how those providers handle data, which services are critical, and who must approve exceptions. Without this input, the classification and monitoring rules will describe an idealized process rather than the real one. Business owners should also agree to notify the security team of significant changes, such as a new provider type or a major acquisition, since those changes trigger an earlier review under the safeguard.

Does the 15.2 policy alone satisfy safeguards 15.3 to 15.7?

No. The policy governs how providers are classified, inventoried, assessed, monitored and decommissioned, but Safeguards 15.3 to 15.7 each require their own records. Those records include the provider classifications, the contract security requirements, the assessment reports or questionnaires, the monitoring evidence and the decommissioning records. A policy that describes these steps without the matching records will be weak evidence for the later safeguards, so plan the records alongside the policy.

What should we ask a partner for in a fixed-scope quote?

A fixed-scope quote should list the deliverables, the business units and provider types included, the number of review rounds, the approval steps, the handover format and the assumptions the price depends on. Ask for the scope in writing before work starts, along with the timeline and the client tasks that could delay it. Confirm whether the partner prepares the document only or also prepares the supporting records for 15.3 to 15.7. DeployOpen works from a written scope and does not publish a price list, so the quote follows from the agreed scope. Remember that only an independent auditor or assessor can issue any report or attestation on the controls.

How DeployOpen prepares the 15.2 policy and its evidence

DeployOpen helps your team prepare the service provider management policy that Safeguard 15.2 requires, then builds the records and systems that show the policy is followed. Your organization owns the policy and its decisions, and an independent auditor or assessor, not DeployOpen, reviews the evidence and issues any report.

How we scope

Agree in writing which service provider lifecycle stages the policy must cover: classification, inventory, assessment, monitoring and decommissioning.
Confirm which business units, platforms and provider types fall within the policy, and who owns each part of it.
Define the deliverables, documents and tooling in a fixed-scope statement agreed before work starts.

How we build

Draft the policy with your governance owners so it names roles, review triggers and the components assessors will check for completeness.
Set up the open-source tools that hold the provider inventory, policy version history and review records in your own infrastructure.
Test the policy against a sample of your providers to confirm the documented process can actually be followed.

How we hand over

Deliver the approved policy, its change log and a mapping to the Safeguard 15.2 assessment measure for your records.
Document the annual review schedule and the significant change events that should trigger an earlier update.
Walk your team through the evidence set so they can show an assessor how the policy is applied in practice.

How we support

Offer ongoing support as a retainer for policy reviews, tool upgrades and changes to your provider landscape.
Update the policy and its records when significant enterprise changes could affect Safeguard 15.2, as your scope agreement allows.
Confirm with your independent assessor which evidence formats and review cycles they will accept before the first review.