Cloud service customer user ID contracts

“Cloud service customer user ID contracts requirement” maps to a narrow but high-impact failure mode: identity lifecycle events can accidentally re-expose someone else’s data. In real operations, user IDs get deprovisioned, recycled, renamed, or reissued. If your platform connects user IDs to stored PII (profile fields, HR data, billing info, audit logs containing personal data, support tickets, identity attributes), then reassigning an expired user ID can cause that PII to become visible to the new holder of the identifier or other parties.

ISO/IEC 27018:2019 Annex A.11.9 draws a bright line: if a customer’s user ID expires because of inactivity, the associated PII cannot be made available to other parties without the original customer’s authorization. This is both a product requirement (how IDs, directories, and tenants work) and a contractual requirement (what you promise customers, and what you require internal teams and subprocessors to follow). For a CCO or GRC lead, the fastest path is: (1) define “user ID expiration due to inactivity,” (2) eliminate identifier reuse or hard-isolate PII from identifiers, (3) lock down support/admin access paths, and (4) document and evidence the control end-to-end.

Regulatory text

Requirement (verbatim): “Where the user IDs of cloud service customers expire as a result of inactivity, the associated PII shall not be made available to other parties without the authorization of the original cloud service customer.” (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)

Operator meaning: if your service expires an account identifier because it has been inactive, you must design and run the service so that any PII linked to that identifier cannot be accessed by anyone else (including a different user, a different customer tenant, or a successor “new” account) unless the original customer explicitly authorizes that disclosure or reuse. (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)

Plain-English interpretation

You cannot “recycle” an inactive/expired customer user ID in a way that could expose the prior user’s PII to another party. This includes accidental exposure paths, such as:

• Reissuing the same username/email-style ID to a different person later.
• Moving an identifier between tenants or customer organizations.
• Allowing admins or support staff to “reactivate” an ID into a different context without the original customer’s approval.
• Using the expired ID as a lookup key that still retrieves PII in APIs, logs, exports, or analytics.

If you must allow reuse, you need explicit authorization from the original customer, and you need evidence of that authorization. (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)

Who it applies to

In-scope entities

• Cloud service providers acting as PII processors for customer data in a public cloud service context. (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)

In-scope operational contexts

You should treat this requirement as applicable if any of the following are true:

• Customer user accounts can become inactive and later expire (automatic deactivation, auto-delete, dormant status, license removal, etc.).
• A “user ID” is a persistent identifier that can be reassigned (username reuse, email reuse, numeric ID reuse, SCIM re-provisioning into a new tenant).
• PII is connected to the identifier in any datastore (identity directory, profile DB, billing, support CRM, audit logs, message content, attachments, telemetry that contains personal data).

Typical owners

• Product/Engineering (identity model, tenant boundaries, deletion/retention mechanics)
• Security (access control, logging, privileged access)
• Privacy (PII mapping, authorization language, customer notices)
• Legal/Commercial (customer contract language)
• Support Operations (reactivation workflows, identity proofing)

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

1) Define the triggering event: “expires as a result of inactivity”

Write a precise internal definition that product, support, and security all use:

• What counts as inactivity (no login, no API calls, license removed, org disabled)?
• What “expiration” means (cannot authenticate, identity removed from tenant, username released)? Then map every state transition in your identity lifecycle (active → inactive → expired → deleted → archived). The control only works if engineering and support treat “expired” consistently.

2) Inventory identifiers and where they are used as keys

Build a short inventory (table is fine) of:

• Primary user ID (immutable UUID, internal principal ID)
• Human-readable identifier (username, email)
• External identity mappings (SAML NameID, OIDC subject, SCIM externalId)
• Tenant/customer scoping key(s) For each, record whether it can be reused and whether PII retrieval is possible by referencing it (API search, admin console lookup, logs, exports).

3) Choose your control design: “no reuse” or “reuse with hard isolation”

Most teams implement one of these patterns:

Pattern A: Permanently reserve expired user IDs (recommended for speed)

• Do not allow re-registration with the same user ID once it expires due to inactivity.
• If you must allow the same email to re-register, issue a new internal principal ID and block any linkage to the prior principal’s data without authorization.

Pattern B: Allow reuse, but cryptographically and logically detach PII

• Ensure the new account cannot resolve or inherit the previous account’s PII, even if the string identifier matches.
• This requires strict tenant scoping, immutable internal IDs, and “no shared lookup keys” that return legacy PII.

Whichever design you choose, document it as a control statement tied to Annex A.11.9. (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)

4) Lock down access paths that could “make PII available to other parties”

Engineers often secure the login path but miss secondary paths. Test and control these:

• Admin consoles: searching by username/email should not surface another party’s PII after expiration/reassignment.
• Support tools: “account lookup” workflows must enforce customer/tenant validation before viewing PII.
• APIs: ensure every endpoint that returns user objects enforces tenant scoping and authorization checks.
• Exports and analytics: scheduled reports must not include PII for expired IDs in ways that could be delivered to the wrong tenant/customer contact.
• Logs: if logs contain PII, ensure access is restricted and that log search cannot be used to pull prior-user PII based on a reused identifier.

5) Put the commitment into customer contracts (and flow it down)

Update customer-facing terms (MSA/DPA/service description) to state, in plain language:

• What happens when customer user IDs expire due to inactivity.
• That associated PII will not be made available to other parties without the original customer’s authorization.
• How customers can provide authorization (and what form it must take) if they want reassignment or disclosure.

Flow the same requirement into:

• Internal policies for support/ops handling of expired accounts
• Subprocessor agreements if a subprocessor stores identity/PII and could enable reassignment exposure

This is the “contracts” part of the requirement: you are binding the rule and the permission model to the customer relationship, not leaving it as an undocumented engineering convention. (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)

6) Implement an authorization mechanism (only if you permit exceptions)

If you ever disclose or re-associate PII tied to an expired ID:

• Require explicit customer authorization captured in a durable system (ticketing system with approvals, admin action with reason codes, contract amendment).
• Validate the requester’s authority (customer admin role, contractual signatory, or documented delegated authority).
• Record what was authorized: scope of PII, identity involved, recipient party, time window.

7) Prove it works: test cases and monitoring

Minimum practical tests:

• Attempt to recreate a user with an expired ID and verify no historic PII becomes visible.
• Attempt admin and support lookups using the old identifier and verify access is blocked or correctly scoped.
• Verify deletion/retention jobs do not “orphan” PII in a shared index searchable by reused identifiers.

Add monitoring signals:

• Alerts for attempts to reassign reserved IDs.
• Audit logs for privileged access to expired-account records.

Required evidence and artifacts to retain

Keep these in an audit-ready folder aligned to Annex A.11.9:

Contractual artifacts

• Customer contract language (MSA/DPA/service description) covering expired user IDs and PII non-disclosure without authorization.
• Subprocessor contract clauses (if applicable) addressing the same restriction.

Operational/design artifacts

• Identity lifecycle specification (definitions of inactive/expired; state diagram).
• Data mapping showing where “user ID” links to PII (systems list).
• Design decision record: “no reuse” vs “reuse with isolation,” with rationale.
• Access control matrix for admin/support tools and APIs that can retrieve user PII.

Run-time evidence

• Sample audit logs showing blocked reassignment attempts or controlled exceptions.
• Change records or pull requests implementing ID reservation / isolation logic.
• Test results for the negative test cases above.
• Support runbooks for reactivation/reassignment with authorization capture.

Common exam/audit questions and hangups

• “Define ‘user ID’ in your system. Is it immutable, and is it tenant-scoped?”
• “Show evidence that expired IDs cannot be reassigned, or show the authorization workflow if they can.”
• “Prove that PII tied to an expired ID cannot be retrieved through admin/support tools.”
• “How do you prevent a tenant migration or org merge from exposing PII tied to expired identities?”
• “Where is this commitment stated in customer contracts?”

Expect auditors to probe secondary access paths (support consoles, exports) because that’s where accidental disclosure happens.

Frequent implementation mistakes and how to avoid them

1. Reusing email/username as the primary key.
   Fix: use an immutable internal principal ID; treat email/username as an attribute that can change without re-linking old PII.

2. Tenant scoping applied in the UI but not the API.
   Fix: enforce tenant scoping and authorization in backend services; treat UI checks as non-controls.

3. Support can “search globally” by identifier.
   Fix: require the customer/tenant context first, then allow lookup; log and review privileged searches.

4. Soft-deleted PII remains searchable.
   Fix: remove expired-user PII from indexes used for lookup; segregate archives with tighter access.

5. Authorization captured informally.
   Fix: require a structured approval record tied to a customer authority check; store it with audit logs.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific ISO control. The practical risk is still clear: user ID reuse can create a direct confidentiality breach where one party gains access to another party’s PII. That drives breach notification obligations and contractual claims, and it undermines customer trust during security reviews.

Practical execution plan (30/60/90-day)

First 30 days (Immediate stabilization)

• Appoint an owner across Product/Security/Privacy for the “expired user ID PII non-disclosure” control.
• Document the identity lifecycle definition and locate every way an ID can expire due to inactivity.
• Decide the control pattern: reserve IDs by default, or allow reuse with hard isolation.
• Patch obvious reuse paths (registration, tenant migration scripts, SCIM provisioning edge cases) that could reattach old PII.

By 60 days (Control implementation + contract updates)

• Implement ID reservation or isolation in the identity service and data stores.
• Add guardrails in support/admin tooling: tenant-first lookup, role checks, logging.
• Update customer contracts and customer-facing documentation to match the control, including the authorization mechanism for exceptions.
• Write runbooks for support and incident response: how to handle reactivation requests without disclosing prior PII.

By 90 days (Assurance + audit readiness)

• Build and run test cases; store results and evidence.
• Add monitoring and periodic review of privileged access to expired-user records.
• Validate subprocessor handling where identity/PII is stored externally.
• Prepare an audit packet: contracts, lifecycle spec, design decision, tests, sample logs, and runbooks.

How Daydream helps (practical, non-disruptive)

If you manage third-party risk and customer contract obligations across many cloud services, Daydream can centralize this requirement as a control, map it to evidence requests (contract clauses, lifecycle specs, test results), and track exceptions where customer authorization is required. The operational win is consistency: the same control language and evidence set can be reused across customer security reviews and ISO/IEC 27018 assessments.

Frequently Asked Questions

Does this mean we can never reuse a username or email address?

ISO/IEC 27018 Annex A.11.9 prohibits making the associated PII available to other parties without the original customer’s authorization. The simplest implementation is to block reuse, but you can allow reuse if you can prove the new party cannot access the old party’s PII and you control exceptions with explicit authorization. (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)

What counts as “authorization of the original cloud service customer”?

Treat it as an explicit, auditable approval from an authorized customer representative that permits the specific disclosure or reassignment scenario. Capture who approved, what was approved (scope of PII and recipient), and retain the record with your audit logs. (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)

If an account is deleted, does Annex A.11.9 still matter?

The control is triggered by user IDs expiring due to inactivity, but the underlying risk is identifier reuse causing PII exposure. If deleted identifiers can be reissued or resurrected through backups, migrations, or support actions, keep the same “no disclosure without authorization” rule.

Our platform is multi-tenant. Is tenant isolation enough?

Tenant isolation helps but rarely covers all exposure paths. Auditors will look for admin/support workflows, exports, and logs that bypass normal tenant boundaries; lock those down and test them.

How should we handle support requests to “re-activate” an expired user for a different person?

Treat it as a reassignment risk. Either deny the request and require creation of a new identity, or require explicit customer authorization and ensure the new identity cannot access any prior-user PII.

What evidence is most persuasive in an ISO/IEC 27018 review?

A clear contract clause, a documented identity lifecycle design that prevents reuse or isolates PII, and repeatable test results showing you cannot retrieve prior PII through common interfaces (admin console, API, support tooling). (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)