Cloud customer onboarding and offboarding controls

Cloud onboarding and offboarding is where small process gaps become big control failures: wrong tenant settings, lingering admin accounts, orphaned API keys, forgotten data replicas, and unclear customer responsibilities. ISO/IEC 27017 focuses on cloud-specific security controls and expectations. This requirement page translates the ISO 27017 “Cloud customer onboarding and offboarding controls requirement” into an operator-ready runbook you can implement with engineering, support, and security teams.

This is a “medium severity” control area in many internal control programs because the failures are common and the blast radius is real: cross-tenant exposure, unauthorized access after contract end, and data retention mismatches all tend to originate from weak lifecycle discipline. You do not need perfection on day one. You do need a single, enforceable process with clear owners, system-of-record artifacts, and a deprovisioning mechanism that does not rely on someone remembering a checklist.

If you want this to survive audits, make the lifecycle measurable: defined entry criteria, approvals, automated provisioning steps, validation gates, and exit criteria. Then store the evidence in one place so you can answer who approved, what changed, when it happened, and how you verified it.

Regulatory text

Framework: ISO/IEC 27017
Control reference: ISO27017-06
Provided excerpt: “Baseline implementation-intent summary derived from publicly available framework overviews; licensed standard text is not reproduced in this record.”
Implementation-intent summary: “Manage secure onboarding and offboarding of cloud customers and services.” ¹

What the operator must do (plain-English)

You must define and run controls that govern the full customer lifecycle in your cloud service:

• Onboarding: approve and securely provision a new tenant/customer context with the right baseline security configuration and access model.
• Changes during service: control identity, permissions, and configuration changes that are customer-specific.
• Offboarding: securely deprovision the tenant and customer access; handle data return, deletion, and retention commitments; remove or rotate customer-specific secrets/keys; document the handoff.

The audit expectation is consistency. If two customers onboard, the evidence should show the same gating controls happened both times, even if the technical details differ by plan or region.

Plain-English interpretation of the cloud customer onboarding and offboarding controls requirement

This requirement is about preventing three predictable failures:

1. Tenant misconfiguration at creation (wrong isolation settings, logging disabled, weak default roles).
2. Residual access after the relationship ends (accounts, tokens, support access, federated identity links).
3. Data handling drift (customer asks for deletion, but backups/snapshots/exports still exist; or retention is not aligned to contract).

To meet the requirement, build a lifecycle that is:

• Documented (policy + procedure),
• Controlled (approvals and segregation of duties where feasible),
• Repeatable (standard steps or automation),
• Provable (logs and records that show what happened).

Who it applies to

Entities

• Cloud providers / SaaS providers that provision and operate tenant environments for customers.
• Cloud customers (in ISO 27017 terms) when they are responsible for onboarding/offboarding within their own cloud usage, such as creating projects/subscriptions, managing identities, or deprovisioning services.

Operational context (where auditors focus)

• Multi-tenant SaaS platforms (tenant provisioning, isolation, admin access)
• Single-tenant hosted offerings (environment creation, image hardening, network segmentation)
• Managed services (customer accounts in underlying IaaS/PaaS, break-glass access)
• Any service with customer-scoped secrets, encryption keys, integrations, or data exports

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

Use this as a minimum viable lifecycle. Adapt the technical steps to your stack, but keep the gates and evidence.

1) Define the lifecycle and owners

• Assign an onboarding owner (often Ops/Provisioning) and an offboarding owner (often Support + Security or Ops).
• Define RACI for: Sales/CS, Support, Engineering, Security, Privacy/Legal (if applicable).
• Choose your systems of record: ticketing (workflow), IAM (access), CI/CD or IaC logs (provisioning), and an evidence repository.

Output: Onboarding/Offboarding SOP + RACI + checklist templates.

2) Standardize onboarding intake and approvals

Create an intake form or ticket type with required fields:

• customer legal name, environment name/tenant ID, region, service tier
• data classification expectations (customer-provided)
• identity model (local auth vs SSO), initial admins, support access model
• contractual data handling requirements (return/deletion/retention triggers)

Add approval gates:

• Security approval for any non-standard configuration (exceptions)
• Engineering approval for custom integrations or privileged access paths

Control design note: Default-deny on “non-standard” is easier to audit than “tribal knowledge approvals.”

3) Provision using hardened baselines (prefer automation)

Provision tenants/environments from standard templates (IaC or scripted runbooks):

• baseline network controls (segmentation, inbound rules)
• baseline logging/monitoring enabled by default
• default roles and least-privilege access patterns
• secrets management integration and key generation (customer-scoped)

Add a post-provision validation gate:

• confirm tenant isolation controls are active
• confirm logging is flowing
• confirm admin accounts match the approved list
• confirm support access is off by default or time-bound

Evidence tip: Save the template version, change request, and the provisioning job output.

4) Perform customer handoff with shared responsibility clarity

At go-live, provide a security handoff package:

• how admins are created and removed
• how to enable SSO/MFA (if customer-managed)
• customer responsibilities for endpoints, credentials, and their user lifecycle
• how to request deletion/offboarding, and what “deletion” means in your service

Track the handoff acknowledgment in your CRM/ticketing.

5) Control ongoing customer-specific changes

Treat these as extensions of onboarding:

• adding/removing tenant admins
• enabling integrations (API keys, OAuth apps, webhooks)
• changing data residency/region (if supported)
• granting support access

Require:

• authenticated requester verification
• approval for privileged actions
• logging of who did what and when
• periodic review triggers for long-lived privileged access paths

6) Execute offboarding with a defined “exit criteria” checklist

Your offboarding procedure should include, at minimum:

Access shutdown

• disable tenant admins and users (or customer SSO connection)
• revoke API keys, tokens, OAuth grants, service accounts
• remove support access and break-glass credentials (or rotate them)

Data handling

• confirm data export/return steps (if applicable)
• execute deletion/retention steps per contract and policy
• address data in: primary stores, caches, search indexes, analytics pipelines, file/object storage, and backups/snapshots based on your documented approach

Configuration cleanup

• delete tenant configuration artifacts
• remove DNS entries, certificates, and customer-specific secrets
• remove allowlists/firewall rules created for the customer

Verification + closure

• run a deprovision validation (tenant no longer accessible; secrets invalid)
• notify the customer of completion and what remains under retention policy
• close the record only after evidence is attached

7) Manage exceptions explicitly

For any offboarding that cannot delete immediately (legal hold, billing disputes, technical constraints), record:

• reason, approver, scope, and duration
• compensating controls (access disabled, encryption keys rotated, monitoring)

Auditors accept constraints when you document them and control the risk.

Required evidence and artifacts to retain

Store evidence per onboarding/offboarding event and per process design.

Process (design-time) artifacts

• Onboarding/offboarding policy and SOP (approved, versioned)
• RACI and escalation paths
• Provisioning baseline templates (IaC modules, configuration standards)
• Offboarding data deletion/retention standard (what systems are in scope, what is excluded, and why)

Operational (run-time) artifacts

• Intake ticket with required fields completed
• Approval records (security/engineering exceptions)
• Provisioning logs (build pipeline output, IaC plan/apply logs, change records)
• Post-provision validation results (automated checks or signed checklist)
• Customer handoff acknowledgment and shared responsibility notes
• Offboarding request, identity verification steps, and closure notice
• Deprovision logs: account disablement, token revocation, key rotations, resource deletions
• Exception records and compensating controls

Practical audit rule: If it isn’t captured in a system of record, it didn’t happen.

Common exam/audit questions and hangups

Use these as a pre-audit checklist.

1. “Show me three recent onboardings and the approvals, provisioning steps, and validation.”
   Hangup: teams can describe the process, but cannot produce consistent evidence.

2. “How do you ensure offboarding removes all access paths?”
   Hangup: API keys, OAuth grants, and service accounts are missed because ownership is unclear.

3. “What does deletion mean in your environment, including backups?”
   Hangup: deletion is performed in primary systems, but backups/replicas are not addressed in a documented way.

4. “How do you prevent non-standard tenant configurations?”
   Hangup: sales-driven customizations bypass security review.

5. “How do you verify that deprovisioning worked?”
   Hangup: closure is based on task completion, not on validation tests.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails audits	Fix
Offboarding is a support checklist with no technical enforcement	Humans miss steps; evidence is incomplete	Add automated revocation/deletion where possible; require logs attached before closure
No single system of record	Evidence is scattered across Slack, email, and consoles	Make the ticket the “spine” and attach/ लिंक logs and outputs
Customer-specific secrets not tracked	Orphaned secrets become persistent access	Maintain an inventory of customer-scoped secrets and rotate/delete on offboarding
“Deletion” promises exceed reality	Contract/privacy risk and customer disputes	Document what’s deleted, what’s retained, and the method for backups based on your policy
Exceptions are informal	Auditors see uncontrolled variance	Use an exception template with explicit approver and compensating controls

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat this section as risk context rather than case-law guidance.

Operationally, onboarding/offboarding breakdowns tend to map to:

• Confidentiality risk: cross-tenant access, lingering credentials, unauthorized support access
• Integrity risk: wrong tenant configuration, unintended admin privileges
• Availability risk: deprovisioning the wrong tenant, unmanaged dependencies during exit
• Contract and privacy risk: inability to prove deletion/retention commitments

Treat “can’t prove it” as a control failure. ISO-style audits are evidence-driven.

Practical 30/60/90-day execution plan

First 30 days: stabilize and make it auditable

• Pick the system of record for onboarding/offboarding (ticket workflow) and require it for every event.
• Publish v1 SOPs: onboarding, offboarding, and exceptions.
• Create standard intake fields and approval rules.
• Build v1 checklists for provisioning validation and deprovision validation.
• Train Support/Ops/CS on the “no ticket, no action” rule.

By 60 days: reduce manual risk and close common gaps

• Convert baseline provisioning to templates or automation where feasible.
• Add customer-scoped secret inventory and defined rotation/deletion steps.
• Implement standard requester verification for admin changes and offboarding requests.
• Define and publish your deletion/retention approach for backups and replicas (in plain language for customers and auditors).
• Start sampling: review recent onboardings/offboardings for completeness and fix the workflow.

By 90 days: mature controls and reporting

• Add automated validation checks (logging enabled, isolation settings, admin list matches approvals).
• Add metrics for control operation (counts of onboardings/offboardings, exceptions, overdue deprovisions) without turning them into vanity stats.
• Run an internal audit-style walkthrough with evidence pull: select samples and test end-to-end.
• If you use Daydream, map the onboarding/offboarding workflow to a control narrative and evidence requests so audits become a repeatable evidence export rather than a scramble.

Frequently Asked Questions

Do we need different processes for onboarding vs offboarding?

Yes. They share a lifecycle mindset, but offboarding needs extra rigor around access revocation, data handling, and cryptographic material. Treat offboarding as a security event with defined exit criteria and verification.

What counts as acceptable evidence for offboarding?

Auditors expect a closed record that includes the request, identity verification, the deprovision checklist, and technical logs showing access was revoked and resources were removed. A “completed” ticket with no attachments usually fails sampling.

How do we handle data deletion if backups can’t be surgically deleted?

Document your approach clearly: what is deleted immediately, what remains in backups, who can access it, and how it expires under your retention policy. Track exceptions (like legal holds) with approvals and compensating controls.

We’re a cloud customer, not a cloud provider. Does this still apply?

Yes, if your teams provision cloud accounts/projects and onboard internal business units or external users into those environments. Your “customer” may be an internal tenant, but the access and deprovision risks are the same.

What’s the minimum automation needed to meet the requirement?

Automation is not mandatory, but repeatability and evidence are. Start with standardized templates and required workflow fields, then automate the highest-risk steps: privileged access, token revocation, and tenant deletion validation.

How do we prevent Sales or Support from bypassing controls for a “quick go-live”?

Make the baseline path fast and the exception path visible. Require security approval for non-standard configurations and block provisioning steps unless the ticket includes the required approvals and fields.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control lifecycle management

Footnotes

1. ISO/IEC 27017 overview