A secure enterprise cloud deployment settles who owns which risks, defines infrastructure as reviewed code, tests every change automatically, centralizes identity and logging, and keeps monitoring configuration after launch. CISA's Cloud Security Technical Reference Architecture lays out this pattern for US federal agencies, and it transfers well to companies.
What is the CISA reference architecture?
The Cloud Security Technical Reference Architecture (version 2, June 2022) was written by CISA, the United States Digital Service and FedRAMP. It has three parts: the shared risk model for cloud adoption (FedRAMP), how to build a cloud environment (USDS) and how to monitor it through cloud security posture management (CISA). CISA's page now labels it archived content that may not reflect current policy, so treat it as a well-organized reference, not a current mandate, and check for newer agency guidance.
It was written around Executive Order 14028 and zero trust, but says plainly that migrating to the cloud does not automatically give you a zero trust architecture. Cloud makes it possible, and still needs configuration and management to deliver visibility over assets, users and data.
Who is responsible for what?
The document says services span IaaS, PaaS and SaaS, which differ in who is responsible for each layer of the system, and that it is imperative to confirm which services and functions your vendors provide and do not provide. Even with an approved provider, it notes that correct configuration, identity and access roles, and protecting data with encryption keys from a key management service may be the responsibility of your own DevSecOps teams or administrators.
How should you build the environment?
Three practices stand out in the build guidance.
Infrastructure as code (IaC). Defining infrastructure in machine-readable files lets teams review changes before they are checked in, apply patches across many instances quickly and avoid the drift of hand-patched servers. The paper lists automated compliance checks, such as enforcing encryption at rest for storage, and automated deployment of identity policies. It also warns that IaC can introduce vulnerabilities like any other code, so monitor it for misconfigurations and audit changes to production.
Automated security testing. Add application security testing to the pipeline: static analysis for common coding issues such as SQL injection, plus dynamic testing of how the code works together. The paper calls this one layer of defense and notes that manual expert analysis, third-party testing, disclosure programs and bug bounties work alongside it.
Centralized services. Deploy centrally integrated security services where you can, since fewer separate instances reduce attack surface. Centralized logging makes local logs redundant, limits the impact of log deletion and shortens investigation time. Single sign-on is described as an ideal place to start on identity.
How do you keep it secure after launch?
The third part defines cloud security posture management (CSPM), for the purposes of the paper, as a continuous process of monitoring a cloud environment by identifying, alerting on and mitigating vulnerabilities, reducing risk and improving security. It notes that CSPM is defined differently by different parties, which is useful when you evaluate tools. The outcomes it lists include governance and compliance, standards and policies, privilege and identity access management, data protections, infrastructure and application protections, system health monitoring, and incident response and recovery.
A constructed example
A company moves its order system to a managed platform. In the first sprint they write the network, database and storage as code, and a pipeline check rejects a storage bucket defined without encryption. Every merge runs static analysis and a dynamic scan against a staging copy. Logs from the platform, the application and the identity provider flow to one place, and a new administrator account triggers an alert. Three months later a developer changes a firewall rule by hand in the console. The posture monitor flags the drift, and the team reverts it through code.
Common mistakes
- Treating a provider's compliance attestation as proof that your configuration is secure.
- Defining infrastructure as code but allowing manual console changes in production.
- Collecting logs without anyone reading them, or logs that the same administrators can delete.
- Skipping identity: service accounts and keys with broad rights and no owner.
How to check or apply this
- Write the responsibility split for each service model you use, with an owner for each item on your side.
- Put infrastructure in version control, require review, and block console changes in production, or detect and revert them.
- Add policy checks to the IaC pipeline for encryption, public exposure and logging.
- Add static and dynamic testing to every release pipeline, and fix findings before release.
- Send logs to a central store with separate access control, and alert on identity changes.
- Review configuration drift and access on a schedule, and test your recovery plan.
Safeguard works on the application side of a deployment: dependency and SBOM scanning, reachability analysis to rank findings and policies and gates for pull requests. It does not monitor cloud configuration or network traffic.
Quick check
Does moving to the cloud give me zero trust?
No. The CISA reference architecture says cloud enables zero trust but still requires configuration and management to get the visibility zero trust needs.
Why use infrastructure as code for security?
It makes changes reviewable and repeatable, allows automated compliance checks and reduces drift. The same paper warns it needs its own misconfiguration monitoring.
Sources
- CISA, Cloud Security Technical Reference Architecture, version 2 (June 2022; archived page)
- Cloud Security Technical Reference Architecture v2, PDF
Last reviewed: 18 October 2026.
