ServiceNow Cloud Provisioning and Governance Requirements Workshop Questions

The questions on this page are the prompts a facilitator uses to settle how cloud resources get requested, approved, costed and governed before anyone configures Cloud Provisioning. The answers from finance, security, platform, application and service management groups become the requirements document for the build.

Current State Discovery Questions

These questions explore your existing cloud landscape and governance practices:

• How many cloud subscriptions does your organisation have? Which providers (AWS, Azure, Google Cloud, Salesforce, etc.)? Who manages each subscription?
• What cloud resources exist today (compute, storage, databases, SaaS applications)? Are they documented anywhere?
• Who can provision cloud resources today? Is there a formal approval process, or can anyone request resources?
• How are cloud costs tracked and allocated? Are costs visible to teams that provision resources, or are they hidden?
• Have there been incidents involving cloud resources (security, compliance, cost surprises)? What controls failed?
• What policies or standards exist today around cloud usage? Are they documented or informal?

Governance Model Questions

These questions shape how Cloud Provisioning will be governed:

• Who should own cloud governance (centralised IT team, distributed teams, steering committee)? What decision rights does that owner have?
• What types of cloud resources should teams be allowed to provision (compute, storage, networking, managed services, third-party SaaS)? What should be restricted?
• Which resources require approval before provisioning, and who should approve (IT, finance, security, business owner)? Are approval requirements different by resource type or by cost?
• How should costs be charged back to teams (chargeback, showback, IT-funded central account)? Will cost visibility influence team behaviour?
• What naming conventions, tagging standards, and documentation requirements will you enforce? How will you validate compliance?
• Do you have regulatory requirements that affect cloud usage (data residency, encryption, audit trails, access controls)?

Policy and Compliance Questions

These questions define specific governance policies:

• What is the maximum cost of a single cloud resource a team can provision without management approval? What is the threshold for IT and finance review?
• What is the maximum total monthly cloud spending per team? What happens when a team exceeds this limit?
• Which cloud regions are allowed (for example, data must stay within the country)? Are multi-region deployments allowed?
• What encryption and access control standards apply to cloud data? Who can access cloud resources, and how are identities managed?
• How long can a cloud resource run without active use before it is decommissioned? Who decides whether to continue or shut down idle resources?
• What audit evidence must be retained for cloud resources (deployment logs, access logs, change records)?

Operational Workflow Questions

These questions define how teams will request and receive cloud resources:

• What is the expected turnaround time for a cloud provisioning request (hours, days)? What is the SLA?
• Will teams provision resources themselves (self-service) or request them from a central team? What complexity level determines which path?
• How will teams describe what they need when they submit a request? What information is required (technical specs, business justification, cost estimate, security requirements)?
• How will you validate that a provisioned resource meets the requested specifications? Who tests the resource before handing it to the requesting team?
• How will teams know that their resource is being decommissioned or changed? What notice period will you provide?

Cost and Financial Questions

These questions align Cloud Provisioning with financial management:

• How frequently should cost data be imported into ServiceNow (daily, weekly, monthly)? How current does cost visibility need to be?
• If you use chargeback, how will you calculate the cost per team? Will you use actual cloud bills, or will you allocate on a different basis?
• What happens if actual cloud usage exceeds the approved budget? Who is notified, and what actions are taken?
• How will you track and report on cloud spending trends (are costs increasing, which teams are top spenders, which resource types cost the most)?
• Will you use reserved instances or commitment discounts (for example, AWS reserved instances or Azure reserved capacity)? How will you manage the commitment versus on-demand decision?

Questions That Reveal Policy Conflicts

These questions often expose disagreements between departments that governance must resolve:

• Does finance want to control cloud spend centrally, or should teams have autonomy as long as it fits their budget?
• Does security want to restrict which cloud providers and regions can be used, or is flexibility valued over control?
• Do teams want fast self-service provisioning, or is IT governance review acceptable if it takes longer?
• If a team exceeds its budget, who decides what to do (cut off additional provisioning, negotiate a higher budget, charge the overage to the team)?

How to Use Workshop Answers

Document answers to these questions in a workshop output. Answers reveal the governance model, policies, and workflows that Cloud Provisioning should enforce. Some answers will align; others will surface conflicts that require executive decision-making. The workshop output becomes the requirements document for configuring Cloud Provisioning.

Running the workshop as a set of separate conversations

A requirements workshop for cloud governance is seldom undone by poor questions. It more often fails when one room of finance, security, platform engineering and application owners is asked the same list at the same time, and the loudest voice answers for everyone. The better approach is to run a short series of conversations, each shaped around the decisions that one group actually owns, and then to bring the answers together where contradictions can be seen. The questions below are grouped that way. Use them as prompts for a facilitator rather than as a form to be completed by email.

The table shows which group should answer which kind of question, and the output the facilitator should expect back. Keep the output in writing, because the synthesis session depends on it.

Questions for the cost and finance group

Begin with ownership rather than with tools. Ask who pays for cloud resources today, and whether that person knows what they are paying for. Ask how a team learns that it has exceeded its allowance, and how long it often takes. Ask whether the organization has ever bought a commitment for steady workloads, and if so, who made the decision and what evidence they used. The answers reveal whether the governance program will be expected to produce cost control or simply to report on it, and those two expectations lead to very different designs.

Questions for security and compliance

Ask for the controls that would stop a deployment outright, as distinct from the ones that create a finding after the fact. The two lists are often different, and only the first belongs in the approval path. For each control, ask what evidence an auditor has asked for in the last period, and what the team had to produce. This turns an abstract requirement into something the platform can record. Ask also where data is permitted to reside, because a region restriction is the kind of rule that is easy to state and hard to enforce unless the catalog carries the region as a field.

Questions for platform and infrastructure

Map the routes first. Ask every platform owner how a resource is created today, including the ones that bypass the official request process, and which provider accounts those routes use. Then ask which services the team is prepared to support in the first release, and which they are not. A common surprise is a service that is technically available but for which no one is willing to take a page at night. That service should not appear in the first catalog, however often requesters ask for it.

Questions for application teams

Ask what they requested in the last quarter, what they waited for, and what they did when the wait was too long. Requesters who have built a workaround will describe it readily, and the workaround often marks a missing catalog item or an approval that takes too long for a low-risk change. Ask how many of their requests fall into a standard configuration, because that share sets how much of the catalog can be automated later.

Questions for service management

Ask which cloud services need an incident path, which need change control before any configuration edit, and which problems have recurred. The answers determine which records must link to which. A cloud resource that cannot be linked to an incident or a change record can be invisible to the people who run the service, however complete the governance records look.

Reading the answers together

After the separate sessions, lay the answers side by side in one document and look for contradictions. The most valuable contradictions are the ones where two groups both believe they own the same decision, or where each believes the other holds it. Resolve those first, because they stall every later design question. A second useful check is to compare what requesters say they need with what platform teams say they support. The gap between them is the scope of the first release.

1. List every decision named by more than one group and record who holds it.
2. List every control named by security that has no owner in platform or finance.
3. Mark the requests that appear often and check whether each one maps to a supported service.
4. Record the outcome of each contradiction as a decision, naming an owner and a review date.

Signs the workshop has gone wrong

• Every answer is a general principle, with no named service, owner or example. The group is describing its ideal rather than its practice.
• One stakeholder group is absent and its concerns are described second-hand by someone else.
• Answers are accepted without asking for an example from the last period. Examples are where the real constraints appear.

Questions a facilitator should expect from the room

Can we skip the workshop and send the questions by email instead?

You can send a pre-read by email, but the answers arrive polished and without the follow-up that exposes disagreement. Use email to prepare, and keep at least one live session for the groups whose answers conflict.

What if a group cannot answer a question?

Record that as an answer. An unanswered question about who owns a cost is itself a finding, and it should be carried into the decisions list with a named person responsible for answering it.

How long should each group’s session last?

Long enough to get one real example per question. Sessions that run out of examples and continue with principles should stop, and the facilitator should book a follow-up with fewer questions.

Should we invite the cloud providers?

Not to the requirements sessions. Provider sales teams often describe their services in terms of what they can do, and the workshop needs to hear what the organization will do. Provider detail belongs in the design stage, once the requirements are written.

Next step

The roles and RACI guide is the natural follow-on for turning the decision owners into named roles, and the CMDB requirements workshop questions are the matching set for the record side of discovery.