Safeguard 15.7: Securely Decommission Service Providers

Safeguard 15.7 requires you to securely decommission service providers so your data, credentials, and access paths are removed or returned at contract end (or earlier), with proof. Operationally, you need an offboarding runbook tied to procurement and IAM that triggers data disposition, access revocation, asset return, and formal third-party attestations. ¹

Key takeaways:

• Build a standard third-party decommission workflow that starts at termination notice and ends with documented data destruction/return and access removal. ¹
• Treat “secure decommission” as three closures: identity/access, data, and integrations/keys, with evidence for each. ¹
• Map safeguard 15.7 to a documented control operation with recurring evidence capture so audits do not depend on ad hoc emails. ¹

“Safeguard 15.7: Securely Decommission Service Providers” is a practical third-party risk requirement: you cannot consider a third party “done” just because the contract ended. If the provider still has your data, still has an active admin account, or still has an API token wired into production, your risk remains live.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing safeguard 15.7 is to standardize offboarding triggers and closeout evidence. You want a repeatable playbook that works for SaaS, hosted infrastructure, consultants, and managed service providers, and that scales across many exits per year. The goal is simple: prove you (1) revoked access, (2) removed integrations and secrets, (3) directed data return or secure destruction, and (4) confirmed completion in writing.

CIS does not require a single tool. It expects a verifiable process and artifacts that show secure decommissioning occurred when a service provider relationship ends. ¹

Regulatory text

Framework requirement (excerpt): “CIS Controls v8 safeguard 15.7 implementation expectation (Securely Decommission Service Providers).” ¹

What the operator must do: implement and run a secure third-party offboarding process that closes out the relationship safely. That means you define the steps, assign owners, and retain evidence that the service provider no longer has access to your systems or data and that any retained information is handled according to your instructions and contractual terms. ¹

Plain-English interpretation (what “securely decommission” means)

Secure decommissioning a service provider means you can answer “no” to three questions, with proof:

1. Can they still log in or connect? Accounts disabled, SSO blocked, MFA devices removed, VPN access revoked, and privileged roles removed.

2. Do they still have your data? Data returned to you, deleted, or destroyed per an agreed method; backups and replicas addressed; retention exceptions documented.

3. Do your systems still trust them? API keys rotated, tokens revoked, certificates replaced, inbound allowlists removed, and integrations disabled.

If you can’t prove those closures happened, auditors will treat the third party as still active risk, even if procurement lists them as “terminated.”

Who it applies to (entity + operational context)

Applies to: any organization that uses third parties to store, process, transmit, administer, or access company data or systems, including SaaS providers, cloud platforms, MSPs/MSSPs, payroll/HR systems, marketing platforms, consultants, and contractors. ¹

Operational contexts where this matters most:

• SaaS with customer/employee data (e.g., HRIS, CRM): data disposition and admin access are the usual gaps.
• MSPs and IT administrators: privileged access, remote tooling, and shared credentials are the usual gaps.
• Cloud and hosting providers: snapshots, object storage, IAM roles, and key management are the usual gaps.
• Professional services and contractors: local data copies, shared folders, and unmanaged endpoints are the usual gaps.

What you actually need to do (step-by-step)

Step 1: Define “termination events” and wire triggers

Create a short list of events that must trigger decommission:

• Contract end, non-renewal, or termination for cause
• Scope reduction that removes access to sensitive environments
• Third-party breach, insolvency, or acquisition (if you choose to exit)
• Migration off a platform (replacement go-live)

Operationalize the trigger: procurement/vendor management should open an offboarding ticket automatically when a termination event is recorded. If you rely on humans remembering, you will miss exits.

Step 2: Classify the relationship to select the right offboarding depth

Use a simple tiering decision so effort matches risk:

• Tier A (high impact): third party has privileged access or stores regulated/sensitive data.
• Tier B (moderate impact): processes internal data or integrates with core systems.
• Tier C (low impact): no sensitive data, no integrations, no access.

Your decommission checklist should scale by tier, but every tier still requires evidence that access is removed.

Step 3: Execute the “Access Closure” checklist (IAM-first)

Minimum actions you should standardize:

• Disable/delete named accounts at the third party (where you manage them).
• Remove the third party from SSO, groups, and SCIM provisioning.
• Revoke VPN, bastion, or remote support tool access.
• Remove privileged roles in your systems (admin consoles, cloud IAM, ticketing).
• Rotate any shared secrets the third party could know (service accounts, break-glass credentials).

Evidence to collect: screenshots or exports from IAM/SSO showing user/group removal; ticket system record with approver and completion timestamps; list of revoked roles.

Step 4: Execute the “Integration & Secret Closure” checklist (trust removal)

Third parties often persist through integrations even after accounts are removed. Close these out explicitly:

• Revoke API tokens; rotate API keys; delete OAuth apps.
• Remove webhooks and inbound firewall allowlists tied to the third party.
• Replace certificates or signing keys used for SFTP/EDI and API auth.
• Disable data pipelines, iPaaS connectors, and sync jobs (including “paused” jobs that can be re-enabled).

Evidence to collect: key rotation records, secrets manager history, integration disablement confirmation, and change-management approvals.

Step 5: Execute the “Data Disposition” checklist (return, delete, destroy)

For each data domain the third party touched, decide the required disposition:

• Return: export data in a usable format; validate completeness; store in approved repository.
• Deletion: require deletion of primary data and confirm treatment of replicas/caches.
• Destruction: if physical media is involved, require secure destruction documentation.

Close common loopholes:

• Backups: require a statement on backup retention and deletion feasibility.
• Legal hold: document exceptions and compensating controls if deletion cannot occur.
• Sub-processors: ensure downstream providers are included if they held your data.

Evidence to collect: third-party attestation of deletion/destruction/return; export logs; inventory of data locations; documented exception approvals.

Step 6: Formal closeout and residual risk sign-off

End with a “closeout packet” that includes:

• Completed checklist (access, integrations, data)
• Third-party written confirmation (email is acceptable if it is explicit and attributable)
• Internal approver sign-off (system owner + security/GRC)

Store the packet where audits can find it quickly.

Step 7: Make it auditable with recurring evidence capture

CIS implementation expectations often fail in audits due to missing proof, not missing intent. Map safeguard 15.7 to a documented control operation and recurring evidence capture, with a defined frequency for sampling or review based on third-party change volume. ¹

Practical tooling note: Many teams run this as a standard workflow in their GRC system, ticketing, or vendor management tool. Daydream is a good fit when you need the requirement mapped to a control, embedded into a workflow, and backed by consistent evidence collection across many third parties without rebuilding the process each audit cycle. ¹

Required evidence and artifacts to retain (audit-ready list)

Retain artifacts that prove closure across identity, trust, and data:

Governance

• Third-party offboarding policy / standard
• Offboarding checklist templates by tier
• RACI (who approves what)

Per third party (closeout packet)

• Termination trigger record (contract end notice, termination email, procurement record)
• Access revocation evidence (SSO/IAM exports, admin console screenshots, group removal logs)
• Integration shutdown evidence (revoked tokens, deleted OAuth apps, removed webhooks, rotated keys)
• Data disposition evidence (return/export confirmation, deletion/destruction attestation, exception approvals)
• Sub-processor disposition confirmation (where applicable)
• Final sign-off (system owner + security/GRC)

Systems evidence

• Ticket records with timestamps, assignees, approvals, and completion notes
• Change-management entries for key rotations and integration changes

Common exam/audit questions and hangups

Auditors and assessors typically drill into a few predictable gaps:

• “Show me three terminated third parties and prove they no longer have access.” If you can’t produce a closeout packet quickly, you will burn time reconstructing events.
• “How do you handle API keys and service accounts?” Teams often remove user accounts but forget non-human access.
• “What about backups and logs?” Expect scrutiny on whether “deleted” includes replicas, backups, and exported reports.
• “Who signs off that data was destroyed?” “The vendor said so” is weak unless you have an attributable attestation and contractual basis.
• “Do you decommission sub-processors?” If your third party used downstream providers, you need clarity on data flow and disposition.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Avoid it by doing this
Offboarding starts after the last invoice	Access and integrations can remain active long after “termination”	Tie offboarding trigger to termination notice, not finance closeout
Only disabling SSO accounts	API keys, OAuth grants, and allowlists remain	Maintain a standard “integration & secrets” checklist
No data inventory for the third party	You cannot prove deletion/return completeness	Maintain a simple data map per third party during onboarding
Relying on informal emails	Evidence becomes fragmented and non-repeatable	Create a closeout packet and store it in a single system of record
Treating all third parties the same	Low-risk exits create noise; high-risk exits get rushed	Use tiered offboarding with clear minimums

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. From a risk standpoint, secure decommissioning failures commonly manifest as: former providers retaining sensitive data, orphaned admin accounts, persistent API tokens, and forgotten remote access tooling. These are preventable control failures that expand your attack surface and complicate incident response.

Practical 30/60/90-day execution plan

Use phases rather than dated promises. The output you want is a working offboarding workflow plus evidence you can show immediately.

First 30 days (Immediate)

• Publish an owner-assigned offboarding procedure for third parties aligned to safeguard 15.7. ¹
• Build a tiered offboarding checklist with three mandatory sections: Access, Integrations/Secrets, Data Disposition.
• Choose a system of record for closeout packets (ticketing, GRC workflow, or vendor management).
• Identify your current “top risk” third parties (privileged access and sensitive data) and validate they have an exit path.

Next 60 days (Near-term)

• Integrate procurement/third-party management with a decommission ticket trigger.
• Add contractual language or templates for termination assistance, data return/deletion, and attestations (if you control templates).
• Run a tabletop offboarding on one SaaS provider and one MSP-like provider; refine the checklist based on what breaks.
• Define minimum evidence requirements and train system owners on what to attach.

Next 90 days (Operationalize + prove)

• Run the process on real terminations and produce complete closeout packets.
• Perform a sampling review of recent third-party exits to confirm evidence quality.
• Report metrics qualitatively to leadership (e.g., “exits with complete closeout packet” vs. “missing attestation”) without inventing benchmarks.
• If scaling is a problem, implement tooling support (workflow + evidence capture). Daydream can reduce manual chasing by mapping safeguard 15.7 to control operation steps and packaging evidence consistently across providers. ¹

Frequently Asked Questions

Does safeguard 15.7 apply to SaaS providers where we only have user accounts?

Yes. You still need to prove account removal, admin role removal, and that data is returned or deleted per your instructions. For SaaS, integrations (OAuth apps, API tokens) are often the hidden tail risk. ¹

What if a provider says they can’t delete data immediately because of backups?

Document the retention constraint, obtain an attributable statement of their backup retention handling, and record your approval of the exception. Then ensure access is removed immediately so retained backups are not reachable by the provider’s former operators.

Is an email from the third party enough as an attestation?

It can be, if it is specific (what data, which systems, what action, when) and attributable (named sender/role/company). For higher-risk providers, require a formal letter or support ticket closure note attached to the closeout packet.

How do we handle shared service accounts used by a third party?

Replace them. Rotate credentials, migrate to named accounts or a managed integration identity, and then disable the shared account. Keep the rotation evidence and the disablement proof in the closeout packet.

We ended the contract but still need read-only access during transition. Can we keep accounts active?

Yes, but treat it as an extension with a defined end date, reduced privileges, and monitoring. Record the exception and require a final decommission step once transition access ends.

What evidence do auditors usually accept for “integration removed”?

Change records plus system screenshots/exports showing token revocation, OAuth app deletion, webhook removal, and key rotation. Pair that with a ticket that shows who approved and who executed the change.

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8