ISO/IEC 27017 FAQ Cloud Admin Access

Start with one named service, service tier, region, administrative interface, and provider chain. List customer consoles, provider support access, APIs, hypervisor or orchestration functions where exposed, emergency accounts, and automated identities. For each capability, record whether the customer, provider, or both can use it and whether it can view data, change security, create or delete resources, terminate service, or affect recovery.

For customer cloud administrators, clause 9.2.3 says the customer should use authentication techniques sufficient for the identified risks and the provider should supply suitable capabilities. Multi-factor authentication is the standard's example, not an unconditional rule for every administrative action. The customer should also ensure that access to cloud functions and data can be restricted under its access-control policy. Provider utilities capable of bypassing normal operating or security procedures should be limited to authorized personnel and reviewed and audited regularly.

Apply two additional branches. If the provider delegates an elevated action to the customer, clause 12.4.3 says the operation and its performance should be logged, and the customer should decide whether provider logging is adequate or add its own. If failure of a customer administrative operation could cause unrecoverable damage, CLD.12.1.5 says the customer should document the procedure and specify supervisor monitoring. Examples are installing, changing, or deleting virtual servers, networks, or storage; terminating cloud use; and backup or restoration.

Keep the administrative-interface inventory, role design, approval, identity-provider settings, authentication configuration, current entitlement export, provider-support terms, emergency-account record, privileged-operation logs, critical-operation procedure, supervisor record, and completed review. Provider evidence should cover the contracted service and provider access; customer evidence should show the customer's own grants and settings.

Sample a new grant, role change, leaver, emergency use, delegated privileged action, and destructive or recovery operation where each exists. Match every human identity to a person and every workload identity to a controlled process. Record approved duties, authentication, grant and expiry, last use, log event, supervisor where required, reviewer, exception, and removal or revalidation.

ISO/IEC 27017 allocates actions between customer and provider but does not assign the customer's internal job titles. As a practical governance model, the manager accountable for the service can approve customer administrator roles, the platform or identity owner can provision them, and someone independent of the access holder can review them where practical.

Supplier management and security should assess provider-administrator commitments and assurance for the contracted service. The authorized risk owner, not the access holder or provisioner, should decide whether an unresolved exception is acceptable.

ISO/IEC 27017:2015 does not set a fixed access-review interval. Set one from risk, applicable requirements, and the agreement, then review whenever a person's role or employment changes, a new administrative interface or identity type appears, provider support access changes, or an incident exposes misuse or weak monitoring.

Immediately review emergency access after use and revoke temporary privileges when the approved period ends. Record the decision, removal, unresolved exception, and next owner.