What Safeguard 15.7 asks when a service provider relationship ends
Safeguard 15.7 asks the enterprise to decommission each service provider securely when the relationship ends, so that the provider no longer holds access to enterprise systems or data and no enterprise data remains in its hands without a deliberate decision. CIS gives three example considerations for that outcome: deactivating user and service accounts, terminating data flows, and securely disposing of enterprise data held within the provider's systems. Each one is a separate thing to verify. A contract can end on paper while an integration token still reads from your systems, a shared service account still has administrative rights, or a nightly export still lands in a storage bucket nobody remembers. Those are the gaps an exit is supposed to close.
The risk is that access and copies outlive the contract. Credentials issued to a provider's staff, API keys, SCIM or directory connections and scheduled data pipelines tend to persist because nobody owns the list of them at exit time. Data copies persist in backups, logs, analytics stores and support tickets. The safeguard is measured against a practical question: can you show, for each provider you decommission, that every account and flow was closed and every copy was disposed of or returned under a documented process?
Safeguard 15.7 sits in Implementation Group 3 only, one of the 23 Safeguards reserved for IG3, so organizations in IG1 or IG2 are not assessed against it under the CIS framework. It also depends on two earlier decisions. Safeguard 15.1 requires an inventory of service providers, without which you cannot know which accounts and flows to close, and Safeguard 15.2 requires a policy, without which the assessment specification scores the Safeguard as failing when the policy gives no guidance on secure decommissioning. Confirm both are in place before you test 15.7. The practical difficulty is ownership. Exits are often managed by procurement or the business unit that bought the service, and the evidence of deletion usually comes from the provider. Ask the provider for written certification of disposal, but also check the access side yourself, since your own identity records are the only proof that accounts were actually deactivated.
Which providers, accounts and data fall under 15.7
Safeguard 15.7 applies to every provider you classified as holding sensitive data or running a critical process under 15.3. The work of ending a relationship grows with each component the provider touches, so the team should settle these scope questions before the exit starts.
Providers holding sensitive data or critical processes
Start from your 15.1 inventory and the classes you assigned under 15.3. Decide which providers fall inside 15.7 and which need only a lighter exit. A provider that stores regulated records or runs a process your business depends on needs a documented termination plan, a named owner and a deadline. Confirm that the 15.2 policy gives a decommissioning procedure for each class, because the assessment specification fails the Safeguard when the policy has no such guidance.
SaaS tenants and their identities
A SaaS tenant holds its own users, administrator accounts, group memberships and API keys, separate from your identity provider. Inventory each tenant and list every account that can sign in, including former staff, shared accounts and vendor support access. Decide whether accounts are removed through federated deprovisioning or manually, and who confirms that the last login is closed. Export or archive any tenant-side audit trail you must keep before the tenant is closed.
Managed services and dedicated service accounts
Managed services often run under service accounts, scheduled jobs or integration users that no one on your team logs into. For each one, record the credential type, where it is stored, and which of your systems it calls. Plan to disable the account, rotate or revoke any secret it used, and remove the connection from downstream systems in a set order. An illustrative example: a reporting job that pulls data nightly keeps working after the vendor is gone unless its key is revoked.
Hosted platforms and API keys
Hosted platforms expose API keys, webhooks, OAuth grants and signing keys that outlive the contract. List each integration that authenticates to the provider, and map it to the internal application that owns it. Decide which keys are revoked on the termination date and which must be replaced first so that production traffic does not break. Confirm with the provider in writing how it disables these credentials on its side.
Data flows, backups and provider-held copies
Map every path that moves enterprise data to and from the provider, including sync jobs, exports and file transfers. Then decide what happens to backups the provider keeps, cached copies, test datasets and replicas in other regions. Each copy needs a disposal method, a date and a confirmation. Ask the provider to state in writing which of these copies it holds, how long it keeps them after termination, and whether deletion covers backups.
Logs, analytics exports and subprocessors
Logs, analytics exports and telemetry often leave the provider in bulk and sit in your own storage or a third party's. Decide which of these you must keep for audit or retention, and which must be deleted with the rest. Identify subprocessors the provider uses to store or process your data, and confirm that their copies are included in the disposal scope. Ask for a written list of subprocessors at the time of termination.
How an assessor tests 15.7 at the decommissioning step
This table compares what an assessor checks at each step of testing Safeguard 15.7, from prerequisites through the sampled terminations, and what evidence proves each step. Read it as a checklist: if the policy has no decommissioning guidance, the score fails before any sample is pulled, so the policy clause is the first thing to prepare.
| Assessment step | What the assessor does | Evidence requested or common finding |
|---|---|---|
| Prerequisites (15.1 and 15.2) | Confirms a service provider inventory and a governing policy exist before testing 15.7 | Inventory entries with an enterprise contact; policy document; missing inventory blocks the test |
| Policy guidance | Checks that the service provider management policy contains guidance for secure decommissioning | Policy clause covering account removal, data flow shutdown and disposal; no such clause usually means a failing score |
| Compliance metric | Calculates the share of service providers that were properly terminated in the sample | Population list of terminated providers with termination dates and owners |
| Sample of terminated providers | Selects terminated providers and traces each one through the decommissioning steps | Ticket or change record per provider showing the steps completed and who approved them |
| Account removal | Confirms user and service accounts at the provider were deactivated | Deactivation logs, identity provider deprovisioning records, and a check for service accounts still active |
| Data flow shutdown | Confirms integrations, API keys, data feeds and scheduled transfers were stopped | Configuration change records, revoked credentials, and firewall or connector removal records |
| Disposal of enterprise data | Confirms enterprise data held by the provider was returned or securely deleted, with proof | Disposal certificate or written provider confirmation; common finding is undocumented disposal |
| Common finding: orphaned accounts | Looks for service accounts or API tokens that outlived the contract | Accounts still active months after termination; no owner in the inventory |
| Common finding: no closure record | Looks for a documented close-out for each terminated provider | Termination with no ticket, no sign-off or no disposal evidence |
How to decommission a provider in six steps
This sequence ends a provider relationship in a fixed order so that accounts, data flows and enterprise data are closed out and each closure leaves a record an assessor can test against Safeguard 15.7.
Trigger the exit and assign an owner
Record the reason for ending the relationship, such as contract expiry, a change in provider risk classification or a failed assessment, and name the accountable business owner and the IT contact from the service provider inventory record. The owner should confirm the exit date and the provider's enterprise contact in writing. The artifact is a dated decommission ticket linked to the inventory entry, which shows the trigger was recorded and someone was accountable from the start.
Inventory the provider's accounts and integrations
Compile every user account, administrator account, service account, API key, SSO connection, SCIM or directory sync and shared mailbox that the provider holds in your environment, and list the systems and data stores it can reach. Include accounts the provider created for its own staff and accounts used by automation. The artifact is a provider access register, which becomes the checklist for the next three steps and lets the assessor compare what existed against what was removed.
Deactivate accounts and revoke credentials
Disable user and service accounts, remove the provider's group memberships and role assignments, and revoke API tokens, certificates, SSH keys and shared secrets. Where identity is managed centrally, deprovision the provider's users through the identity platform rather than by hand in each application, so removal is repeatable. Confirm each item against the access register. The artifact is a signed-off deprovisioning log with timestamps and the administrator who performed each action.
Terminate data flows and integrations
Stop scheduled exports, replication jobs, webhooks, API integrations, file transfer routes and network allowances that carry enterprise data to or from the provider. Remove firewall rules, VPN peers and DNS or routing entries that exist only for the provider. Check logs for a period after cutover to confirm no traffic remains. The artifact is a change record showing each flow stopped, the network change reference and the log evidence that traffic has ceased.
Return or dispose of enterprise data with written confirmation
Decide with the data owner whether enterprise data is returned, migrated or destroyed, and set that requirement against the contract clauses agreed under Safeguard 15.4, including data disposal terms. Request a written certificate from the provider confirming return or secure disposal of each data set, covering backups and subprocessors where the contract applies. Where you retain a copy for legal or record purposes, document the basis and the retention period. The artifact is the provider's signed disposal or return certificate, linked to the data inventory.
Close the inventory record and retain records
Change the provider's status in the service provider inventory to decommissioned, record the closure date and the owner who approved it, and file the access register, deprovisioning log, change records and disposal certificate together. Keep these records for the period your policy and regulators require, and note any open exception, such as data the provider could not confirm as destroyed. The artifact is a closed inventory entry with an archived evidence package, which is what an assessor samples when testing whether terminations were completed properly.
Evidence that shows a provider was terminated properly
Safeguard 15.7 is tested through records, not intentions. The six artifacts below show who ended the relationship, which accounts and integrations were removed, and how the provider confirmed disposal of enterprise data. Each one should be closed in the service provider inventory when the exit completes, so audit evidence is current rather than rebuilt after the fact.
Decommissioning record per provider
A single record for each terminated provider, showing the termination date, the accountable business owner, the reason for exit and the systems and data in scope. Link it to the entry in the service provider inventory from Safeguard 15.1. Check that the record names an owner who signed off on completion, and that no provider is marked active after its exit date. Close the record as the last step of the exit, not at the next audit.
Account deactivation logs and directory exports
Logs from the identity provider or directory showing user and service accounts disabled or deleted for the provider, with timestamps. An export taken after the exit should show no remaining accounts tied to that provider. Where an identity provider pushes deprovisioning to target applications, such as the authentik SCIM provider, keep the sync or deletion events as proof that removal reached the application. Confirm which accounts sit outside the directory, such as local administrator logins.
Integration and API key revocation records
Records showing that API keys, OAuth clients, webhooks and other machine credentials issued to the provider were revoked. Service accounts are often the weakest link because they outlive staff changes and rarely appear in user reviews. Keep the revocation ticket or change record, the list of credentials before and after, and a test showing that the old key no longer authenticates. Ask the provider to confirm it has discarded any copies it held.
Data flow shutdown confirmations
Evidence that every feed, sync job, file transfer, replication link and network route to the provider has stopped. Keep firewall or routing change records, scheduler configuration showing disabled jobs, and log entries showing no further transfers after the cutover date. Check for flows that were built by individual teams and never added to the inventory, because these are common reasons a terminated provider keeps receiving data.
Provider disposal or return certificate
The provider's written confirmation that enterprise data was returned, deleted or destroyed, and that backups and replicas were handled in the same way. The confirmation should name the data categories, the method used and the date, and should state any legal hold or retention exception that applies. Contract clauses from Safeguard 15.4, such as data disposal terms, define what this letter must cover. Ask whether the provider's own assurance report or an independent attestation covers its disposal process.
Policy clause defining the exit process
The section of the service provider management policy from Safeguard 15.2 that sets out the decommissioning steps, roles, deadlines and evidence required. Auditors start here because the CIS Controls Assessment Specification scores Safeguard 15.7 as failing when the policy gives no guidance for secure decommissioning. Keep the clause under version control, record the approval date, and confirm that the exit checklist used for each provider matches what the policy requires.
What meeting 15.7 costs in money and effort
This table breaks the cost of securely decommissioning service providers into components, showing who is paid, whether each cost is one-time or recurring, and what drives it up. Read it as a checklist for requesting quotes, since no prices or durations are given here. The main takeaway is that licence spend is often the smallest part of the work, while engineering, contract exit terms and evidence upkeep recur with every exit.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it |
|---|---|---|---|
| Tooling and licences | Software vendors, or no licence fee for self-hosted open-source directories and provisioning tools | Licences recur; open-source tools have no licence fee but still need hosting and upkeep | Number of identity platforms, connectors and environments in scope |
| Engineering time for deprovisioning automation | Internal platform or identity engineers, or an implementation partner under a written scope | One-time build, then recurring maintenance as applications change | Number of integrations, custom connectors and applications without SCIM support |
| Legal and procurement time for exit terms | Internal legal and procurement staff, or outside counsel | One-time per contract, with recurring review at renewal | Number of contracts, data sensitivity and whether terms already cover return and disposal |
| Data disposal verification | Internal security staff, plus the provider for certificates or logs of deletion | Recurring per exit | Data volume, number of storage locations and backup copies held by the provider |
| Evidence upkeep | Internal compliance or security staff who file termination records and evidence | Recurring per exit and per evidence review cycle | Number of exits each year and how many records each exit must produce |
| External review or assessor sampling | Independent auditor or assessor, who issues any report; the organization pays for the review | Recurring, usually tied to audit cycles | Audit scope, sample sizes chosen by the assessor and how well records are organized |
| Business continuity during transition | Internal operations and application owners | One-time per exit | Dependence on the provider, data migration needs and length of parallel running |
Open-source tools that can support 15.7 evidence
These open-source tools each cover part of the evidence for ending a service provider relationship: account deprovisioning, directory removal and the assessment record. None of them covers every step, so the last card names the gap that remains. Confirm each tool's fit against your own provider inventory before treating its output as evidence.
authentik SCIM provider
The authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour and deprovisions users who lose access to the application. For 15.7, the deprovisioning events and the target application's own user list, captured after the sync, show that a provider's accounts were removed. Confirm that each target application supports SCIM. An application without SCIM needs a manual removal, and that step must be logged separately.
FreeIPA directory records
FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects. It offers centralized access control and delegated administration through its web UI and command line tools. It serves as the central access record for internal identities, so removing a provider's staff or service objects here ends their internal access. Confirm that provider-issued accounts actually live in this directory, that delegated administrators can delete them, and that the change history can be exported. FreeIPA is licensed GPL-3.0-or-later, so review source obligations with counsel before modifying it.
CISO Assistant termination records
CISO Assistant ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and runs audits and assessments with automatic mapping between frameworks. It can hold each provider's termination record, the decommissioning requirement from your policy, and the evidence links that support them. It does not delete accounts or data, so attach evidence from the systems that did. Confirm the framework mappings against the source documents before an assessor relies on them. It is licensed AGPL-3.0-only, so hosting a modified version for others may trigger source obligations to review with counsel.
Provider data disposal evidence
None of the three tools above removes enterprise data from a provider's own systems, so this is the gap an assessor will probe first. Safeguard 15.7 covers securely disposing of enterprise data within provider systems, which depends on the contract terms and the provider's destruction method. Ask each provider for written deletion or destruction confirmation, record its date and scope, and link it to the contract clause from Safeguard 15.4. Confirm the wording with counsel before relying on it.
Who owns decommissioning, and what a partner can prepare
Your organization owns the decision to end a provider relationship, the termination record for each provider, and the attestation that enterprise data has been returned or disposed of. These are management and accountability duties. Safeguard 15.7 is measured against your service provider management policy, so the policy must already state how decommissioning is triggered, who approves it and what closes the file. The inventory from Safeguard 15.1 tells you which providers hold enterprise data and which accounts and data flows to check.
- Exit decision: A named owner approves each termination and records the reason, such as contract end, provider failure or a risk finding.
- Termination record: A dated record for each provider lists the accounts removed, data flows stopped and disposal method used.
- Data disposal attestation: The provider or the internal owner signs a statement that enterprise data was returned or destroyed, with the exceptions noted.
- Policy guidance: The policy includes decommissioning steps, since the assessment specification gives a failing score when no such guidance exists.
- Ongoing ownership: Someone checks that closed providers no longer appear in identity systems or integrations.
Check that each termination in your records has an approver, a completion date and a signed attestation that an assessor could sample.
An implementation partner can help you design the decommissioning procedure, build the deprovisioning and sync configuration in your self-hosted identity and integration platforms, prepare the evidence pack and test the workflow on a sample exit. This work makes the procedure repeatable and makes the records easier to produce. A partner cannot issue the assessor's conclusion, and cannot sign the attestation on your behalf.
- Procedure design: Written steps for account removal, data flow termination and disposal, aligned to your policy and classification levels.
- Deprovisioning configuration: Settings in platforms such as authentik, where its SCIM provider can remove users from target applications when access ends.
- Evidence pack preparation: Templates and logs that capture who did what and when, organized by provider.
- Sample exit test: A supervised walkthrough with a non-production provider to confirm the steps work and the logs are complete.
- Gap report: A list of places where accounts or data flows remain after an exit, handed to your team to fix.
Ask the partner to state in writing which tasks it performs and which remain with your staff, so the scope of prepared work is clear.
An independent auditor, assessor or certification body tests the decommissioning process and its records without involvement in building them. The assessor samples terminated providers, compares the termination records with identity system logs and disposal attestations, and reaches its own conclusion. Only the assessor issues that conclusion, and a report or certificate from it is what third parties rely on.
- Sampling: The assessor selects terminated providers from your inventory and checks each file.
- Record testing: It compares dates in the termination record with account removal and data flow logs.
- Disposal review: It examines the disposal attestation and any exceptions you recorded.
- Independence: The partner that configured the systems should not be the party that certifies the result.
- Licensing check: If a partner packages CIS Controls content for clients, the CIS Controls are licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0, and commercial use requires CIS's prior approval.
Before engaging any assessor, confirm which standard or scheme it will test against and which records it expects to sample.
Where organizations fall short on 15.7 and how to close it
Most failed decommissioning reviews trace back to a small set of gaps: a policy with no exit rules, exits that never reach IT, and data that survives the contract. Each card below names one gap, the closure step and the artifact an assessor will ask to see.
No decommissioning clause in policy
The assessment specification gives Safeguard 15.7 a failing score when the policy has no guidance for securely decommissioning service providers. Close the gap by adding a section to the service provider management policy from Safeguard 15.2 that sets out the exit steps: account deactivation, data flow termination, data return or disposal, and written confirmation. Assign an owner for each step. The artifact is the approved policy version with that section and its approval date, which the assessor will compare against your exit records.
Exits tracked only by procurement
When procurement closes a contract but IT is never told, accounts, API integrations and data feeds stay live after the relationship ends. Route every termination through a single ticketed workflow that IT, security and the business owner must each sign off on before the contract is marked closed. The artifact is a termination record per provider showing the ticket, the sign-off dates and the date the last account was removed.
Service accounts and API keys missed
Deprovisioning often covers named user accounts in the directory but misses service accounts, shared mailboxes, OAuth grants and API keys that the provider was issued. Build a list of every credential, integration and federation connection tied to the provider before exit, and revoke each one with a recorded action. Where users are provisioned to a provider automatically, a SCIM connector such as the authentik SCIM provider can remove users from the target application when they lose access, but you still need to confirm that service credentials are covered. The artifact is a revocation checklist signed by the system owner.
Data left in backups and exports
Termination often deletes the live tenant while copies persist in provider backups, analytics exports, shared drives and the enterprise's own archives. List every location where enterprise data was sent, including test environments and reports, and set a disposal date for each. Ask the provider to state how long backups are retained after termination and when they will be purged. The artifact is a data location register with a disposal action and date for each entry.
No written disposal confirmation
Without a written statement from the provider, you have no evidence that enterprise data was deleted or returned. Write the required disposal method and certificate into the contract under Safeguard 15.4, then request a signed confirmation that states what was removed, the method used and the date. Where the provider cannot give a certificate, record the reason and the compensating checks you ran. The artifact is the provider's signed disposal certificate, filed with the termination record.
Exit not linked to the inventory
If a provider is removed from the inventory without its exit being recorded, the register from Safeguard 15.1 shows an active supplier that no longer exists, and the assessment cannot measure the share of providers properly terminated. Set the inventory status to terminated only after the exit checklist is complete, and keep the record with its classification, enterprise contact and exit date. The artifact is the inventory entry showing terminated status, the completed checklist and the date of final data disposal.
Questions buyers ask about decommissioning service providers
How much effort does a service provider decommissioning procedure take?
The effort depends on how much enterprise data the provider holds, how many accounts and integrations connect to it, and how well the relationship is already documented. A provider that only holds a few user logins and no bulk data is a small exercise. A provider that holds customer records, feeds several business processes and has API connections into your identity systems needs a documented exit plan, a data inventory, and checks at each step. Cost has two parts: the internal time your identity, data and business owners spend, and any external work you buy. Ask for the work to be broken into named tasks with owners so you can see where the effort sits.
Does Safeguard 15.7 apply to every service provider or only IG3?
Safeguard 15.7 is assigned to Implementation Group 3 only, so it is one of the 23 Safeguards that IG3 adds on top of IG1 and IG2. An organization in IG1 or IG2 is not required to measure it under the CIS Controls, though a sound exit process is still good practice. Organizations in IG3 are expected to decommission providers securely. Whether a particular provider is in scope depends on your own service provider policy and classification under Safeguard 15.3, so confirm which providers you have classified as sensitive before scoping the work. Any regulator or contract that cites the CIS Controls may set its own expectations.
How long does a service provider exit take, and what sets the timeline?
No general duration can be stated with confidence, because the timeline depends on the provider, the data and your contract terms. The main drivers are the contractual notice and data return period, the volume and format of the data to be returned or deleted, the number of downstream systems that depend on the provider, and whether you need the provider to issue written confirmation of disposal. Replacement of the service, if you are moving to another provider, often sets the critical path. Ask for a timeline with dependencies marked, and confirm the contract's termination and data return clauses before agreeing a start date.
What does decommissioning need from our internal team?
Your team owns the decision and the evidence. You need a named business owner who confirms the relationship is ending, identity and access staff who can deactivate user and service accounts and revoke API keys or federation trusts, and data owners who confirm which enterprise data sits with the provider and what must be returned or destroyed. Security or compliance staff should review the disposal confirmation. Expect the most internal time to go to finding out what the provider holds and which integrations depend on it, since those facts are often missing from older records.
Can we decommission a service provider ourselves?
Yes, many organizations do this with internal staff, provided they have the access, time and documentation to do it properly. The work is largely administrative and technical: inventory the accounts and data flows, plan the sequence, deactivate access, terminate integrations and obtain disposal evidence. Internal teams often struggle with the discovery step and with coordinating the provider's data return. An implementation partner can help with the technical deactivation of accounts, such as configuring provisioning and deprovisioning in self-hosted identity tooling, and with keeping the evidence organized. Only your organization decides that the exit is complete, and only an independent assessor can test it against a standard.
How does automated deprovisioning help with a provider exit?
Automated deprovisioning reduces the chance that a user or service account remains active in a target application after access ends. For example, the authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour, and deprovisions users from the target when they lose access to the application. This helps keep account state consistent during an exit, but it does not dispose of data held by the provider. You still need a contract or process step that returns or destroys enterprise data and produces written confirmation. Confirm each connector's behavior in your own environment before relying on it.
What should we ask a partner for in a fixed-scope quote?
Ask for a written scope that names the providers in scope, the systems and accounts to be deactivated, the data flows to be terminated and the data stores to be returned or disposed of. Request the deliverables, such as an exit runbook, a dependency map, deprovisioning configuration, a disposal checklist and an evidence pack. Ask which tasks are fixed and which depend on the provider's response, what your team must supply and when, and how changes to scope are priced. Confirm that the partner prepares evidence and does not issue attestations, and ask who will review the final evidence for your assessor.
Which evidence will an assessor expect to see for a provider exit?
An assessor will typically look for the Safeguard 15.2 policy text covering decommissioning, the provider's inventory entry under Safeguard 15.1, records of account deactivation and removed integrations, and written confirmation of data return or disposal from the provider. The CIS Controls Assessment Specification scores Safeguard 15.7 with a Compliance metric based on the share of service providers properly terminated, and it fails the Safeguard if the policy contains no decommissioning guidance. Confirm with your assessor which records they accept and how long they expect them to be retained.
How DeployOpen prepares 15.7 decommissioning evidence
DeployOpen works on Safeguard 15.7 as an implementation partner: it prepares the account deactivation, data flow termination and disposal steps that a decommissioning record depends on, inside the client's own infrastructure. The organization owns the decision to exit a provider and the policy behind it, and an independent assessor is the party that tests and reports on the result.
How we scope
- Written scope lists each service provider being decommissioned, the systems and identity links involved, and the data stores to be disposed of.
- Scope confirms the prerequisite records from Safeguards 15.1 and 15.2 exist, including the provider inventory entry and the policy's decommissioning section.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any account or data work begins.
How we build
- Configure identity federation so user and group removals in the enterprise directory propagate to provider applications, for example through SCIM provisioning where the application supports it.
- Map every service and integration account, API key and data flow to the provider so each one has a named deactivation step.
- Test the disposal path on non-production data first, and record which deletion methods the provider confirms in writing.
How we hand over
- Decommissioning runbook with ordered steps, owners, and the evidence each step produces, such as directory change logs and deletion confirmations.
- Evidence pack that the organization can give its assessor, mapped to the Compliance metric of Safeguard 15.7: the share of providers properly terminated.
- Documented open items, such as provider-held backups or sub-processor copies, with the questions to put to the provider and the owner for each.
How we support
- Support for the next decommissioning cycle is available as a retainer, covering runbook updates and repeat evidence collection.
- Retainers can also cover reviewing provider contract exit clauses against the disposal steps the runbook depends on.
- Confirm with your assessor which artifacts they accept before handover, because only the independent assessor issues any conclusion on the safeguard.
