ServiceNow Cloud Provisioning and Governance: Security and Access Design

Cloud Provisioning and Governance carries requests for production infrastructure, approval decisions and cost data, so its access model has to separate the people who ask, approve, design and provision. This page defines the core roles, applies least privilege and segregation of duties to each, covers approval delegation, audit and data security, and then turns to the access the platform itself needs: integration credentials, how to issue and check them, and the access reviews that catch drift before go-live.

Core Role Definitions

Cloud Requesters submit requests for cloud resources. They should have permission to submit requests and view their own request status, but not view other teams’ requests or approve requests.

Cloud Approvers review requests for business justification, cost appropriateness and compliance alignment. They approve or reject requests but do not provision resources. Approval authority typically depends on request cost or risk level.

Cloud Architects define the approved service catalog and architectural standards. They can modify the catalog and set governance policies but do not make approval decisions on individual requests.

Cloud Administrators provision approved resources, troubleshoot provisioning issues and manage the integration between ServiceNow and cloud platforms. Administrators have technical access to provisioning but should not approve requests.

Least Privilege Principles

Requesters should not see requests from other teams. Configure request list filters so users see only requests they created or are assigned to. Exceptions: managers may see their team members’ requests for oversight.

Approvers should not see request details that could influence their decision unfairly. For example, if cost is not a factor in approval, hide cost information from approvers who might let cost bias their decision. Similarly, hide approver names from requesters to prevent lobbying.

Architects should not have approval authority. Separating design decisions from approval decisions prevents architects from implementing non-standard designs by simply approving them despite policy.

Administrators should not approve requests. Provisioning should only occur after approval, enforcing the separation between approval and execution.

Segregation of Duties

No single person should request and approve cloud resources without a business manager review. This prevents rogue provisioning: unauthorized resources created without approval.

No single person should approve requests and provision resources without oversight. Split this into two roles to prevent unauthorized provisioning of unapproved requests.

No single person should define the service catalog and approve requests to those services. This prevents defining unauthorized services and approving requests for them.

Approval Workflows and Delegation

Define approval workflows that route requests to the right person based on request type, cost or risk. For example, development requests under a cost threshold auto-approve; production requests route to infrastructure leadership.

Allow approval delegation: approvers can delegate authority to a backup during absence. Document delegation to maintain audit trails. Prohibit permanent delegation of approval authority.

Implement multiple-approver workflows for high-risk requests: production resources, security-sensitive workloads or requests exceeding cost thresholds. Multiple approvers reduce risk of single-approver error or bias.

Audit and Compliance

Maintain audit logs of all request activity: submission, approval, rejection, provisioning and deprovisioning. Include timestamps and the user taking each action. Logs should be immutable and retained per policy.

Quarterly access reviews confirm that users still need their assigned roles. Remove users who have moved to different teams or left the organization. Document reviews in case of audit.

Monthly approval audits spot-check requests for appropriateness: were approvals justified, did the requests follow policy and were resources actually provisioned as approved? This identifies approval lapses or policy violations early.

Data Security

Cloud credentials used to provision resources should be stored securely: in a credential vault, never in email or documents. Access to credentials should be limited to cloud administrators and auditable.

Request details containing cost, business justification or approver comments may be sensitive. Limit visibility as appropriate: cost may be hidden from some viewers, business justification hidden from others.

Archive decommissioned request records according to retention policy. Archive should be immutable to prevent retroactive changes to historical decisions.

Designing the access that the platform itself needs

Security reviews of cloud governance often concentrate on the people who request resources. The more consequential access is the access the platform holds: the integration accounts that create resources in each provider, the credentials that let the workflow read billing data, and the roles that let an administrator change an approval rule. A governance platform that can provision across several accounts is, from a security point of view, a privileged system. It should be designed with the same care as the accounts it controls, and reviewed on the same cycle. The first design question is therefore not who may request a resource, but what the platform is allowed to do on its own behalf, and how far that reach extends if its credentials are misused.

The table below proposes access tiers for the platform’s own identities. The principle is that each tier can do one kind of work in one scope, and that moving up a tier requires a separate approval.

A procedure for issuing and checking integration credentials

Integration credentials are a common route into a cloud estate that is not supposed to be reachable, so their issue and handling should be deliberate.

1. Create one integration identity per provider account or subscription, rather than one shared identity for everything. A compromise then stays inside a single scope.
2. Grant the identity only the actions in its tier, and write the granted actions into the access record so a later reviewer does not have to infer them.
3. Store the credential in a managed secrets store with access restricted to the integration component. It should not appear in workflow configuration, in exported records or in a shared document.
4. Rotate the credential on a fixed schedule and test that the integration still works immediately after rotation, because a rotation that breaks delivery is often reversed under pressure.
5. Record every use of the identity in the audit trail and alert on use outside the expected window or from an unexpected network source.

Designing for least privilege without blocking delivery

Narrow permissions are easy to specify and often hard to get right. A delivery identity that is limited to creating compute instances can fail when the same catalog item also needs a network interface, a disk and a tag set, and the failure may appear only in production. The practical method is to derive the permissions from a test run of each catalog item in a non-production account, listing every action the provider logs, and then removing any action the item does not need. That produces a permission set that is smaller than the default and that actually works.

Review the derived set whenever a catalog item changes. A new option on a resource type often needs a new permission, and the change should be visible in the access record before it reaches production.

Access review that catches drift

People and identities both accumulate access. A review should look at three things: whether each granted tier still matches the work being done, whether any identity has been unused for a long period, and whether any break-glass access was used without a matching incident or change record. The last check is often the most revealing. Emergency access that is used for convenience rather than emergencies is a common sign that the normal path is too slow, and that is a design problem to fix rather than an access problem to police.

Keep the review evidence in the records the audit team reads. A review that exists only as a meeting note is hard to defend later.

Where the design breaks down

• A single administrator holds rule administration and delivery rights, so a rule can be changed and the change executed by the same person without a second check.
• Credentials were copied into a troubleshooting note during an incident and never removed. The rotation schedule then no longer protects the copy.
• The read-only inventory identity was granted broad rights during a migration and kept them afterwards, so the inventory can read data it was never meant to see.

Questions a security lead should ask before go-live

What happens if an integration credential is exposed tomorrow?

Walk through the answer. The exposed identity should reach only one account, its actions should be limited to its tier, its use should be alerted, and rotation should be possible without taking delivery down for every team. If any of those answers is no, fix the design before go-live.

Should the platform be allowed to create identities in the provider?

Generally no. An identity that can create other identities can extend its own reach, and that power is hard to review. Identity creation should be a manual, approved step with its own record.

How do we prove the access model works, not just that it exists?

Attempt the actions a tier should not allow, from each identity, and record that they are refused. A negative test of this kind is worth more than a diagram.

Does the audit trail need to cover the reads as well as the writes?

For billing data and inventory of sensitive accounts, yes. Read access to a cost export or a resource list can reveal as much about the estate as a write, and the trail should show who looked.

Next step

For how the platform’s own roles get checked, the access controls review post is a companion read. To see where those credentials sit in the flow of a request, go back to the integration patterns.