ServiceNow Cloud Provisioning and Governance: Roles, Responsibilities and RACI

Key Roles in Cloud Provisioning and Governance

Cloud provisioning involves multiple roles: requestors (business teams asking for cloud resources), approvers (governance bodies reviewing requests for compliance and cost), provisioning teams (infrastructure or cloud ops deploying resources), and auditors (ensuring deployed resources comply with policies). Each role has distinct responsibilities and decision authority.

Requestors describe their cloud need: what type of resource (VM, database, container), what workload it will run, what data it will handle, and when it is needed. Approvers assess the request against organizational policies: is the requested resource type approved, does it meet security and compliance requirements, does the business unit have remaining budget? Provisioning teams deploy resources and configure access. Auditors verify that deployed resources match approved configurations and continue to comply as they evolve.

In smaller organizations, one person might fill multiple roles; in larger organizations, each role is distinct. Regardless of organization size, clarity about who holds each role and what authority they have prevents bottlenecks and delays.

RACI Table for Cloud Provisioning Decisions

A RACI table clarifies decision-making across roles: Responsible (who does the work), Accountable (who is ultimately responsible for the decision), Consulted (who provides input), Informed (who needs to know the outcome). Here is a typical RACI for cloud provisioning:

Escalation Paths and Conflict Resolution

Define escalation paths for when decisions are unclear or roles conflict. For example, if a cloud resource request is denied but the requestor believes it is necessary, what is the escalation path? Typically, escalation goes to the next management level or to a steering committee. Define these paths explicitly and communicate them so stakeholders know what to do if a decision affects them.

Also define conflict resolution: if Approvers and Security recommend different actions, who decides? Usually, security takes precedence in compliance-related decisions, but this should be documented. If cost and availability conflict, business priorities might take precedence, but again, document the decision rule.

Ownership and Accountability Throughout Resource Lifecycle

Ownership of a cloud resource often changes as it moves from approval to deployment to operations. Initially, the requestor and approver drive decisions; during provisioning, the provisioning team owns it; during operation, responsibility transfers to the business team or operations. Clarity about who is responsible at each phase prevents accountability gaps.

In ServiceNow, use tags or custom fields to track ownership throughout the resource lifecycle. A cloud resource record should show: original requestor, approver, provisioning owner, current operational owner, and scheduled retirement date. When ownership changes, update the record so audit trails are complete.

Governance Checkpoints and Review Gates

Define governance checkpoints throughout the resource lifecycle: initial approval gate (request received), pre-provisioning gate (final compliance check), post-provisioning gate (verify deployed resource matches approved specification), and periodic review gates (ongoing compliance audits).

Each gate has specific criteria: initial approval checks policy and budget; pre-provisioning checks that nothing has changed since approval; post-provisioning verifies that what was deployed matches what was approved; periodic reviews ensure the resource is still needed and compliant. This gating prevents the scenario where resources are provisioned, nobody verifies they match requirements, and they drift over time.

Separating the four jobs that one person should not hold alone

In many cloud governance programs, the same person ends up requesting a resource, approving it, building it and later deciding that it is no longer needed. That is efficient in a small team and dangerous in a large one. The four jobs are request, approve, fulfil and retire, and the governance design works best when no single role holds two of them for the same resource. A requester who can approve their own request is not a control, and a platform engineer who can both deploy and sign off the deployment has nobody checking the work. Start the role design by drawing these four boundaries, and then fill in the detail.

The table below maps those jobs onto the roles that most organizations need, with the rule that keeps each pair apart. It is a pattern to adapt, and the names of the roles will differ from one organization to the next.

Writing a RACI that names one accountable role per activity

A RACI chart is only useful when each activity has exactly one role marked accountable. Two accountable roles means that when the activity goes wrong, each believes the other was responsible. The procedure below produces a chart that survives the first incident.

1. List the activities in the lifecycle of a resource, from first request to retirement, and keep them to the verbs people actually use in tickets.
2. For each activity, mark one role as accountable. Resist the urge to share accountability; if two roles seem necessary, split the activity into two.
3. Mark one or more roles as responsible for doing the work, and a small number as consulted before the work is done.
4. Name the roles that must be informed when the activity completes, such as the cost owner after a resource is provisioned.
5. Check the chart against the separation table. Any activity where one role is both requester and approver, or approver and fulfiller, needs a second approver or a different owner.

Where the chart fails in practice

The chart often fails at the edges between roles rather than inside them. Retirement is a common gap. Everyone agrees who creates a resource and who approves it, but nobody is clearly accountable for deciding it is no longer needed, so resources persist. A second gap is the exception path. When a request falls outside the catalog, the chart may name the governance approver, but nobody has said who writes the justification or who checks that it was recorded. A third gap appears when a role changes. The person who was the accountable owner of a service moves team, and their successor inherits the resources without the responsibilities being transferred.

Review the chart when roles change, and treat a departure as a trigger for an ownership review of every resource the leaver owned.

Keeping the chart consistent with the tools

A RACI chart and the platform’s assignment rules must match, or the chart describes a process that the system does not enforce. Check that every accountable role maps to a group or a rule in the platform, and that the groups in the platform have a current member. Empty groups are a common cause of requests that wait indefinitely, because the approval step routes to a group with nobody in it. The check is simple to run and worth scheduling.

When the separation rule should bend

Very small teams cannot always separate every role, and forcing a strict split can create an approval queue that everyone routes around. In that case, accept the overlap but make it visible: require a second person to review the request after the fact, and record the overlap in the monthly governance review. An overlap that is recorded and reviewed is much easier to defend than one that is never mentioned.

Questions to settle with the people named in the chart

Who approves a request when the approver is on leave?

Name a delegate in the chart, with the same authority and the same separation rules. A delegate who lacks the authority to approve a given request should be recorded as a gap, not quietly given the rights.

Can a platform operator reject a request they think is unsafe?

Yes, and the rejection should go to the approver with the reason. Operators should not be able to cancel an approved request on their own judgment, because that turns the fulfilment role into a second approval gate with no record.

Who is responsible for a resource that was provisioned by an automated rule?

The owner recorded on the request, not the rule. The rule is a mechanism. The accountable person is whoever the request named, and the chart should say so explicitly so the automated path does not dilute ownership.

How often should the chart be reviewed?

When the organization changes, when a provider is added and whenever an incident shows that a responsibility was unclear. A periodic review is also worth doing, but the triggers matter more than the calendar.

Next step

For the forum that decides exceptions, see the governance model. The same separation logic applies to people who already hold access, which the access recertification post addresses.