Executive Summary
Managing 1,000 cloud subscriptions across Azure, AWS, and Google Cloud requires more than an inventory of assets and security findings. It requires a consistent way to identify the environments that matter most to the business, understand their exposure, and ensure that the right security controls are enforced.
A central identity platform, a critical production application, and an isolated development environment do not carry the same level of risk. Applying identical security requirements everywhere can leave critical workloads under-protected while consuming valuable resources on lower-risk environments.
This blueprint proposes a risk-based approach built around three decisions:
- Classify by business criticality: Assess business impact, data sensitivity, external exposure, privilege and blast radius, and dependency and recovery.
- Prioritise by current exposure: Identify exploitable vulnerabilities, excessive privileges, public exposure, logging gaps, and other weaknesses that require action.
- Enforce security guardrails: Establish a common security baseline across all active subscriptions, with stronger controls for critical workloads and foundational services.
The framework combines evidence-based scoring, provider-native policy enforcement, accountable ownership, controlled exceptions, and measurable security outcomes.
A phased 180-day rollout takes the organisation from inventory and classification to policy pilots and scaled enforcement. Urgent threats must be addressed immediately rather than deferred to the project schedule.
The business objective is straightforward: establish consistent, risk-based control over the cloud environments that support the organisation’s operations, data, and critical services.
1. Establish a Reliable Cloud Inventory
Before classifying subscriptions, establish a reliable view of the cloud estate.
In many organisations, asset information is spread across a CMDB, cloud consoles, spreadsheets, and application records. Some entries are outdated, while newly created subscriptions may not have been registered at all.
Build the inventory using cloud-provider APIs and reconcile it continuously with existing asset records.
For every subscription or equivalent cloud account, capture:
- Cloud provider, subscription or account ID, and organisational hierarchy.
- Business application, purpose, and environment.
- Business owner and technical owner.
- Data classification and regulatory obligations.
- Internet exposure, network connectivity, and external trust relationships.
- Privileged identities and access to other subscriptions.
- Logging, vulnerability management, and configuration-monitoring status.
- Backup coverage and tested recovery arrangements.
- Open security exceptions and their expiry dates.
An unknown owner is not evidence of low risk. It is an accountability gap that needs to be resolved.
The first milestone is a reconciled inventory in which every active subscription has an identified purpose and an accountable owner.
2. Separate Criticality From Current Exposure
Business criticality and current exposure answer two different questions.
Criticality determines how much protection a workload requires. Current exposure determines how urgently a security issue needs attention.
Consider a production payments platform with strong security controls and no major findings. It remains critical because an outage or compromise could significantly affect the business.
Now consider a development environment with an internet-facing server containing a known exploited vulnerability. Its business impact may be lower, but the immediate exposure could require urgent remediation.
If we rank subscriptions only by their current findings, we may under-protect important workloads. If we rank them only by business importance, we may overlook urgent threats elsewhere.
The solution is to classify business criticality separately from security exposure and use both assessments to guide decisions.
3. Build a Practical Criticality Scoring Model
Apply a consistent five-point scale across all cloud providers. Assess each subscription against five dimensions, using evidence from business impact assessments, data classifications, architecture records, access reports, and recovery tests.
Business impact — 30%
Assess the operational, financial, customer, and business continuity consequences if the workload becomes unavailable or is compromised.
Data sensitivity — 25%
Consider whether the subscription processes personal information, financial records, regulated data, intellectual property, or other sensitive business information.
External exposure — 20%
Assess internet reachability, exposed management interfaces, third-party connectivity, and network paths that could increase the attack surface.
Privilege and blast radius — 15%
Determine what an attacker could control after compromising the subscription. Consider privileged identities, cross-account access, and the ability to affect other environments.
Dependency and recovery — 10%
Assess whether other critical services depend on the subscription and whether recovery has been demonstrated, including dependencies on identity, networking, encryption keys, and shared infrastructure.
Scoring model: Operating rules
The formula is useful only if teams apply it consistently. The following rules establish a repeatable assessment process.
Use a defined five-point scale.
- 1 — Very low: Minimal business impact, sensitivity, or dependency.
- 2 — Low: Limited impact with manageable consequences.
- 3 — Moderate: Meaningful business impact or exposure requiring established controls.
- 4 — High: Significant business, data, operational, or dependency impact.
- 5 — Critical: Severe business consequences, highly sensitive data, substantial privileges, or major service dependencies.
These descriptions provide a common starting point. Define dimension-specific criteria so that teams interpret each score consistently.
Apply the weights consistently.
Use the same weights for every cloud provider and business unit: 30%, 25%, 20%, 15%, and 10%. Together, they total 100%. Changes to the weighting model should be formally approved and recalibrated rather than introduced locally.
Use evidence, not assumptions.
Business owners should validate business impact and data sensitivity. Cloud and security teams should validate technical exposure, privileges, and recovery dependencies.
If evidence is missing, do not automatically assign a score of 1. Mark the dimension as unknown, record the gap, and use a conservative provisional classification until the assessment is completed.
Define the assessment boundary.
Score the subscription against the workloads and services it contains. Where several workloads have materially different risk profiles, assess them individually when practical. The subscription’s minimum guardrail tier should reflect its highest-impact workload or a documented aggregation method.
Keep security findings separate.
A vulnerability being fixed should not reduce a workload’s business criticality. Likewise, discovering a new vulnerability should not automatically change its criticality score. Record those findings in the current-exposure assessment.
Apply mandatory overrides.
Central identity services, organisation-wide administrative control planes, central security monitoring, and other services whose compromise could affect multiple environments may require a higher tier regardless of the calculated score. Document the reason and required tier.
Record and review the assessment.
Retain the dimension scores, supporting evidence, final classification, assessment date, and accountable reviewer. Reassess after material changes, such as increased privileges, new sensitive data, internet exposure, or significant changes to business dependencies. Review critical and high-risk subscriptions more frequently.
For borderline cases, validate the evidence and scoring criteria instead of adjusting the score to obtain a preferred result. Where material uncertainty remains, apply the more protective tier provisionally.
Applying the scoring formula
Each dimension receives a score from 1 to 5. Its contribution is calculated by multiplying the score by the assigned weight.
The weighted score is:
[ W=\sum_{i=1}^{5}\left(\frac{s_i}{5}\times w_i\right) ]
The final criticality score is:
[ C=100\times W ]
Here, (s_i) represents the score for each dimension, and (w_i) represents its weight expressed as a decimal.
An equivalent formula is:
[ C=20\sum_{i=1}^{5}(s_i\times w_i) ]
Let us apply this formula to three different subscription types.
Example 1: Critical production payments platform
Assume a subscription hosts a production payments application that processes sensitive financial data and supports essential business operations.
The assessment produces the following scores:
- Business impact: 5 × 0.30 = 1.50
- Data sensitivity: 5 × 0.25 = 1.25
- External exposure: 4 × 0.20 = 0.80
- Privilege and blast radius: 4 × 0.15 = 0.60
- Dependency and recovery: 5 × 0.10 = 0.50
The weighted total is 4.65 out of 5.
Final calculation:
[ C=20\times(1.50+1.25+0.80+0.60+0.50) ]
[ C=20\times4.65=\boxed{93} ]
The subscription receives a Critical classification with a score of 93/100.
It requires stringent security guardrails, tightly controlled privileged access, protected central logging, enhanced monitoring, and tested recovery arrangements.
Example 2: Standard internal business application
Consider an internal business application with moderate operational impact, limited sensitive data, restricted network access, and manageable dependencies.
Its scores are:
- Business impact: 3 × 0.30 = 0.90
- Data sensitivity: 2 × 0.25 = 0.50
- External exposure: 2 × 0.20 = 0.40
- Privilege and blast radius: 2 × 0.15 = 0.30
- Dependency and recovery: 3 × 0.10 = 0.30
The weighted total is 2.40 out of 5.
Final calculation:
[ C=20\times(0.90+0.50+0.40+0.30+0.30) ]
[ C=20\times2.40=\boxed{48} ]
The subscription receives a Moderate classification with a score of 48/100.
It must meet the common security baseline, including identity and access controls, logging, vulnerability management, configuration monitoring, and appropriate recovery arrangements. Access to higher-criticality environments must remain restricted.
Example 3: Isolated development sandbox
Consider a temporary development environment that contains no production data, has limited privileges, is isolated from production, and supports no critical downstream services.
Its scores are:
- Business impact: 1 × 0.30 = 0.30
- Data sensitivity: 1 × 0.25 = 0.25
- External exposure: 2 × 0.20 = 0.40
- Privilege and blast radius: 1 × 0.15 = 0.15
- Dependency and recovery: 1 × 0.10 = 0.10
The weighted total is 1.20 out of 5.
Final calculation:
[ C=20\times(0.30+0.25+0.40+0.15+0.10) ]
[ C=20\times1.20=\boxed{24} ]
The subscription receives a Lower classification with a score of 24/100.
It still requires the common security baseline, restricted production connectivity, controlled privileges, approved configurations, and ownership and expiry controls.
These scores are illustrative. Actual classifications must be supported by evidence, and mandatory overrides may require a higher tier regardless of the calculated result.
Classification bands
Use the following thresholds as an initial model:
- Critical: 80–100 — Crown-jewel workloads and environments with substantial business or systemic impact.
- High: 60–79 — Important production services and workloads with significant business or data risk.
- Moderate: 40–59 — Standard business workloads with more limited impact.
- Lower: 20–39 — Isolated, low-impact environments with restricted access and dependencies.
These are proposed thresholds, not universal industry standards. Validate them against business impact analysis, regulatory requirements, and the organisation’s risk appetite.
4. Assess Exposure and Prioritise Remediation
Once criticality is established, assess what could be exploited or abused in the current environment.
Focus on:
- Known exploited vulnerabilities and indicators of compromise.
- Publicly exposed services and management interfaces.
- Excessive privileges, compromised identities, and risky cross-account trust.
- Missing audit logs or gaps in security monitoring.
- Exposed secrets, dangerous configuration drift, and weak data protection.
- Untested backups or unverified recovery arrangements.
- Unowned subscriptions and expired security exceptions.
Prioritise action according to the severity and likelihood of harm, the business impact of the affected workload, and whether the weakness could affect multiple environments.
A practical response order is:
- Contain active compromise and immediately exploitable exposure.
- Address systemic weaknesses, such as compromised central identity or excessive organisation-level privileges.
- Remediate high-impact weaknesses in critical workloads.
- Close visibility gaps that prevent reliable risk assessment.
- Resolve remaining configuration drift according to agreed remediation targets.
Applying this to the payments example
Suppose the subscription scoring 93 out of 100 is internet-facing, contains a known exploited vulnerability, and is not forwarding audit logs to central monitoring.
The workload is already Critical, and its current exposure demands urgent action. The response should include appropriate containment or immediate risk reduction, vulnerability remediation, and restoration of security visibility.
Once these issues are resolved, the subscription remains Critical. Its business importance has not changed.
5. Enforce Guardrails According to Risk Tier
The classification model should determine the minimum controls a subscription must meet.
Tier 0: Foundational and control-plane services
This tier includes central identity, organisation-wide administration, security tooling, central logging, key management, and shared networking or recovery services.
Apply tightly restricted privileged access, strong authentication, just-in-time elevation where supported, separation of duties, and controlled emergency access. Protect audit logs against unauthorised modification, monitor changes to critical security settings, restrict trust relationships, and test recovery procedures.
These services deserve the strongest protection because their compromise could undermine the security of many other subscriptions.
Tier 1: Critical production and sensitive workloads
Enforce least-privilege access, strong authentication, restricted network exposure, appropriate segmentation, encryption, and secure key and secret management.
Require central audit logging, threat detection, vulnerability and configuration monitoring, risk-based remediation deadlines, and tested backups aligned with business-approved recovery objectives.
For the payments subscription scoring 93, these are minimum requirements, not optional enhancements.
Tier 2: Standard business workloads
Apply the common security baseline, including identity and access controls, approved network configurations, encryption, asset inventory, vulnerability management, logging, and appropriate backup arrangements.
Control access between these workloads and more critical environments to prevent a lower-tier subscription from becoming a route into a higher-impact system.
Tier 3: Isolated development and sandbox environments
Restrict privileged access and production connectivity. Limit services and regions where appropriate, apply usage quotas, and establish ownership and expiry requirements for temporary environments.
Do not allow uncontrolled access to production credentials or sensitive data. If a sandbox starts processing sensitive information or gains broad administrative privileges, reassess its classification rather than relying on its original label.
6. Establish a Baseline for Every Subscription
Regardless of tier, every active subscription should meet a minimum set of security requirements:
- Identity and access: Strong authentication, least privilege, and controlled privileged and workload identities.
- Logging: Required audit events sent to a protected central destination, with appropriate monitoring.
- Asset and vulnerability management: Discoverable assets, security assessment, and risk-based remediation.
- Configuration management: Approved configurations, detection of drift, and enforceable restrictions on high-risk settings.
- Data protection: Encryption, secrets management, and appropriate safeguards for sensitive information.
- Recovery: Documented and tested arrangements proportionate to business impact.
- Accountability: Named owners and traceable security exceptions.
If a control genuinely does not apply, document the reason and retain evidence. A technical limitation should trigger a documented assessment, not an automatic compliance pass.
7. Implement the Guardrails Using Native Cloud Controls
The enterprise security standard should define the required outcome. Each cloud provider should enforce or monitor that requirement through its native capabilities.
Microsoft Azure
Use management groups and subscriptions to establish the governance hierarchy. Azure Policy can audit configurations, deny supported non-compliant deployments, and deploy supported configurations. Use Azure role-based access control and Privileged Identity Management to manage permissions and privileged elevation.
Amazon Web Services
Use AWS Organizations and organizational units to group accounts by purpose and risk. Service Control Policies restrict the maximum permissions available to affected accounts, but they do not grant permissions by themselves.
Use AWS Config for configuration assessment and centralised audit logging for visibility across accounts. Protect the central logging destination against unauthorised changes or deletion.
Google Cloud
Use the organisation and folder hierarchy to group projects and apply Organization Policy constraints. Combine these with controlled IAM permissions, audit logging, and configuration monitoring.
Maintain a common cross-cloud policy catalogue
For each guardrail, record the security requirement, risk addressed, applicable subscriptions and tiers, provider-specific enforcement mechanism, evidence of compliance, accountable owner, and exception process.
This catalogue allows the organisation to maintain one security standard without assuming that Azure, AWS, and Google Cloud implement every control identically.
Before enabling disruptive preventive policies at scale, test them in audit mode or a controlled pilot wherever supported. Validate the results and operational impact before expanding enforcement.
8. Govern Security Exceptions
Some workloads cannot immediately meet a guardrail because of legacy architecture, technical limitations, or business constraints. Such cases should be managed through a formal, time-bound exception process.
Each exception must identify:
- The affected subscription and control.
- The business justification.
- The risk assessment and compensating controls.
- The accountable owner and authorised risk approver.
- The expiry date and review schedule.
- The remediation plan and target date, where applicable.
Expired exceptions should trigger review and escalation. Exceptions affecting foundational or critical workloads require closer scrutiny because their consequences can extend beyond a single application.
An accepted risk is not the same as an implemented control. Reporting must preserve that distinction.
9. Roll Out the Framework Over 180 Days
A phased implementation establishes visibility first, then classification, followed by scaled enforcement. Active compromise and urgent exposure must be addressed immediately, regardless of the project schedule.
Days 1–15: Establish visibility
Reconcile provider inventories with the asset register. Identify subscriptions without owners, exposed services, privileged accounts, and dependencies on foundational services.
Deliverable: A reconciled inventory, accountable ownership, and an initial list of urgent risks.
Days 16–60: Classify and prioritise
Apply the scoring model, validate classifications with business owners, identify mandatory tier overrides, and assess current exposure separately.
Deliverable: A risk-ranked subscription register showing criticality, exposure, ownership, and remediation priorities.
Days 61–120: Design and pilot guardrails
Define the common baseline, tier-specific requirements, and provider-native enforcement mechanisms. Test policies, validate evidence collection, and establish exception and rollback procedures.
Deliverable: A tested cross-cloud guardrail catalogue ready for phased deployment.
Days 120–180: Scale enforcement
Roll out approved controls in risk-based waves. Apply preventive enforcement to high-impact settings where supported and safe, and connect findings to remediation workflows.
Deliverable: An operational governance process with measurable control coverage and visibility into unresolved risks.
10. Measure Whether the Controls Are Working
The number of policies deployed is not proof that the cloud estate is secure. Measure whether the programme is improving visibility, reducing exposure, and enforcing the required protections.
Track these outcomes:
- Inventory coverage: Percentage of active subscriptions discovered and reconciled.
- Ownership coverage: Percentage with validated business and technical owners.
- Classification coverage: Percentage assigned a validated criticality tier.
- Guardrail compliance: Percentage meeting mandatory baseline and tier-specific controls.
- Security visibility: Percentage forwarding required audit events to protected central logging and covered by appropriate monitoring.
- Critical exposure: Number and age of unresolved high-impact risks, including known exploited vulnerabilities and dangerous privilege paths.
- Exception health: Number of open, overdue, and expired exceptions, especially for critical workloads.
- Remediation performance: Time taken to contain or resolve critical findings against agreed targets.
- Recovery assurance: Percentage of critical workloads with successfully tested recovery against approved objectives.
Give each metric a clear definition, accountable owner, and trend over time. Set targets using the initial baseline, business requirements, and risk appetite.
11. From Cloud Inventory to Active Risk Management
Managing 1,000 cloud subscriptions does not mean every subscription should receive identical security treatment. It means every subscription should receive protection appropriate to its business importance and current exposure.
The framework begins with a reliable inventory, uses evidence-based scoring to determine criticality, and assesses current exposure separately to prioritise action. Common guardrails establish minimum protection, while stronger controls protect critical and foundational services.
Provider-native policies turn those requirements into enforceable rules. A controlled exception process makes accepted risks visible, and outcome-based metrics show whether the programme is working.
The real value is not the scoring formula or the number of policies deployed. It is the ability to make consistent, defensible decisions across a large, distributed cloud environment.
When a critical workload is exposed, the team should know why it matters and what action is required. When a security policy is introduced, the organisation should be able to demonstrate where it applies and whether it is enforced. When an exception is accepted, its risk, owner, and expiry should remain visible.
The goal is simple: know what matters, understand what is exposed, enforce the right guardrails, and demonstrate that the controls are working.
That is how cloud governance moves from maintaining an inventory to actively managing risk across 1,000 subscriptions.
