A compliance audit tells you something true about a single moment, but it says almost nothing about the weeks that follow.
Between reviews, infrastructure keeps changing: permissions get granted for a one-off project and never revoked, a storage bucket gets spun up during a deadline crunch with default settings nobody double-checks, a new service gets connected to production before anyone updates the access policy. None of this shows up until the next audit cycle, if it shows up at all.
So, the real question isn’t whether an organization passed its last review. It’s what has changed since.
The Audit Cycle Wasn’t Built for Cloud Environments
Traditional audit cycles were designed for a different kind of infrastructure. Servers sat in a data center, and changes went through a formal request process. A quarterly or annual review had a reasonable chance of catching what mattered, because not much had moved since the last one.
Cloud infrastructure doesn’t work that way.
- Configurations change daily, often through automated deployments rather than manual tickets
- A single line in an infrastructure-as-code template can open or close a control instantly, with no review cycle in between
- Shared responsibility models split ownership between the provider and the organization, and that split isn’t always clear to the people making changes
- Evidence collected for an audit is often stale before the report is even finalized
Federal environments have already started addressing this. The shift from a traditional Authorization to Operate, reassessed every few years, toward Continuous Authorization to Operate (cATO) reflects the same underlying problem, just under a different name.
What This Means in Practice
The gap between reviews shows up in familiar ways:
- An employee leaves the company, and their access to a sensitive system is deactivated in the identity provider but not in a connected third-party tool
- A team migrates a workload to a new environment and copies over a storage configuration that was never meant to be public
- A logging pipeline fails silently after a configuration update, and nobody notices until an incident requires records that were never captured
How This Plays Out Across Frameworks
Different compliance frameworks assess on different schedules, but the underlying problem is the same. For example, SOC 2 audits typically cover a defined period, which means a control that failed midway through can go unnoticed until the next report. ISO 27001 certification cycles, on the other hand, run on a multi-year basis with surveillance audits in between, leaving long stretches unchecked.
The frameworks aren’t the problem; it’s how they get implemented.
What Does “Structural Compliance” Mean for Cloud?
Structural compliance means the control is enforced by the system itself, not verified afterward by a person reviewing logs or screenshots.
The difference plays out like this:
Checklist Model
- A control exists as a written policy
- Someone checks whether it’s being followed, usually on a set schedule
- Violations are discovered after the fact, sometimes months later
Structural Model
- The control is built into the configuration
- Non-compliant changes are blocked, flagged, or automatically corrected
- Violations surface in real time, close to the moment they happen
The areas where this distinction matters most are identity, encryption, logging, network segmentation, and secrets management. Each one can be enforced structurally instead of waiting for periodic reviews.
Five Layers That Should Be Enforced Structurally
1. Identity and Access Management
Access requests are usually granted based on what someone needs right now, then left in place long after the need has passed. Structural enforcement changes that pattern.
- Least-privilege access becomes the default setting, not a request someone has to justify
- Just-in-time access replaces standing permissions for sensitive systems
- Deprovisioning happens automatically when a role changes or a project ends
- Access recertification is triggered by the system on a schedule, rather than chased down by a compliance team
2. Encryption
Encryption should be a property of the infrastructure, not a decision left to whoever provisions a given resource.
- Encryption at rest and in transit is set as the default across every environment
- Key management is automated, with rotation and expiry handled by policy
- Unencrypted storage or transport simply isn’t an option that can be deployed
3. Logging and Monitoring
Logs are only useful for compliance if they can be trusted and if they cover the moment something actually happened.
- Logging is centralized across environments rather than scattered across individual services
- Logs are immutable, so records can’t be altered after the fact
- Retention policies are automated to match regulatory requirements
- Alerts fire on anomalous access in real time, rather than waiting to be discovered in a review
4. Network Segmentation and Isolation
Flat networks make it easy for a single compromised resource to reach everything else. Segmentation limits how far a problem can spread.
- Default-deny policies mean nothing connects unless it’s explicitly allowed
- Environments are isolated from one another, so a breach in development doesn’t reach production
- Access between segments is defined in configuration, instead of ad hoc firewall rules
5. Configuration Management
Credentials and configuration values are some of the easiest things to leave exposed, and some of the most damaging when they are.
- Secrets are stored in a dedicated management system, never hardcoded into application code or configuration files
- Rotation happens automatically on a defined schedule
- Drift detection flags any gap between the declared infrastructure state and what’s actually running
Policy as Code: The Mechanism That Makes This Work
Structural enforcement happens because the rules are written into the deployment process itself.
- Policies are defined in code, using the same tools and version control as the applications they govern
- Non-compliant infrastructure is blocked before it’s provisioned, not flagged after it goes live
- Policy changes go through peer review, the same way application code does
- Compliance status is validated continuously, rather than attested to once and left alone
Where Enforcement Happens
Policy as code works because it’s checked at multiple points:
- At commit, when code is first written and submitted for review
- At build, when infrastructure templates are validated before deployment
- At deploy, when the actual provisioning happens and non-compliant resources are blocked
- At runtime, through ongoing drift detection that compares the live environment against what was declared
Bringing in Drift Detection
A policy that’s only checked at deployment doesn’t account for changes made afterward, whether through a manual override, an emergency fix, or a misconfigured update. Drift detection closes that gap by continuously comparing the state of the environment to what was declared in code, flagging anything that no longer matches.
Mapping Frameworks to Structural Controls
Most regulatory compliance frameworks describe outcomes, rather than implementation. Structural control fills in the implementation gap.
- SOC 2 requires evidence of access controls, encryption, and monitoring. Structural enforcement of identity, encryption, and logging generates that evidence automatically.
- ISO 27001 calls for continual improvement of an information security management system. Policy as code and drift detection provide the ongoing verification that standard expects.
- PCI DSS requires strict controls over cardholder data environments, including network segmentation and access restriction. Structural network isolation and least-privilege access map directly to these requirements.
- HIPAA requires safeguards over protected health information, including access logging and encryption. Structural enforcement of these controls reduces the risk of a gap going unnoticed between assessments.
- FedRAMP expects continuous monitoring as part of its baseline. Organizations already building toward structural compliance are closer to meeting this expectation than those relying on periodic checklists.
- cATO takes this further in federal environments, replacing multi-year ATO reauthorization with ongoing automated monitoring and evidence collection. Organizations with structural controls already in place tend to be much closer to cATO readiness than those working from periodic reviews.
Structural controls don’t replace these frameworks, but they do make the frameworks easier to satisfy on an ongoing basis.
Continuous Compliance as an Engineering Discipline
Once controls are enforced structurally and policies are defined as code, maintaining compliance stops being an event that a separate team schedules once or twice a year. Instead, it’s a central part of how infrastructure is built and maintained.
- Compliance requirements get written directly into infrastructure templates, alongside performance and security requirements
- Engineering teams can see compliance status as a live indicator, the same way they track uptime or error rates
- Formal audits become a confirmation of what’s already true.
- Gaps get caught and closed as they appear, instead of accumulating until the next review
A Rough Maturity Model
Most organizations sit somewhere along this spectrum:
- Manual and periodic: Compliance is checked during scheduled reviews. Between reviews, there’s little visibility into whether controls are still in place.
- Automated but reactive: Some controls are automated, and monitoring tools flag issues after they occur. Response still depends on someone noticing and acting on an alert.
- Continuously enforced: Controls are built into the infrastructure and deployment pipeline. Non-compliant changes are blocked or corrected automatically, and compliance status is visible at any time.
Moving from one stage to the next doesn’t happen all at once, and it doesn’t need to.
Ownership Shifts
This model changes who’s responsible for compliance efforts every day. A compliance function may still own reporting and framework interpretation, but platform and engineering teams become responsible for building and maintaining the controls themselves. That shift usually means compliance requirements need to be understood early in the design process.
How to Measure Continuous Compliance
Structural compliance is easier to justify internally when it’s tied to numbers leadership wants to know about.
- Time to detect a misconfiguration: How long does it take between a control failing and someone knowing about it?
- Percentage of controls enforced versus manually checked: A rising number here reflects real progress toward structural enforcement.
- Time to remediate drift: Once an issue is detected, how quickly does the system or the team correct it?
- Audit preparation time: A drop in the hours spent gathering evidence before an assessment is one of the clearest signs the shift is working.
These metrics also give engineering and compliance teams a shared language, which tends to reduce friction between the two.
Building the Internal Case
Structural compliance is as much a budget conversation as a technical one. Getting it funded usually means translating engineering benefits into terms a CFO or board can act on.
Frame the Exposure
Most compliance conversations focus on the cost of implementing new controls. A more useful framing starts with the cost of the current gap.
- Calculate how much time typically passes between when a control fails and when anyone would notice
- Identify what data or systems would be exposed during that window
- Translate that exposure into terms leadership already tracks, such as potential breach costs, regulatory penalties, or client contract requirements
Quantify the Efficiency Gain
Audit preparation consumes a surprising amount of engineering and compliance time, and most of that time is spent gathering evidence that structural enforcement would generate automatically.
- Track hours spent preparing for the last two or three external audits
- Break down how much of that time went into manual evidence collection versus actual remediation
- Use that breakdown to estimate what a continuously enforced environment would save
Use the Maturity Model as a Reference Point
Showing leadership where the organization currently sits (whether that’s manual and periodic, automated but reactive, or continuously enforced) gives the conversation a shared reference point. It also makes the next step concrete rather than open-ended, since the path from one stage to the next can be described in specific, achievable terms.
Where This Effort Can Break Down
Treating Policy as Code as a One-Off Project
Writing policies into code is often approached as a discrete initiative with a defined end date. Infrastructure and regulatory requirements keep changing after that point.
- Policies need scheduled review cycles, similar to how application code gets revisited as requirements shift
- New services or environments introduced after the initial rollout need to be brought under the same enforcement, or they quietly become exceptions
- A policy that made sense at launch can become outdated within months as the underlying infrastructure evolves
Overly Restrictive Guardrails
Strict enforcement creates friction, and friction pushes engineers toward workarounds.
- Blocking every possible edge case can slow down legitimate work that doesn’t actually pose a risk
- Engineers under deadline pressure will find ways to bypass controls that feel like obstacles rather than safeguards
- A workaround that becomes routine defeats the purpose of the control entirely
Guardrails work best when they’re built with input from the engineers who have to work within them, rather than designed in isolation by a compliance or security team.
Trying to Convert Everything at Once
A full migration to structural enforcement across every control, every environment, and every team at the same time is difficult to execute well.
- Prioritize the controls tied to the highest risk or the most sensitive data first
- Treat each control area as its own project with its own timeline
- Use early wins to build the internal support needed for later phases
Take a Practical Starting Point
Moving toward structural compliance doesn’t require rebuilding an entire environment at once. A staged approach tends to work better than a single sweeping initiative.
1. Assess What’s Currently Manual
Start by mapping which controls rely on periodic human review today.
- List every control currently verified through a manual audit or spreadsheet
- Flag which of those controls could realistically be enforced through configuration
- Rank them by risk, prioritizing controls tied to sensitive data or regulated systems
2. Address Identity and Access
Access controls are often the fastest area to show measurable improvement.
- Review current IAM policies for standing access that should be time-bound
- Identify accounts or roles with permissions broader than their actual use requires
- Set up automated deprovisioning for roles tied to specific projects or timelines
3. Confirm Encryption Defaults
Encryption gaps are often inconsistent rather than absent entirely, which makes them easy to miss during a standard review.
- Check whether encryption at rest and in transit is enforced by default in every environment
- Review key management practices for rotation schedules and expiry handling
- Remove the ability to provision unencrypted storage or transport wherever possible
4. Centralize and Secure Logging
Logging is frequently the control with the biggest gap between what’s assumed and what’s actually happening.
- Confirm logs are centralized rather than scattered across individual services
- Verify that logs are immutable and retained according to current regulatory requirements
- Set up real-time alerting for anomalous access patterns
5. Convert One Control to Policy as Code
Rather than attempting a full migration, select a single control area as a starting project.
- Choose an area with clear, well-understood requirements
- Define the policy in code and integrate it into the deployment pipeline
- Use the results to refine the approach before expanding to additional controls
Stop Leaving Gaps Between Reviews
The gap between audits is a reflection of how compliance has traditionally been treated: something checked rather than something built.
Infrastructure that enforces its own controls doesn’t need to wait for the next review to prove it’s secure, because it’s secure by design, every day between audits and during them.
SMS has spent years applying federal-grade security measures and compliance standards to complex cloud environments. If your organization is looking to move compliance from a periodic exercise to something engineered into the infrastructure itself, we can help map out what that looks like for your environment.
