India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Cloud Governance Operations: Policy Reviews, Exceptions and Vending
Cloud governance operations is the recurring work that keeps a cloud organisation inside its agreed rules: reviewing policy compliance, handling exception requests, vending new accounts, subscriptions and projects with guardrails pre-applied, and updating policies as services and regulations change. NTSPL runs this monthly cycle across AWS, Azure and Google Cloud for companies whose landing zone exists but whose rules are drifting.
Delivered on
In scope
Keeping a Cloud Organisation Inside Its Rules
Landing zones are designed once, usually during migration, with management groups, SCPs, organisation policies and tagging rules. Two years later the picture has shifted. New teams asked for accounts and got them by email, without the baseline. Exemptions granted for a launch weekend are still active. Policies written in audit mode were never switched to deny. Nobody is sure which of 300 policy assignments still matter, and the compliance dashboard shows 61% because half the findings belong to resources nobody owns.
NTSPL operates governance as a service with three loops. Account and subscription vending runs through a request form and pipeline that applies baseline guardrails, budgets, logging and network attachment in hours. Every exception has an owner, a reason, compensating controls and an expiry date of 90 days or less. Each month we review compliance by policy and by owner, propose audit-to-deny promotions and retire policies that no longer apply.
Signs Your Guardrails Are Drifting
Signals you need Cloud Governance Operations
- New accounts, subscriptions or projects take more than a week to provide, or are created outside the landing zone
- Policy exemptions exist with no expiry date or owner
- The policy compliance score has been flat or falling for three months
- More than a third of your policies are still in audit mode two years after the landing zone went live
- An internal audit or regulator asked for evidence that cloud policies are reviewed and enforced
When to choose something else
- You do not yet have a landing zone, management hierarchy or policy baseline; build that first, then hand it to operations
- You need to design the CCoE, roles and decision rights from scratch; that is an operating model assessment
Governance Loops NTSPL Runs Each Month
Account and subscription vending
Request form, approval and pipeline that create accounts, subscriptions or projects with guardrails, logging, budgets and networking pre-applied.
Exception management
Every exemption recorded with owner, reason, compensating controls and an expiry, reviewed before renewal.
Monthly compliance review
Non-compliance by policy and by owner, trend against last month, and tickets for the top items.
Policy lifecycle
Promotion from audit to deny when compliance passes 95%, retirement of obsolete policies and new policies for new services.
Regulatory mapping
Policies mapped to RBI, SEBI CSCRF, IRDAI or DPDP requirements so audit evidence comes straight from the compliance data.
Vending, Exception and Compliance Review Cycle
Guardrail Lifecycle with Account Vending and Exception Expiry
New accounts and subscriptions are vended through a pipeline that applies the baseline. Policy evaluation feeds a monthly review that promotes, retires or adds policies, while every exception carries an expiry that triggers re-review.
Select any component
Guardrail Lifecycle with Account Vending and Exception Expiry: click any of its 7 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Guardrail and Vending Tooling by Provider
We vend accounts through Account Factory for Terraform so baselines are code, and use resource control policies alongside SCPs to stop external access to S3 and KMS regardless of resource-level settings.
Azure Policy exemptions support an expiry date, which we set on every exemption, and the landing zone subscription vending module creates subscriptions with policy and networking already attached.
Custom organisation policy constraints let us enforce settings such as required labels or approved machine families, and Policy Intelligence shows who would be affected before we tighten a rule.
Deny vs Audit, Exception Terms and Vending Choices
When to move from audit to deny
Start new policies in audit mode for 30 days. Promote to deny once compliance exceeds 95% and the remaining resources have owners and tickets. Some rules, such as allowed regions, public storage blocks and mandatory encryption, should be deny from day one in new accounts. Never promote a policy in the same week as a major release.
Exception terms
Grant exceptions for at most 90 days, scoped to a specific resource or resource group, never to a whole subscription or account. Each needs a reason, owner, compensating control and target fix date. Renewals require evidence of progress. Report the count and age of exceptions monthly; more than 5% of resources under exception means a policy is wrong or a team needs help.
Vending speed vs control
Sandbox accounts should be self-service and vended in under an hour with tight budgets, such as ₹10,000 a month, and automatic cleanup after 90 days. Non-production should take under a day with team-lead approval. Production should take one to two days with CCoE approval, because network attachment and data classification need a human decision.
How many policies
Fewer, enforced policies beat hundreds in audit. Start from the provider's foundational benchmark and regulatory mapping, then add custom policies only where an incident or audit finding justifies one. Retire any policy with 100% compliance for six months if a deny rule elsewhere already covers it, and review the full set every quarter.
Bringing Governance into a Monthly Rhythm
Governance baseline
Inventory hierarchy, policies, assignments, exemptions and compliance by owner; find accounts outside the landing zone.
Exception clean-up
Review every exemption with owners; renew with expiry, fix, or remove.
Vending pipeline
Build or repair the vending pipeline and bring stray accounts under the hierarchy.
Monthly review cycle
First governance review with promotion and retirement proposals, then monthly.
What you receive
Governance Health Measures
| KPI | Typical target |
|---|---|
| Policy compliance across in-scope resources | Above 95% |
| Exceptions without expiry | Zero |
| Production account or subscription vending time | Under 2 working days |
| Accounts or subscriptions outside the hierarchy | Zero |
Governance Breakdowns We Prevent
| Risk | How NTSPL prevents it |
|---|---|
| A deny policy blocks a production deployment unexpectedly | 30-day audit period, impact analysis with Policy Intelligence or what-if, and promotions outside release weeks. |
| Exceptions renewed by default and never fixed | Renewal requires evidence of progress and is visible in the monthly review. |
| Teams bypass vending by using personal or partner accounts | Billing and SSO checks for unknown accounts and a vending SLA fast enough that bypass is not worth it. |
Cloud governance operations vs a cloud operating model: what is the difference?
An operating model decides who does what: the CCoE's remit, decision rights, roles, skills and processes. Governance operations is the monthly execution of the rules that model sets. If nobody agrees who approves production accounts or owns the policy baseline, an operating model assessment comes first. If those roles exist but policies drift, exceptions pile up and new accounts take weeks, governance operations is what is missing. Most organisations two years into cloud already have a workable model on paper and need the operational rhythm to make it real.
Key facts: Cloud Governance Operations
Cloud Governance Operations in Practice
2 Cloud Governance Operations scenarios, from Hospital network and Port community system, plus related platform case studies.
Hospital network retires 140 open-ended exemptions and vends subscriptions in a day
Port community system brings 46 AWS accounts and 12 Azure subscriptions under one baseline
Health-tech SaaS moves patient data behind KMS and Identity Center ahead of DPDP
IT services firm brings 43 Azure subscriptions under one policy hierarchy
Cloud Governance Operations: Frequently Asked Questions
What does cloud governance operations cost?
For an organisation with 20-80 accounts, subscriptions or projects, NTSPL typically charges ₹1-2.5 lakh a month for vending, exception management, monthly reviews and policy upkeep. Building or repairing the vending pipeline is a fixed one-time fee, usually four to six weeks of effort.
Can governance enforce Indian data residency?
Yes. Allowed-region policies in SCPs, Azure Policy and Organization Policy restrict production to Indian regions such as AWS Mumbai and Hyderabad, Azure Central, South and West India, and Google Cloud Mumbai and Delhi. Global services such as IAM need carefully scoped exceptions.
How does this help with RBI, SEBI or IRDAI audits?
We map each policy to the relevant control in RBI's IT governance directions, SEBI CSCRF or IRDAI's cyber security guidelines. Compliance data then becomes audit evidence, showing enforcement, exceptions with approval and monthly review records. Auditors can sample any policy and trace it to enforcement.
Who approves exceptions?
Your CCoE lead or CISO, according to a matrix agreed at onboarding. NTSPL prepares each request with risk, compensating controls and expiry, and implements it once approved. We do not approve exceptions ourselves. Every approval is logged against the exception record.
Do you replace our CCoE?
No. Your CCoE sets direction and makes decisions. We run the recurring tasks, prepare the monthly review and implement agreed changes, which lets a small CCoE of two or three people govern a large estate. Decision rights stay entirely with you.
How fast can a new account or subscription be ready?
Sandboxes in under an hour, non-production within one working day and production within two working days. Each arrives with network attachment, central logging, budgets, mandatory tags and baseline policies already applied, so teams can deploy immediately without a follow-up request to the platform team.