Who is accountable for cloud security and compliance when public sector workloads are moved to AWS?

Why This Matters for Security Teams

For public sector workloads, cloud migration changes the operating model, not the accountability model. The organisation still owns compliance evidence, data protection, identity governance, and privileged access decisions, even when AWS provides secure infrastructure and partners assist with implementation. The common mistake is assuming a shared responsibility label transfers risk. It does not. NIST’s Cybersecurity Framework 2.0 is clear that governance and risk oversight remain internal functions, while NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives shows how auditability depends on visible ownership of non-human identities and secrets. In practice, many security teams discover the accountability gap only after an audit request, incident review, or regulator inquiry has already exposed missing evidence.

How It Works in Practice

Accountability in AWS environments is usually divided across the cloud provider, implementation partners, and the public sector organisation. AWS is responsible for the security of the cloud, while the organisation remains responsible for security in the cloud, including access control, logging, classification, retention, key management, and compliance validation. That means the agency must define who approves access, who reviews privileged activity, and who can produce evidence that controls are operating effectively.

Practically, this is a governance and identity problem as much as a platform problem. A mature model uses workload identity, short-lived credentials, and documented approval paths so that every service, automation, or agent can be traced to a controlled business purpose. The SPIFFE workload identity specification is useful here because it treats workload identity as a cryptographic primitive rather than an administrative afterthought. NHIMG’s Guide to SPIFFE and SPIRE maps that idea to real operational identity lifecycles, which matters when cloud resources are ephemeral and audit trails must be reconstructable after the fact.

• Define accountable owners for each control domain: identity, logging, encryption, vulnerability management, and evidence collection.
• Use least privilege and just-in-time access for both humans and non-human identities.
• Require control testing before migration, not after go-live.
• Retain evidence that proves access reviews, policy enforcement, and exception handling were performed.
• Ensure partners can operate only within contracts and technical boundaries approved by the organisation.

The strongest programmes also align migration decisions to control frameworks such as NIST SP 800-53 Rev 5, the CSA Cloud Controls Matrix, and internal policy-as-code rules so compliance is tested continuously rather than assembled during audits. These controls tend to break down when agencies inherit legacy admin sprawl, because shared accounts and undocumented exceptions make it impossible to prove who actually owns each control.

Common Variations and Edge Cases

Tighter cloud governance often increases delivery overhead, requiring organisations to balance migration speed against assurance depth. That tradeoff is especially visible in public sector environments that use managed services, cross-agency landing zones, or third-party integrators. Best practice is evolving, but there is no universal standard for how much operational authority should be delegated to a provider or partner without weakening accountability.

One edge case is when service teams assume a vendor attestation replaces local control validation. It does not. Another is when compliance is treated as a one-time migration gate instead of a living obligation tied to identity lifecycle, logging, and access review. For workloads with automation, service accounts, or agentic AI, the risk rises further because those identities can act faster and more broadly than human operators. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both reinforce the same practical lesson: ownership must follow the workload, not the infrastructure label.

For evidence-heavy regimes, current guidance suggests combining internal control ownership with external assurance reports, but never treating external assurance as a substitute for internal accountability. When agencies cannot show who approved privileged access, who rotated secrets, and who reviewed exceptions, the compliance gap becomes an operational risk rather than a paperwork issue. Public sector cloud programmes break down fastest when responsibility is split by contract, but control execution is split by assumption.

Related resources from NHI Mgmt Group

• Who is accountable when a cloud security platform is used for sensitive government workloads?
• How should public sector organisations evaluate identity security controls for cloud services under GovRAMP or similar frameworks?
• Who is accountable for governing third-party, non-employee, and machine access in public sector cloud environments?
• Who is accountable for container image compliance when third-party images are used across cloud workloads?