User access provisioning

ISO/IEC 27017 Clause 9.2.2 requires a formal, repeatable user access provisioning process that assigns and revokes access rights for all user types across all cloud systems and services. To operationalize it, you need documented workflows, role/entitlement standards, approvals, technical enforcement in IAM, and retained evidence that every access change was authorized, implemented, and removed on time. ¹

Key takeaways:

• Scope is broad: all user types and all cloud systems/services, not just employees or production. ¹
• “Formal process” means defined triggers, approvals, implementation steps, and deprovisioning, with audit-ready evidence. ¹
• Auditors test actual tickets/logs and joiner-mover-leaver outcomes, not policy language. ¹

“User access provisioning” is the control that turns identity and access management from a set of tools into an accountable business process. ISO/IEC 27017:2015 Clause 9.2.2 is direct: you must implement a formal process to assign or revoke access rights for all user types to all cloud systems and services. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path to a passable implementation is to define (1) who can request access, (2) who must approve it, (3) how access is technically provisioned, (4) how quickly access is removed when it should be removed, and (5) what evidence proves each step happened. The goal is consistent outcomes across the user lifecycle: joiners get the right access, movers get changes controlled, and leavers lose access promptly, including third parties and service accounts.

This page gives you requirement-level guidance you can turn into a working procedure, ticket workflow, and evidence package without over-engineering.

Regulatory text

ISO/IEC 27017:2015 Clause 9.2.2 (User access provisioning) states: “A formal user access provisioning process shall be implemented to assign or revoke access rights for all user types to all cloud systems and services.” ¹

What the operator must do: implement a documented, repeatable process (not ad hoc admin actions) that covers both provisioning and deprovisioning, applies to every category of user, and applies to every cloud system/service in scope. The standard’s language forces you to address gaps that commonly slip through: contractors, support vendors, break-glass accounts, CI/CD identities, APIs, and SaaS admins. ¹

Plain-English interpretation (what “formal” means in practice)

A “formal user access provisioning process” is a controlled workflow with:

• Defined triggers (hire, role change, termination, vendor onboarding/offboarding, project start/end).
• Standard access patterns (roles/groups, not one-off entitlements).
• Approval rules (business owner approval; security approval for sensitive roles).
• Technical implementation steps (IAM group assignment, SSO role mapping, PAM checkout, key issuance).
• Verification (confirm access matches the request and is effective).
• Revocation (remove access when no longer needed, including indirect access through groups, tokens, and keys).
• Evidence (tickets, approvals, logs, access lists) sufficient to prove the above happened. ¹

Who it applies to (entity + operational context)

Entity types in scope:

• Cloud Service Providers (CSPs): you operate cloud services and must control access to the systems that deliver them (production, support tooling, management plane). ¹
• Cloud Service Customers: you consume cloud services and must control access to your tenant(s), subscriptions, projects, SaaS instances, and cloud-hosted data. ¹

Operational contexts auditors will include:

• Workforce identities (employees, interns, temps)
• Third parties (contractors, consultants, managed service providers, auditors)
• Privileged admins (cloud console admins, SaaS super-admins)
• Non-human identities (service accounts, API tokens, CI/CD runners)
• Emergency access (break-glass) and support access paths (vendor support portals, just-in-time access)

If you exclude any of these categories, you need a written scope rationale and compensating controls; otherwise you are contradicting “all user types” and “all cloud systems and services.” ¹

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

1) Define your access model (so provisioning has a standard to follow)

Create and publish:

• System inventory (cloud systems/services): list every cloud environment and SaaS app where access grants meaningful capability (data access, admin actions, billing, key management).
• User type taxonomy: workforce, third party, privileged, non-human, break-glass.
• Role catalog: roles mapped to job functions (e.g., “Support Agent,” “Billing Admin,” “Cloud ReadOnly,” “Prod Deployer”) with allowed entitlements/groups.

Operator tip: make “group-based access via SSO” the default, and require exceptions to be time-bound and explicitly approved.

2) Build the provisioning workflow (request → approve → implement → verify)

Document a procedure and implement it in your ticketing/ITSM tool:

1. Request intake: requester identifies the user, system, requested role, and business justification.
2. Identity proofing / uniqueness checks: confirm the identity exists in the authoritative directory (HRIS for employees; vendor onboarding record for third parties).
3. Approvals:
   • Business owner approval (system owner or data owner).
   • Security/IAM approval for privileged roles, sensitive datasets, or unusual access patterns.
4. Implementation: IAM admin or automation assigns roles/groups, issues credentials, and configures MFA/SSO as required.
5. Verification: confirm the user can access only what was approved (spot-check group membership and effective permissions).
6. Recordkeeping: close the ticket with evidence and implementation notes.

This satisfies the “formal” requirement because every grant is tied to a traceable request and approval, and it is executed consistently across systems. ¹

3) Build the deprovisioning workflow (the part auditors focus on)

Define revocation triggers and owners:

• Joiner/Mover/Leaver events: HR-driven for employees; contract end-date driven for third parties.
• Role changes: remove prior access before or at the same time as adding new access.
• Temporary access expiry: auto-revoke when the approved window ends.

Operational requirements to implement:

• Single “source of truth” for offboarding: HRIS and vendor management records should drive disablement in the identity provider.
• Cascading removal: disabling in IdP must remove access in downstream SaaS and cloud consoles (SSO-integrated apps), and you still need a plan for non-SSO systems.
• Non-human identities: rotate/disable API tokens, remove keys, disable service accounts when owners change or workloads retire.

Deprovisioning failures create persistent unauthorized access, which is exactly what Clause 9.2.2 is written to prevent. ¹

4) Cover special cases without breaking the process

Create playbooks for:

• Emergency / break-glass: controlled storage of credentials, named approvers, post-use review, and documented activation/deactivation.
• Privileged access: require stronger approvals, stricter logging expectations, and narrower roles.
• Third-party access: require a sponsoring internal owner, contract linkage, and offboarding tied to the third party’s end date.
• Service accounts: require an owning team, documented purpose, credential handling rules, and periodic ownership validation.

5) Make it testable (auditors test outcomes)

Define control checks you can run on demand:

• List of users with privileged roles by system.
• List of active third-party users and their sponsors.
• List of dormant accounts and accounts without recent authentication (where the system can report it).
• Orphaned service accounts without owners.

If you want this to run cleanly across many systems, Daydream can help by centralizing the evidence pack (tickets, approvals, IAM exports, and owner attestations) so audits don’t become a spreadsheet scramble.

Required evidence and artifacts to retain

Keep artifacts that prove the process exists and was followed:

Process and standards

• Access provisioning and deprovisioning procedure (approved, versioned).
• Role/entitlement catalog ¹.
• RACI for request/approve/provision/revoke responsibilities.

Execution evidence (sampled by auditors)

• Access request tickets showing requester, user, system, role, justification.
• Approval records (workflow approvals, email approvals captured into the ticket).
• Implementation proof (IAM group membership change logs, admin action logs, screenshots where logs are unavailable).
• Deprovisioning records (disablement tickets, IdP logs, app-level removal evidence for non-SSO apps).
• Third-party onboarding/offboarding records linked to access grants.

Ongoing monitoring

• Periodic access review outputs (where you do them) mapped back to provisioning records.
• Exception register for any manual or non-standard access paths.

Common exam/audit questions and hangups

Expect these lines of inquiry:

• “Show me the documented process for granting and revoking access to cloud services.” ¹
• “How do you ensure third parties are removed when the engagement ends?”
• “How do you handle service accounts and API tokens?”
• “Who approves privileged access, and how do you prove approvals occurred before access was granted?”
• “Pick a terminated user. Prove access was revoked across SSO apps and any non-SSO systems.”

Hangups that slow audits:

• No authoritative system inventory, so “all cloud systems and services” is unprovable. ¹
• Approvals occur in chat/email but aren’t retained.
• Deprovisioning is assumed because the laptop was returned.

Frequent implementation mistakes (and how to avoid them)

1. Relying on policy text without workflow evidence. Fix: enforce request/approval in a ticketing system and attach logs.
2. Ignoring non-human identities. Fix: require owner, purpose, and revocation triggers for service accounts and tokens.
3. SSO coverage gaps. Fix: maintain a list of non-SSO systems and document app-level deprovisioning steps.
4. Overly granular entitlements. Fix: push access through roles/groups, with limited exceptions.
5. Third-party sprawl without sponsors. Fix: require an internal sponsor who re-approves extensions and owns offboarding.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the supplied sources, so you should treat “enforcement” here as audit failure and incident risk rather than a specific regulator penalty narrative.

Practically, weak provisioning creates two high-frequency failure modes:

• Unauthorized access persists after job change or termination because revocation is incomplete.
• Excess privilege accumulates via ad hoc grants that never get removed.

Both raise breach likelihood and complicate incident containment because you cannot quickly determine who had access and why. Clause 9.2.2 targets that operational reality by requiring a formal, end-to-end lifecycle process. ¹

Practical 30/60/90-day execution plan

No fixed timelines are required by the cited clause text, but a staged rollout is workable.

Next 30 days (Immediate)

• Draft and approve the access provisioning/deprovisioning procedure mapped to joiner/mover/leaver events. ¹
• Build a cloud systems/services access inventory and name system owners.
• Stand up a standard access request ticket with mandatory fields and approval routing.
• Identify the highest-risk roles (cloud admin, SaaS super-admin) and force ticket-based approvals for all changes.

Days 31–60 (Near-term)

• Publish role catalogs for top systems and migrate ad hoc entitlements into role/group patterns.
• Integrate HR/offboarding triggers to disable identities in the IdP and confirm downstream propagation for SSO apps.
• Create playbooks for third-party access, service accounts, and break-glass access.
• Start an evidence pack routine: export IAM change logs and attach them to a sample of tickets each cycle.

Days 61–90 (Operationalize)

• Expand coverage to remaining cloud systems/services, including non-SSO apps with documented removal steps.
• Implement monitoring checks (privileged users list, third-party active list, orphaned accounts list) and assign owners to review findings.
• Run an internal “mock audit” sample: pick access grants, role changes, and leavers, then prove request→approval→implementation→revocation with artifacts.
• If you need to scale evidence collection across many tools, configure Daydream to gather and normalize the audit trail (tickets, approvals, exports, and attestations) into a single review workflow.

Frequently Asked Questions

Does ISO 27017 require a specific tool for user access provisioning?

No. The requirement is a “formal process” that assigns and revokes access across all user types and cloud systems/services. You can meet it with ITSM + IAM + documented procedures if the workflow is consistent and evidenced. ¹

What counts as “all user types” in practice?

Treat it as inclusive: employees, contractors, third parties, privileged admins, and non-human identities like service accounts and API tokens. If a category exists in your environment, auditors expect it in scope. ¹

If we disable a user in SSO, is deprovisioning complete?

Only for systems that fully rely on SSO for authentication and authorization. You still need a documented approach for non-SSO systems, local accounts, long-lived API keys, and any out-of-band admin access paths.

How do we handle emergency access without violating the “formal” process?

Write a break-glass procedure with named approvers, controlled credential storage, logging expectations, and a post-event review that gets retained with the access record. Emergency does not mean undocumented.

What evidence is most persuasive to auditors?

A closed-loop trail: ticket request, recorded approval, provisioning logs showing the exact change, and deprovisioning proof when access ends. Auditors typically sample multiple user types and systems, so keep evidence consistent across platforms. ¹

We have many SaaS tools. How do we prove coverage across “all cloud systems and services”?

Maintain an access-controlled inventory with owners and the provisioning/deprovisioning method for each system (SSO, SCIM, manual). If you can’t automate evidence, standardize exports/screenshots and store them in a repeatable audit folder structure.

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