Unique use of cloud service customer user IDs

This requirement is deceptively small and easy to get wrong in real operations. Many cloud service providers and SaaS teams focus on password policy, MFA, session controls, and access reviews, then overlook a basic identity hygiene issue: the same user ID being reused for a different person after an employee leaves, a contractor rotates, or a customer admin “cleans up” accounts.

ISO/IEC 27018 targets public cloud PII processors, meaning organizations that process PII on behalf of cloud customers. The control aims to prevent identity confusion, misdirected access, and audit trail corruption. If a user ID can be reassigned, then historical logs and permissions may appear to belong to the “new” user. That breaks nonrepudiation, complicates incident response, and raises the chance that the wrong person gains access to PII.

This page gives requirement-level implementation guidance for a CCO, compliance officer, or GRC lead who needs to operationalize the control quickly. The goal is simple: establish a lifecycle model where customer user IDs are unique and never reissued to another user, with clear evidence to prove it.

Regulatory text

Requirement (verbatim): “Where a public cloud PII processor registers cloud service customer user IDs, those user IDs shall not be assigned to other users.” ¹

What the operator must do: If your service creates or stores customer user identifiers (for example, usernames, account IDs, directory IDs, or other identifiers your system uses to represent a user), you must ensure you never reassign a previously registered ID to a different individual. “Disable” and “delete” are not enough if deletion makes the ID available for reuse later.

Plain-English interpretation

• A customer user ID is a long-lived identity handle inside your cloud service (or connected identity layer) that represents a person.
• If you ever assigned ID = X to Alice, then ID = X must never later represent Bob, even if Alice leaves and you delete her account.
• The requirement focuses on assignment. You can keep the ID in a retired state, but you cannot give it to someone else.

A practical way to think about it: your ID system needs “memory.” Once an identifier is used, it becomes burned (retired permanently) or immutable (still exists, but no longer active).

Who it applies to

Entity scope

• Public cloud PII processors: cloud service providers processing PII for customers in a public cloud context. ¹

Operational scope (where it shows up in practice)

• Your SaaS application user directory (internal user table, tenant directory).
• Your IAM/IdP if you register customer users there (for example, a managed IdP instance you operate on behalf of customers).
• Provisioning connectors (SCIM, JIT provisioning, HRIS-to-directory pipelines) where IDs can be created, renamed, deactivated, deleted, or recreated.
• Support/admin tooling where staff can “free up” usernames or merge accounts.

Common scoping decision

• If your system stores an internal immutable identifier (for example, user_uuid) and separately stores a mutable display name (for example, username or email), your compliance position depends on what you treat as the “user ID.” Examiners typically care about the identifier that drives authorization decisions and log attribution. Document which field is the authoritative user ID and enforce non-reassignment for that field.

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

1) Define what counts as a “customer user ID” in your service

Create a short, explicit definition and data model mapping:

• Authoritative user identifier(s) used for authentication and authorization (for example, internal user_id, external subject, directory object_id).
• Any alternate identifiers customers see and might expect to be unique (for example, usernames).
• Any identifiers written into logs and audit trails.

Deliverable: “Customer User ID Definition” section in your IAM standard.

2) Choose a non-reassignment strategy that fits your architecture

Use one of these patterns, and document it:

Pattern	How it works	Where it fits	Primary risk to manage
Immutable internal ID + mutable login name	Internal ID never changes; login name can change	Most SaaS	Must ensure logs and authorization use internal ID, not mutable name
Tombstone / burned ID registry	Deleted IDs remain reserved forever	Systems with human-readable IDs	Growth of reserved namespace; need clear retention logic
Soft delete only	Accounts never truly deleted; set inactive	Regulated audit-heavy environments	Data minimization and retention alignment; privacy requests need handling
Tenant-scoped uniqueness	ID uniqueness enforced within a tenant	Multi-tenant SaaS	Must prevent cross-tenant collisions in global logs/admin tooling

Deliverable: An architecture decision record (ADR) that states: “Once assigned, IDs are never reassigned.”

3) Implement hard technical controls to prevent reassignment

Controls should be enforceable by system behavior, not policy alone.

Minimum guardrails to implement:

• Uniqueness constraint in the database for the authoritative ID (and any other identifier you promise is unique).
• No “reuse” code path: deletion must not free the identifier for future assignment.
• Block or strictly control renames if the renamed value could collide with a previously used identifier.
• SCIM/JIT protections: if provisioning receives an ID that matches a retired identity, fail closed and require manual review.
• Admin tool restrictions: remove “reset user” behaviors that drop identity state and recreate with the same ID.

Practical test: Attempt to create a new account using a previously deleted/retired identifier. The system should reject it deterministically and log the event.

4) Align lifecycle workflows (Joiner/Mover/Leaver) to “retire, don’t recycle”

Your operational procedures must match the control:

• Deprovision: disable access, revoke sessions/tokens, remove entitlements.
• Retire: mark the ID as permanently reserved or inactive.
• Record: retain the mapping between the retired ID and the original user for audit trail integrity (subject to your retention policy).

If customer admins can manage users, add customer-facing guidance: “Do not delete and recreate to ‘reuse’ an ID; create a new identity.”

5) Ensure audit logs preserve correct attribution

A common failure mode is logs that key off a mutable identifier (email/username).

• Log with the immutable internal ID as the primary subject.
• Treat email/username as an attribute that can change.
• Preserve historical values where needed for investigations.

6) Add monitoring and periodic checks

You want an automated way to detect violations or near-misses:

• Alert on attempted creation of an ID that matches a retired ID.
• Report on identity merges, manual admin edits, or direct database operations affecting identity tables.
• Run a control check that searches for duplicate authoritative IDs (should be impossible if constraints are correct).

7) Vendor/third party dependencies (where your proof can break)

If a third party identity platform generates IDs you “register” in your service:

• Confirm their ID non-reassignment behavior contractually or via due diligence.
• Still implement your own application-layer controls to prevent reuse inside your domain.

If you use Daydream to manage third-party risk and compliance evidence collection, map this control to your IAM and SDLC evidence requests so engineering supplies configuration screenshots/exports, lifecycle procedures, and a negative test result showing reuse is blocked.

Required evidence and artifacts to retain

Keep evidence that proves both design and operation:

Policy/standards

• IAM standard defining “customer user ID” and stating IDs are not reassigned.
• Account lifecycle procedure (provisioning, deprovisioning, retirement).

Technical configuration and implementation

• Data model snippet showing immutable ID field and uniqueness constraints.
• Configuration exports from IAM/IdP or directory showing identifier behavior (as applicable).
• Admin tooling permissions model showing who can perform identity changes.

Operational evidence

• Sample of deprovisioning tickets showing “disabled” and “retired” steps completed.
• Audit logs demonstrating: (a) user deactivated, (b) attempted reuse blocked (if you have such events), (c) identity attribution uses immutable ID.
• Test evidence from QA/security: negative test case “cannot recreate account with retired ID.”

Change management

• Change records for any modifications to identity schema, provisioning flows, or admin tools.

Common exam/audit questions and hangups

1. “What is the user ID in your system?” Expect follow-ups if you answer with email/username. Be prepared with a data dictionary.
2. “Can a deleted username be reused?” If yes, the auditor may treat the username as the “registered user ID” unless you clearly separate it from the authoritative ID.
3. “Show me evidence.” Auditors often want both config and a live demonstration or test record.
4. “What about contractors and shared accounts?” Shared accounts complicate attribution; if allowed, document compensating controls and keep the unique ID rule intact.
5. “What happens when a customer requests deletion?” Your privacy process must reconcile deletion with retaining a tombstone/retired identifier for security and audit integrity. Document how you do that within your retention and deletion policy boundaries.

Frequent implementation mistakes and how to avoid them

• Mistake: Treating “delete” as compliant. If delete frees the ID for reuse, you fail the requirement. Fix with tombstones or immutable IDs.
• Mistake: Using email as the primary key. Email changes. Use a stable internal ID; store email as an attribute.
• Mistake: Allowing support staff to “fix” identity issues by recreating accounts. Lock down tooling; require controlled workflows.
• Mistake: Provisioning system overwrites identity linkages. In SCIM/JIT, ensure the stable identifier is the join key; reject ambiguous matches.
• Mistake: Logs don’t survive renames. Log immutable IDs and keep historical attributes.

Enforcement context and risk implications

No public enforcement cases were provided for this specific ISO/IEC 27018 control in the source material. The operational risk is still concrete: ID reassignment can cause unauthorized access to customer data, misattributed actions in audit logs, and failed incident investigations. Those outcomes increase regulatory and contractual exposure even if the requirement itself is framed as a standard control.

Practical execution plan (30/60/90)

First 30 days (triage and design)

• Inventory all systems that create/store customer identities (app DB, IdP, directories, provisioning).
• Decide and document the authoritative “customer user ID.”
• Identify any paths where deletion enables reuse (self-service UI, admin console, API, back-office scripts).
• Write a short standard: “IDs are never reassigned,” plus lifecycle definitions.

By 60 days (build and prove)

• Implement technical guardrails: uniqueness constraints, tombstones/soft delete, API validation.
• Update provisioning flows to fail closed on retired IDs and collision cases.
• Update logging to key off immutable ID; verify rename behavior doesn’t corrupt attribution.
• Produce an audit packet: configs, data model, and a negative test showing non-reassignment.

By 90 days (operationalize and sustain)

• Add monitoring for collision attempts and admin identity edits.
• Train support and customer success on “retire, don’t recycle” workflows.
• Add control checks to release/change management for identity code paths.
• Centralize evidence collection (for example, in Daydream) so each audit cycle you can refresh the same artifacts without scrambling engineering.

Frequently Asked Questions

If we delete a user, can we reuse their username for a new employee at the same customer?

If the username is the “registered customer user ID” in your service, reuse would violate the requirement. If you separate login/display name from an immutable internal ID, you can allow username reuse only if logs and authorization never treat the username as the authoritative user ID.

Does this apply to internal staff accounts or only customer users?

The text addresses “cloud service customer user IDs” registered by a public cloud PII processor. If your internal staff can access customer PII, applying the same non-reassignment rule to staff IDs is a practical extension, but document scope so audits don’t get stuck on definitions.

What about email addresses as identifiers?

Email is a poor authoritative identifier because it changes and can be reassigned by an organization. Use a stable internal ID for identity and logging, and treat email as an attribute with history.

We use an external IdP. Are we still responsible?

Yes, if your service registers and relies on customer user IDs. Confirm the IdP’s non-reassignment behavior and enforce your own controls so your application never maps a retired ID to a different person.

How do we handle “right to deletion” requests while keeping a tombstone?

Separate “access disablement + identifier retirement” from retaining unnecessary PII. A tombstone can reserve the identifier with minimal data so you prevent reassignment while honoring your deletion policy. Document the fields retained and the purpose.

What evidence will an auditor accept to show IDs are never reassigned?

Show the design (data model/constraints or directory configuration), the process (lifecycle procedure), and operational proof (test case or logs demonstrating that reuse attempts are rejected and that attribution is tied to an immutable ID).

Footnotes

1. ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors