Cloud security compliance is one of the most-discussed topics in public-sector cloud adoption, and one of the most consistently misunderstood. The shared responsibility model is well-documented, but the operational implications of what shared responsibility actually means in practice produce gaps that show up in audits, incidents, and procurement reviews.
This post is about what cloud security compliance looks like operationally for federal agencies, state and local governments, higher education institutions, and healthcare organizations running workloads in AWS or Azure.
What the Cloud Provider's Authorization Actually Covers
When AWS or Azure achieves FedRAMP authorization (Moderate or High), the authorization covers specific services within a documented boundary. The cloud provider's responsibilities include physical security of data centers, network infrastructure, hypervisor security, and operational security of the managed services within the authorization.
What the authorization does not cover: anything the institution configures or operates within the cloud environment. The application layer, the data layer, identity and access management configuration, network configuration, monitoring and logging operation, and incident response are all the institution's responsibility.
The structural confusion: institutional buyers sometimes assume that running on a FedRAMP-authorized cloud automatically makes the workload FedRAMP-compliant. It does not. The cloud provider's authorization is the foundation; the institution's authorization (System Security Plan, control implementation, continuous monitoring) sits on top of it.
What the Institution's Authorization Has to Cover
For any workload subject to a compliance framework, the institution has to document and operate the application-layer controls that the framework requires. The specific controls vary by framework (NIST 800-53, FedRAMP, HIPAA, FERPA, HECVAT, ISO 27001), but the categories are consistent.
Identity and access management. Who can access the workload, under what conditions, with what authentication strength, and how access is reviewed. For public-sector workloads, this typically means federation through the institutional IdP, MFA enforcement at the IdP layer, role-based access aligned to the institution's authorization model, and documented access reviews on a defined cadence.
Configuration management. What configuration the workload runs in, how changes are reviewed and approved, and how configuration drift is detected and remediated. Cloud-native tooling (AWS Config, Azure Policy) handles much of this when configured for it.
Logging and monitoring. What events the workload logs, where logs are aggregated, how long they are retained, and how anomalies are detected. CloudTrail for AWS, Azure Monitor for Azure, SIEM aggregation for cross-environment visibility.
Incident response. What constitutes an incident, who responds, how response is documented, and how lessons learned feed back into the operational practice. The framework typically requires documented procedures, periodic testing, and audit-ready evidence of response activity.
Backup and recovery. What gets backed up, how often, where backups are stored, how recovery is tested, and how recovery time and recovery point objectives are validated. Backups that have not been restored end-to-end are not backups; they are evidence of intent.
What "Continuous Compliance" Actually Looks Like
Traditional compliance practice treats authorization as an event: the auditor reviews documentation, the institution receives the authorization, and the documentation gets filed for the next audit cycle. This pattern fails in cloud environments because the workload changes continuously and the documentation drifts from operational reality.
Continuous compliance is the operational alternative: configuration is enforced through code, drift is detected automatically, evidence is generated as a side effect of normal operations, and the audit cycle pulls from existing artifacts rather than triggering separate documentation work.
The pattern that produces continuous compliance:
- Policy-as-code that enforces configuration baseline through cloud-native policy engines (AWS Config Rules, Azure Policy, Service Control Policies)
- Logging by default at the cloud provider level (CloudTrail, Azure Activity Logs) plus application-layer logging
- Drift detection automation that flags configurations deviating from the authorized baseline
- Compliance documentation generated from operational artifacts rather than maintained separately
- Periodic operational reviews that catch drift before it accumulates to audit-finding levels
This pattern requires investment in operational tooling and practice. For institutions where the investment is not feasible, partner engagement under managed cloud operations provides the operational depth at a level the institution can sustain.
Where Compliance Failures Originate
Three failure modes produce most of the cloud compliance findings we see in public-sector audits.
Identity drift. Privileged role assignments accumulate over time. Service principals proliferate without lifecycle management. Local IAM users that were supposed to be temporary become permanent. The aggregate access posture exceeds what any single review can audit comprehensively.
Configuration drift in security baselines. Security group rules added for one-time troubleshooting and never removed. Encryption defaults weakened for specific workloads and not restored. Public S3 bucket policies that were intentional for one use case applied accidentally to other buckets.
Documentation that lags operational reality. The authorization package documents the workload as it was at authorization time. The workload has been changing since then. The documentation is stale, the operations team operates the current state, and the audit finds the gap between the two.
The structural fix in all three: operational tooling that detects drift automatically and operational practice that responds to drift before it becomes an audit finding.
What Mature Public-Sector Cloud Compliance Looks Like
The institutions that operate cloud compliance well share visible characteristics:
- Authorization documentation is generated from operational artifacts, not maintained separately
- Configuration drift is detected and remediated within days, not at audit time
- Identity hygiene is a standing operational practice with documented review cadence
- Incident response is exercised periodically with documented evidence
- Compliance findings are infrequent and address evolving threats rather than accumulated drift
This is not exotic practice. It is mature operational discipline applied to cloud-shaped problems. We covered the broader public-sector cloud governance challenges in Cloud Governance for Public Sector and the AWS-specific shared responsibility patterns in The AWS Shared Responsibility Gap.
Frequently Asked Questions
Does FedRAMP authorization of the cloud provider mean my workload is FedRAMP-compliant?
No. The cloud provider's authorization covers specific services within a documented boundary. Your workload's authorization is separate and covers the application-layer controls that you configure and operate. Both authorizations have to be in place for the workload to be FedRAMP-compliant.
What is the shared responsibility model in cloud security?
The cloud provider is responsible for security of the cloud (physical infrastructure, hypervisor, managed service security). The customer is responsible for security in the cloud (application configuration, identity, data, and the controls that depend on customer configuration). The boundary moves slightly depending on whether the workload uses IaaS, PaaS, or SaaS services.
How often should public-sector institutions test their cloud compliance posture?
Continuous monitoring is the operational baseline; explicit periodic review (quarterly or semi-annually) catches what continuous monitoring misses. Annual third-party assessments produce the audit evidence that frameworks like FedRAMP and SOC 2 require. The cadence is determined by the framework requirements, not by institutional convenience.
What is the cost of cloud compliance for public-sector workloads?
Variable, depending on the framework and the workload's complexity. The operational discipline of continuous compliance is meaningful but typically lower than the cost of remediating audit findings reactively. Institutions that underinvest in continuous compliance end up paying more in remediation work than they saved by skipping the operational practice.