Removal of cloud service customer assets

The “removal of cloud service customer assets” requirement means you must be able to promptly remove all customer-provided or customer-created assets from your cloud infrastructure at contract termination, and securely return them to the customer when applicable. Operationalize it by defining “customer assets,” building a repeatable offboarding workflow, and retaining verifiable evidence that assets were returned and/or deleted within the agreed timeframe. ¹

Key takeaways:

• Define the asset boundary: production data, backups, logs, keys, metadata, and customer-configured content.
• Implement an offboarding runbook with ownership, timelines, and deletion/return verification steps.
• Keep audit-ready proof: export manifests, deletion logs, support tickets, and customer confirmations.

ISO/IEC 27017:2015 CLD.8.1.5 is a simple sentence that creates a hard operational expectation: when a cloud service agreement ends, you must remove customer assets from your infrastructure and, where relevant, return them securely to the customer in a timely manner. The control is easy to “agree with” and easy to fail in practice because cloud environments replicate data by design (snapshots, backups, caches, DR copies, search indexes, analytics stores), and different teams own different layers.

A Compliance Officer, CCO, or GRC lead should treat this as an offboarding control with three outputs: (1) a contractual and procedural definition of what counts as a “customer asset,” (2) a standardized and testable process to export/return and delete across all systems where data lands, and (3) evidence that stands up to an audit without heroic forensics. Your goal is not perfection on day one; your goal is a repeatable process with clear exceptions, documented customer instructions, and demonstrable execution.

Regulatory text

Requirement (verbatim): “Cloud service customer assets that are placed on the cloud service provider infrastructure shall be removed, and if applicable, securely returned to the cloud service customer, in a timely manner upon termination of the cloud service agreement.” ¹

Operator interpretation (what you must do):

• Identify and scope customer assets that reside on your infrastructure due to the service (including derived copies you create to operate the service).
• Upon termination, execute an offboarding event that results in (a) return of assets when applicable and (b) removal of assets from provider-controlled infrastructure.
• Do it “in a timely manner,” meaning within a defined, agreed, and operationally supported timeframe, with the ability to prove completion. ¹

Plain-English interpretation (requirement-level)

If the customer leaves, you don’t get to keep their stuff. You must:

1. give them their data back when the contract or customer request requires it, using a secure transfer method; and
2. delete their assets from your systems (including secondary copies you control), then keep evidence showing what you returned and what you deleted. ¹

Who it applies to

In-scope entities

• Cloud service providers (CSPs): primary duty to remove and (if applicable) return assets because the assets sit on the provider’s infrastructure. ¹
• Cloud service customers: indirectly in scope because they must define return expectations, provide receiving endpoints, and validate successful return/removal as part of exit management. ¹

In-scope operational contexts (what “customer assets” usually means)

Treat “assets” broadly unless your contract very explicitly narrows it:

• Customer content: files, database rows, objects, messages, documents.
• Customer configuration and artifacts: tenant configuration, policy objects, workflow definitions, templates.
• Identity and access artifacts: customer user profiles, role mappings, API tokens created for the customer, where applicable.
• Cryptographic material you host: customer-managed keys you store or proxy; key metadata; wrapped data keys.
• Operational data created by the service about the customer: audit logs, usage logs, support attachments, monitoring traces tied to tenant identifiers.
• Copies: backups, snapshots, replicas, DR images, cached copies, search indexes, analytics extracts.

Auditors tend to focus on the things teams forget: backups, logs, and “hidden” derived stores (indexes, data lakes, debug buckets).

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

1) Define the termination trigger and ownership

• Trigger events: contract termination, non-renewal, account closure, customer instruction, or forced termination.
• Assign an owner: typically Security/Compliance defines the control, but Operations/Platform executes it. Put a single accountable role on the runbook.
• Define decision points: whether the customer requested return; whether legal hold applies; whether there are unpaid invoices affecting access (be careful: business disputes do not eliminate security obligations).

2) Build a “customer asset inventory map”

Create a living map from “tenant” to “systems where tenant data lands.” Minimum fields:

• System name (prod DB, object store, search index, logs, backups, DR)
• Data types stored
• Tenant identifier used
• Deletion method (API purge, storage lifecycle, crypto-erasure, manual ticket)
• Evidence produced (log line, job output, change record)
• Dependency/owner team

This is the backbone of your ability to claim “removed from infrastructure.”

3) Set the exit return/deletion requirements in the agreement and customer-facing docs

The standard’s phrase “securely returned” and “timely manner” needs operational definition in:

• Contract terms / offboarding addendum: what will be returned, format, transfer method, and the timeframe commitment. ¹
• Customer offboarding guide: how customers request export, prerequisites (e.g., destination S3 bucket, SFTP endpoint), and what evidence they will receive.

If you cannot commit to a specific timeframe across all systems, document different timelines by system class (production vs. backup) as part of the agreed approach. The standard allows “timely” as an agreed expectation; it does not force a single universal number. ¹

4) Implement the offboarding workflow (return then remove)

A practical sequence that holds up in audits:

1. Open an offboarding case in your ticketing system with the termination trigger and scope (tenant IDs, environments, regions).
2. Validate authority (the requester is authorized) and capture the customer’s return instructions.
3. Generate an export manifest (what will be returned, from which systems, in what format).
4. Perform secure return (if applicable):
   • Prefer customer-controlled destination + encrypted transfer.
   • Keep integrity evidence: checksums or signed manifest.
5. Confirm customer receipt (explicit confirmation or a defined acceptance window in your process docs).
6. Execute removal plan across the asset inventory map:
   • Production stores: purge tenant data, verify zero remaining rows/objects for tenant IDs.
   • Secondary stores: delete snapshots where feasible; expire backups via lifecycle; delete indexes; purge logs per policy; remove support attachments; delete staging exports after handoff.
   • Keys: revoke customer credentials; delete or disable customer key material you host; record key destruction where applicable.
7. Verify removal: run a post-check query/search for tenant IDs in each system class, record outputs.
8. Close with an offboarding certificate: a standardized summary of what was returned and what was removed, including exceptions (e.g., “backup copies expire per retention policy”).
9. Access cleanup: disable accounts, API keys, and integrations tied to the customer to prevent data re-ingest.

5) Handle exceptions without breaking the control

Common legitimate exceptions:

• Legal hold / eDiscovery: pause deletion for specific data sets, document the hold, and narrow scope.
• Regulatory retention: if you must retain certain records, segregate them, restrict access, and document why they cannot be removed immediately.
• Shared multi-tenant artifacts: ensure you delete tenant-specific records without harming other customers.

The audit expectation is that exceptions are pre-defined, approved, and evidenced, not improvised.

Required evidence and artifacts to retain

Build an “offboarding evidence packet” per terminated customer:

• Termination request or contract termination notice
• Offboarding ticket(s) with timestamps, approvals, and assigned owner
• Asset inventory map snapshot used for the offboarding (or reference to the controlled version)
• Export manifest and transfer logs (including encryption method and destination confirmation)
• Deletion job outputs (system logs, batch job IDs, API responses)
• Post-deletion verification results (queries, inventory listings, tenant ID searches)
• Exception records (legal hold notice, retention requirement justification)
• Customer confirmation of receipt (or documented acceptance process)
• Final offboarding certificate / closure note signed by an authorized internal approver

A recurring exam hangup: evidence must show actions across all storage locations you control, not just the primary database.

Common exam/audit questions and hangups

Expect auditors to ask:

• “Define ‘customer assets’ for your service. Does it include logs and backups?”
• “Show me the runbook and the last completed offboarding.”
• “How do you prove deletion in object storage and backups?”
• “What does ‘timely’ mean in your contracts, and how do you meet it?”
• “How do you prevent re-ingestion after termination (integrations, API keys, service accounts)?”
• “Who approves exceptions, and where is the evidence?”

Hangup pattern: teams can describe the process but cannot produce a complete evidence packet for a real customer.

Frequent implementation mistakes (and how to avoid them)

1. Only deleting the application database.
   Fix: inventory every data store and require sign-off from each system owner.

2. No customer-return path, only “you can export yourself.”
   Fix: publish a supported export method or a contractual statement that the customer is responsible for export before termination, plus a defined window and assist process. Align this with “if applicable.” ¹

3. Backups are treated as “out of scope.”
   Fix: document backup deletion/expiry method and retention, and show it in the offboarding certificate as a stated lifecycle outcome.

4. Manual steps with no verification.
   Fix: add post-deletion checks and attach outputs to the ticket.

5. Support systems overlooked.
   Fix: include ticketing attachments, shared drives, and CRM notes as part of “customer assets” where they contain customer-provided content.

Enforcement context and risk implications

No public enforcement cases were provided for this specific ISO/IEC 27017 control in the source catalog. Treat the risk as practical and contractual: failure to return/remove assets can create confidentiality exposure (residual data), breach notification risk if data is later accessed, and contract disputes where customers claim you retained or mishandled their data. ¹

Practical 30/60/90-day execution plan

To avoid making unsourced timing claims, use these phases as a sequencing tool, not a promise of completion time.

Immediate (stabilize and define)

• Write the one-page requirement statement: what assets, what triggers, what “return” means, what “remove” means. ¹
• Stand up an offboarding ticket template with mandatory fields (tenant ID, systems, export required, exceptions).
• Draft the customer offboarding guide and internal runbook skeleton.

Near-term (implement and test)

• Build the customer asset inventory map and assign owners for each system.
• Implement export/return procedure (format + secure transfer + manifest).
• Implement deletion steps per system (automation where possible) plus verification checks.
• Run a tabletop exercise on a “sample termination” and produce a mock evidence packet.

Ongoing (operate and prove)

• Run periodic internal reviews of completed offboardings for evidence completeness.
• Update the asset inventory map after architecture changes (new pipelines, new logs, new regions).
• Add the control to third-party risk reviews if you are a customer of other cloud services: require their termination removal/return terms to match your obligations downstream.

Where Daydream fits (without adding process weight)

Daydream can help you standardize third-party offboarding evidence collection across cloud providers and other third parties by templating the evidence packet, routing tasks to system owners, and keeping the proof tied to each termination event. That reduces the “we did it, but can’t prove it” failure mode during audits.

Frequently Asked Questions

What counts as “cloud service customer assets” in practice?

Start with any customer-provided data and tenant configuration stored on your infrastructure, then add derived copies you create to operate the service (backups, replicas, indexes, logs tied to tenant identifiers). Document the boundary in your offboarding runbook. ¹

Do we have to return data in every termination?

The requirement says “if applicable,” so you need a defined rule for when return applies, typically based on contract terms and customer instructions. If self-service export is the model, document the process and the support you provide. ¹

How do we prove deletion from backups?

Treat backups as a governed lifecycle: document how backup sets are identified by tenant and how they are expired, deleted, or rendered unreadable (for example through key destruction where applicable). Keep system logs or job outputs that show the action taken and the retention logic used.

What does “timely manner” mean for auditors?

Auditors expect you to define it and meet it consistently. Put the timeframe expectation in the agreement or offboarding documentation, then show tickets and logs that demonstrate you executed within that agreed window. ¹

Can we keep some customer data after termination for legal or regulatory reasons?

Yes, but treat it as an exception with documented authority (legal hold, retention requirement), scoped data sets, access controls, and a defined eventual disposal path. Your offboarding certificate should disclose the exception.

We’re a cloud customer. How do we enforce this on our providers?

Put explicit termination return/removal terms in the contract and require evidence of completion (deletion attestation plus descriptions of backup handling). Ask for their offboarding runbook summary during due diligence. ¹

Footnotes

1. ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services