Cloud Infrastructure
Cloud Operations
Governance
Visibility-First Cloud Governance: Why You Should Start with Data
TL;DR: Traditional governance starts with policies and tries to enforce them. This fails because you can't enforce rules about infrastructure you can't see. The Visibility-First Governance Model inverts the process: build a unified inventory first, write policies in SQL against that inventory, monitor continuously, then automate responses. The result is governance that actually works across multi-cloud environments because it's grounded in real infrastructure data, not assumptions about what should exist.
This post is adapted from the free Cloud Operations Playbook, which includes the full implementation guide with 20+ SQL policy examples.
Governance That Starts at the Wrong End #
Here's how most cloud governance programs begin. A security or compliance team writes a set of policies: "All S3 buckets must block public access." "Every resource must have an owner tag." "No security groups should allow unrestricted SSH." Good policies. Reasonable rules.
Then the team tries to enforce them.
They quickly discover they don't have a complete picture of what's actually running. The AWS accounts they know about have hundreds of untagged resources. There are GCP projects nobody told them about. Azure subscriptions from last year's acquisition haven't been onboarded to any tooling. The policies are correct, but they're floating in mid-air with nothing to anchor them to.
This is the fundamental problem with traditional governance: it assumes you already know what you're governing.
89% of organizations use multiple cloud providers. But according to the HashiCorp State of Cloud Strategy Survey, only 8% qualify as highly cloud-mature. That means the vast majority of multi-cloud organizations are writing governance policies against infrastructure they can't fully see. And misconfigurations are the leading cause of cloud security incidents, not sophisticated attacks. The resources were there. The rules existed. Nobody could connect the two.
The Traditional Model vs. Visibility-First #
The traditional governance model follows a predictable pattern:
- Define policies based on frameworks and best practices
- Try to enforce them using disparate tooling per cloud provider
- Discover gaps when audits, incidents, or questions reveal blind spots
- Scramble to fix the gaps under time pressure
This cycle repeats every quarter. Teams spend weeks before each audit manually gathering evidence from five or six different systems, correlating data across spreadsheets, and hoping nothing falls through the cracks.
The Visibility-First model flips this sequence entirely:
- Build a unified inventory across all providers
- Understand your actual infrastructure state
- Define policies against real data
- Enforce continuously and automatically
The difference isn't just ordering. It's foundational. When you start with visibility, every subsequent step has something to stand on. Policies reference actual resources. Monitoring covers your real attack surface, not just the parts you've manually onboarded. Automation acts on verified state, not assumptions.
The Four Layers of Visibility-First Governance #
We've broken the model into four layers, each building on the one below it. Skipping a layer or implementing them out of order is why most governance programs stall.
Layer 1: Unified Visibility #
This is the foundation everything else depends on. Without it, the other three layers are guesswork.
Unified visibility means a single queryable inventory that spans every cloud provider, every account, and every resource type. Not three separate dashboards you flip between. Not a spreadsheet someone updates monthly. A normalized data layer where an AWS EC2 instance and an Azure VM and a GCP Compute Engine instance all live in the same queryable format.
This matters because governance questions are almost never single-provider questions. "Do any of our compute instances have public IPs and no encryption at rest?" That question spans AWS, Azure, and GCP. If your inventory only covers two of the three, your answer is incomplete and your governance is incomplete.
The data model needs to be normalized so you can compare resources across clouds. It also needs to retain historical data so you can track changes over time. "When did this security group rule change?" is just as important as "is this security group rule compliant right now?"
Layer 2: Policy as Code #
Once you have a unified inventory, you need a way to express governance rules against it. This is where most tools go wrong: they invent a proprietary language.
Rego. Sentinel. Custom DSLs. Each one requires engineers to learn a new syntax, maintain fluency in it, and convince other teams to adopt it. The security team writes policies the platform team can't read. The compliance team can't verify what the policies actually check. Knowledge stays siloed.
SQL changes this dynamic completely.
Every engineer already knows SQL. Security teams can read it. Compliance teams can understand it. Finance teams can run queries themselves. There's no translation layer between "what the policy checks" and "what people understand."
Here's what a policy looks like in SQL:
-- Find S3 buckets that don't block public access
SELECT
account_id,
region,
name,
arn
FROM aws_s3_buckets
WHERE block_public_acls IS NOT TRUE
OR block_public_policy IS NOT TRUE
OR ignore_public_acls IS NOT TRUE
OR restrict_public_buckets IS NOT TRUE;
That's a real governance policy. Anyone who's written a WHERE clause can read it, modify it, and verify what it does. No new language to learn. No vendor lock-in to a proprietary policy engine.
And the same query works in multiple contexts. Run it interactively to investigate a finding. Schedule it to generate compliance evidence. Wire it into an alert to catch new violations. The policy becomes living documentation of your governance standards, written in a language your entire organization already speaks.
Here's another example that works across providers:
-- Find compute instances with public IPs across AWS and GCP
SELECT
'aws' AS provider,
instance_id AS resource_id,
public_ip_address,
tags
FROM aws_ec2_instances
WHERE public_ip_address IS NOT NULL
UNION ALL
SELECT
'gcp' AS provider,
id AS resource_id,
access_configs->>'natIP' AS public_ip_address,
labels AS tags
FROM gcp_compute_instances
WHERE access_configs->>'natIP' IS NOT NULL;
Try writing that cross-cloud query in Rego.
Layer 3: Continuous Monitoring #
Policies that only run at deploy time miss everything that happens after deployment. And a lot happens after deployment.
Configuration drift is constant. A developer widens a security group rule to debug a connectivity issue and forgets to revert it. An S3 bucket policy gets modified through the console to unblock a deployment. An IAM role accumulates permissions over months as different teams request access. None of these changes go through CI/CD. None of them trigger your deploy-time policy checks.
Continuous monitoring means evaluating your policies on a schedule, not just when code is pushed. It means running your SQL policies against fresh inventory data daily, hourly, or on whatever cadence makes sense for your risk tolerance. When a resource drifts out of compliance, you know about it within hours, not months.
This layer also handles drift detection and alerting. If a resource was compliant yesterday and isn't today, that's a signal. If ten resources in the same account all drift in the same direction, that's a pattern worth investigating.
Layer 4: Automated Response #
Not every violation needs a human in the loop. Some violations have clear, safe remediation paths that can be automated.
Public S3 bucket detected? Auto-remediate by enabling the block public access setting. Untagged resource created? Apply default tags based on the account and creator. Security group opened to 0.0.0.0/0? Automatically restrict to the VPN CIDR range.
Other violations need human judgment. A production database with an unusual access pattern might be a security incident or might be a legitimate batch job. For these cases, automated response means notification workflows: the right person gets alerted with the right context to make a decision quickly.
This layer also handles exception tracking. Sometimes a resource needs to violate a policy for a legitimate reason. A staging environment might need public access for a vendor integration test. The key is tracking the exception: who approved it, when it expires, and whether the resource is returned to compliance afterward. Without exception tracking, you're constantly triaging the same known violations and wasting time on false positives.
Why SQL Is the Right Policy Language #
We've mentioned SQL a few times now, so let's be explicit about why it matters.
The barrier to governance adoption in most organizations isn't technical. It's organizational. Policies written in Rego or Sentinel create a bottleneck: only the team that knows the language can write, read, or modify policies. Everyone else has to trust that the policies do what they claim.
SQL eliminates this bottleneck. Your platform engineering team can write the initial policies. Your security team can review them without learning a new syntax. Your compliance team can verify they map to control requirements. Your finance team can write their own cost governance queries. Everyone works in the same language against the same data.
This also means policies become auditable documentation. When an auditor asks "how do you ensure all storage buckets block public access?", you don't hand them a prose document describing your intent. You show them the SQL query that checks it, the schedule it runs on, and the historical results. Policy, evidence, and enforcement in one artifact.
Going deeper on implementation? The Cloud Operations Playbook eBook includes a full implementation guide for each of the four governance layers, 20+ ready-to-use SQL policy examples, and a week-by-week deployment plan so you can roll this out without guessing at the sequencing.
Getting Started: A Practical Path #
You don't need to implement all four layers at once. And you shouldn't. The short version: start with a unified asset inventory in weeks one and two, write your first five SQL policies in weeks three and four, add scheduled monitoring in month two, and layer in automation in month three.
Each layer produces value on its own. You don't need automated response to benefit from continuous monitoring. You don't need continuous monitoring to benefit from policy-as-code. And even Layer 1 alone, a unified inventory you can query, is a massive improvement over the status quo.
The Cloud Operations Playbook eBook includes the detailed week-by-week implementation guide with specific milestones, so you can hand it to your team and start executing.
What Changes When You Get This Right #
Teams that adopt the Visibility-First model report a few consistent outcomes.
Audit prep drops from weeks to hours. Instead of manually gathering evidence from multiple systems, compliance teams run the relevant queries and export the results. The evidence is always current because the policies run continuously.
Security investigations get faster. When someone asks "are we affected by this new CVE?", the answer comes from a query against the unified inventory, not from logging into three different consoles and cross-referencing spreadsheets.
Governance becomes a shared responsibility instead of a bottleneck. When anyone can read, write, and verify policies, governance isn't something the security team does to the engineering team. It's something everyone participates in.
And perhaps most importantly, teams stop being surprised. Drift gets caught early. Misconfigurations get flagged before they become incidents. The gap between "what we think is running" and "what's actually running" starts to close.
Key Takeaways #
- Start with visibility, not policies. You can't enforce rules about infrastructure you can't see. Build a unified, queryable inventory first
- Use SQL for policies. Every engineer already knows it. It removes bottlenecks and makes governance a shared responsibility
- Monitor continuously, not just at deploy time. Configuration drift happens constantly and silently. Schedule your policies to catch it
- Automate what's safe, alert on what's not. Not every violation needs a human, but some do. Build both paths
- Implement in order. Each layer builds on the one below it. Skipping ahead creates the same gaps you're trying to close
The next post digs into practical implementation. Part 7 covers Continuous Cloud Governance, where we walk through setting up scheduled policy evaluation, building dashboards that track compliance over time, and integrating governance into your existing workflows.
About This Series: This is Part 6 of our 12-part Cloud Operations Playbook series. Each post builds on the previous, covering the gap between what leadership thinks they know about cloud infrastructure and what's actually running.
- Part 6 (This post): The Visibility-First Governance Model
Want the complete guide? Download the free 67-page eBook.
FAQ #
What Is the Visibility-First Governance Model? #
The Visibility-First Governance Model is a four-layer approach to cloud governance that inverts the traditional sequence. Instead of starting with policies and trying to enforce them, it starts with unified visibility across all cloud providers, then layers on policy-as-code, continuous monitoring, and automated response. Each layer builds on the one below it, grounding governance in actual infrastructure data rather than assumptions.
Why Do Traditional Governance Models Fail? #
Traditional governance models fail because they assume you already have complete visibility into your infrastructure. They start with policy definitions and enforcement mechanisms, but when teams try to enforce those policies, they discover they don't know about all the accounts, resources, or configurations in their environment. The policies are correct but disconnected from reality.
Why Use SQL for Cloud Governance Policies? #
SQL removes the organizational bottleneck that proprietary policy languages create. Every engineer already knows SQL. Security teams can read it, compliance teams can verify it, and platform engineering teams can write it. The same query works for interactive investigation, scheduled compliance checks, and automated alerting. Policies become living documentation that your entire organization can understand and contribute to.
How Is This Different from Cloud Security Posture Management? #
CSPM tools typically focus on security-specific checks within a single cloud provider. The Visibility-First model is broader: it spans security, compliance, cost governance, and operational hygiene across all providers. CSPM can be a component within Layer 3 (Continuous Monitoring), but the model addresses the full governance lifecycle from inventory through automated response.
How Long Does It Take to Implement? #
Most teams can have a unified inventory (Layer 1) running within a week or two using the quickstart guide. Writing initial SQL policies (Layer 2) takes another week or two. Continuous monitoring (Layer 3) is a month-two activity, and automated response (Layer 4) typically comes in month three. You don't need all four layers to see value. Even Layer 1 alone is a significant improvement.
What If We Already Have Governance Tooling in Place? #
Existing tooling isn't wasted. The Visibility-First model provides the data foundation that other tools often lack. Your CSPM tool, compliance platform, and cost management system all work better when they're pulling from a single, normalized asset inventory. The model complements existing investments rather than replacing them entirely.
Can This Approach Scale Across Thousands of Accounts? #
Yes. Because the model is built on a queryable data layer rather than agent-based scanning, it scales with your data infrastructure rather than your cloud footprint. SQL queries against a normalized database work the same whether you have ten accounts or ten thousand. The key constraint is sync frequency and data freshness, not account count.
How Do We Handle Policy Exceptions? #
Layer 4 includes exception tracking as a core component. When a resource legitimately needs to violate a policy (a staging environment requiring temporary public access, for example), the exception is logged with an owner, a justification, and an expiration date. Expired exceptions automatically resurface as violations. This prevents known exceptions from becoming permanent blind spots.
Get the Full Governance Implementation Guide
The free 67-page eBook includes implementation guides for each governance layer, 20+ SQL policy examples ready to use, and a week-by-week deployment plan. Want help planning your rollout? Talk to our team.
