User registration and de-registration

ISO/IEC 27018 Clause 9.2.1 requires a formal, auditable process to register users (create identities and grant access) and de-register users (remove access) so access to PII is granted only when authorized and is removed promptly when authorization ends. Operationally, you need defined workflows, clear approvers, and strong evidence that access changes track HR and role changes. ¹

Key takeaways:

• Treat “user lifecycle” as a controlled workflow: request, approve, provision, review, revoke, and verify removal.
• Your highest-risk gap is delayed offboarding or role-change access cleanup for accounts with PII access.
• Evidence matters: auditors will ask for tickets, approvals, timestamps, and technical proof of deprovisioning.

“User registration and de-registration” sounds basic until you apply it to real cloud delivery: multiple identity providers, privileged roles, shared support access, third-party operators, and customer-administered tenants. ISO/IEC 27018 Clause 9.2.1 focuses that complexity on one outcome: access rights must be assigned through a formal process, and access to PII must be promptly removed when no longer authorized. ¹

For a CCO, compliance officer, or GRC lead, the fastest path to operationalizing this requirement is to define a single control objective (“only authorized users can access PII, and access is removed immediately when authorization ends”), then build lifecycle workflows that are provable. Your process must cover employee and contractor joiners/movers/leavers, service accounts, and privileged access. It also must work across systems that touch PII, including production environments, support tooling, analytics platforms, and administrative consoles. The standard is short; the implementation work is not. This page breaks it down into execution steps, required artifacts, audit-ready evidence, and a practical plan.

Regulatory text

ISO/IEC 27018:2019 Clause 9.2.1 states: “A formal user registration and de-registration process shall be implemented to enable assignment of access rights, with specific provisions to ensure that access to PII is promptly removed when no longer authorized.” ¹

Operator interpretation (what you must do):

• Implement a defined, repeatable workflow for creating, changing, and disabling user access.
• Ensure that PII access is tied to authorization (role, job duties, contract scope) and not granted ad hoc.
• Ensure that when authorization ends (termination, contract end, role change, access no longer needed), PII access is removed promptly, and you can prove it happened. ¹

Plain-English requirement: what “user registration and de-registration” means

This requirement is user lifecycle governance for PII:

• Registration: you create a unique identity, verify who the user is, assign the right roles/groups, and document approvals.
• De-registration: you remove access rights and disable accounts so the user cannot access PII after their authorization ends.
• Formal: the process is documented, consistently followed, and produces records. “We usually email IT” fails because it is not controlled or auditable. ¹

Who it applies to (entity and operational context)

Applies to: Cloud Service Providers acting as PII processors under ISO/IEC 27018. ¹

Operational scope you should assume (practical):

• Workforce identities: employees, contractors, interns, temporary staff.
• Third parties with access to your systems (managed service providers, support vendors, incident response retainers).
• Privileged access: cloud console admins, database admins, break-glass accounts.
• Non-human identities: service accounts, API keys, CI/CD identities (these often end up with broad data access unless controlled).
• Systems in scope: IdP, SSO, IAM, ticketing, HRIS, endpoint management, production and non-production environments, support platforms, logging/monitoring tools that may contain PII.

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

1) Define your control objective and boundaries

Write a short control statement you can test:

• “All access to systems that store, process, or transmit PII is granted through approved requests tied to a role, and access is removed promptly when no longer authorized.” ¹

Then define:

• In-scope systems (where PII exists or where access can reach PII).
• In-scope roles (support, SRE, engineering, data, security).
• Access types (interactive login, privileged roles, application tokens).

2) Build a formal registration workflow (joiner provisioning)

Minimum workflow components:

1. Requestor submits access request (ideally in ticketing) with business justification and required systems/roles.
2. Manager (or system owner) approves access and confirms it aligns with job duties.
3. Security/IAM validates segregation of duties and ensures least-privilege roles exist.
4. Provisioning happens through IdP/IAM groups (avoid manual one-off grants).
5. User activation includes identity proofing aligned to your HR/contractor onboarding process.
6. Recordkeeping: ticket, approvals, roles granted, provisioning timestamps, and user identifier.

Practical tip: If your “registration” is just account creation but roles are granted informally in Slack, your control fails on “formal assignment of access rights.” ¹

3) Build a formal change workflow (mover events)

Most PII exposure comes from role changes that do not remove legacy access.

Implement:

• A trigger from HR/manager change events into IAM reviews.
• A rule: role change requires re-authorization of PII-relevant access.
• A “remove then add” pattern for high-risk roles (especially privileged groups).

Evidence to capture: prior roles, new roles, who approved, and what was removed.

4) Build a formal de-registration workflow (leaver/offboarding)

De-registration must be deterministic and fast:

1. Trigger: HR termination, contract end date, or manager offboarding request.
2. Disable identity in primary IdP first (cuts off SSO).
3. Revoke privileged access (PAM roles, admin groups, break-glass access where applicable).
4. Revoke direct application access not controlled by IdP (local accounts, database users, SaaS native users).
5. Rotate secrets the user knew: shared credentials, team API keys, emergency passwords (where used).
6. Verify removal via system reports or logs: account disabled, tokens revoked, group memberships removed.

ISO/IEC 27018 adds a specific emphasis: de-registration must ensure PII access is promptly removed when authorization ends. Your workflow should explicitly label PII-bearing systems as “priority offboarding.” ¹

5) Control non-human identities (service accounts, API keys)

Treat service identities as “users” for this control:

• Register them with an owner, purpose, and allowed scope.
• Approve creation and permissions.
• De-register by disabling the account and revoking keys when the app/service is retired or ownership changes.

Common audit failure: “nobody owns this key” or “we can’t tell what systems this token touches.”

6) Add verification and monitoring (prove it works)

Your process needs a feedback loop:

• Periodic reconciliation: HR roster vs. IdP active users; contractor list vs. active accounts; privileged group membership vs. authorized list.
• Alerting for dormant accounts with privileged roles or PII access paths.
• Exception handling with time-bounded approval and compensating controls.

7) Operationalize through ownership and RACI

Assign named owners:

• Control owner (GRC/IAM lead): policy, evidence, audit response.
• Process operators (IT/IAM): provisioning/deprovisioning execution.
• Approvers (managers/system owners): authorization decisions.
• Security: oversight for privileged access and PII systems.

Required evidence and artifacts to retain

Auditors will look for both design evidence and operating evidence.

Design artifacts

• Access control policy and user lifecycle procedure referencing registration/de-registration.
• System inventory marking which systems contain PII or can access PII.
• Role and group definitions for PII access (least privilege mapping).
• RACI for access approvals and offboarding execution. ¹

Operating evidence (samples)

• Access request tickets showing requester, justification, approval, and roles granted.
• Provisioning logs (IdP/IAM) showing group membership changes.
• Offboarding tickets showing termination trigger and completion.
• Account disablement evidence (screenshots or exported reports from IdP/SaaS/IAM).
• Privileged access assignment and removal records.
• Exception approvals (if any) and proof exceptions ended.

Common exam/audit questions and hangups

Expect questions like:

• “Show me a recent hire: where is the request, approval, and access granted?”
• “Show me a termination: when did HR notify you, when was access removed, and how do you know?”
• “How do you handle role changes?”
• “List all users with access to PII systems; show authorization for each.”
• “How do you manage third-party and contractor accounts?”
• “How do you control service accounts and API keys?” ¹

Hangups that stall audits:

• No consistent joiner/mover/leaver trigger.
• Local accounts in apps outside SSO.
• Privileged access managed “in the cloud console” with no ticket trail.
• Inability to prove prompt removal for PII paths.

Frequent implementation mistakes (and how to avoid them)

1. Offboarding only disables email
   Fix: make the IdP disable step the first action; then enumerate PII systems with direct access paths.

2. Approvals are implicit (manager “told IT”)
   Fix: require an approval artifact (ticket approval, workflow approval) for any PII access grant.

3. Role change doesn’t remove access
   Fix: require re-authorization and removal of legacy groups during mover events.

4. Shared accounts for support
   Fix: require unique user IDs; use audited elevation for admin tasks.

5. Service accounts are unmanaged
   Fix: inventory service identities, assign ownership, and enforce de-registration on application retirement.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. From a risk standpoint, weak de-registration creates a predictable failure mode: former employees, contractors, or role-changed users retain access to PII longer than intended, and that access is hard to detect during an incident. ISO/IEC 27018 elevates this risk by explicitly requiring prompt removal of access to PII when authorization ends. ¹

A practical 30/60/90-day execution plan

Because no timeline metrics are provided in the cited sources, treat these as planning phases, not compliance deadlines.

First phase: establish control design and scope

• Confirm in-scope PII systems and access paths (SSO apps, direct logins, cloud IAM roles, databases, support tools).
• Publish the written registration/de-registration procedure and RACI.
• Standardize access request fields: system, role, justification, approver, duration (if temporary).
• Identify the authoritative sources for joiner/mover/leaver triggers (HRIS for employees, contract management for contractors).

Second phase: implement workflows and close the biggest gaps

• Route all PII-system access through ticketing + approval.
• Centralize access via IdP groups where possible; document exceptions.
• Implement an offboarding checklist specifically for PII systems, including privileged roles and non-SSO apps.
• Stand up a service account register (owner, purpose, permissions, rotation/revocation process).

Third phase: verify, monitor, and harden for audit

• Run reconciliations between HR/contractor rosters and active accounts.
• Sample test: pick recent joiners and leavers and confirm evidence exists end-to-end.
• Add monitoring for privileged group membership changes and unusual reactivations.
• Package an audit binder: policy, procedure, system inventory, and evidence samples mapped to ISO/IEC 27018 Clause 9.2.1. ¹

Tooling note (where Daydream fits)

If you struggle to collect consistent evidence across identity, ticketing, and cloud platforms, Daydream can act as the system of record for your control narrative and evidence requests. Use it to standardize what “good evidence” looks like for registration and de-registration, then track samples across teams without chasing screenshots in chat threads.

Frequently Asked Questions

Does ISO/IEC 27018 require SSO for all PII systems?

The clause requires a formal process for assigning and removing access, with prompt removal for PII access. SSO helps, but the requirement can be met with other controlled mechanisms if you can prove approvals and deprovisioning. ¹

What counts as “promptly removed” access?

ISO/IEC 27018 Clause 9.2.1 requires prompt removal but does not specify a fixed time value in the provided text. Define an internal service level by risk tier (PII and privileged first), then prove you meet it consistently. ¹

Do contractors and third-party support staff fall under “users”?

Yes, treat any identity that can access PII as a user for lifecycle purposes, including third-party personnel. Your process should cover creation, approval, and de-registration at contract end or access withdrawal. ¹

How do we handle access for emergency incident response?

Pre-define an emergency access path with approvals, logging, and fast revocation after use. Capture who authorized the access, what was granted, and proof of removal once the incident ends. ¹

Are service accounts in scope for registration and de-registration?

If a service account can reach PII, manage it through a formal creation and removal workflow: named owner, documented purpose, approved permissions, and revocation when no longer needed. Auditors commonly ask for ownership and proof of key/token revocation. ¹

What evidence is “enough” for an auditor?

Provide a traceable chain: request, approval, provisioning action, and technical proof of access removal for leavers and role changes. Focus samples on PII systems and privileged roles because that is where the clause places special weight. ¹

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