IT (HOSTED, CLOUD, AND SaaS) SECURITY STANDARD

Owned Data Center · Leased Facility · IaaS · PaaS · SaaS

Table of Contents

1. Purpose and Scope
2. CERG Roles in Hosted and Cloud Environments
3. GOVERN, Cloud Program Foundation and Shared Responsibility
4. IDENTIFY, Visibility Across Estates
5. PROTECT, Architecture, Identity, and Data
6. DETECT, Cloud-Native and Cross-Estate Monitoring
7. RESPOND, Containment Without Crossing Tenant Boundaries
8. RECOVER, Resilience in Multi-Tenant Environments
9. Training and Personnel
10. Regulatory and Framework Alignment Summary
11. Exceptions and Escalation
12. Document Control

1. Purpose and Scope

This standard implements the foundational principles established in CERG-POL-001 for information technology assets hosted in owned data centers, leased / colocation facilities, infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS), and software-as-a-service (SaaS) environments. It defines specific, measurable security requirements that apply regardless of whether the underlying infrastructure is owned, leased, rented, or consumed as a service.

The intent is durable: as the organization continues to shift workloads between owned, hybrid, and fully cloud-native models, the security obligations do not change, only the implementation specifics do. This standard makes those implementation differences explicit while keeping the underlying control intent constant.

1.1 Scope

This standard applies to:

• All applications, services, and data hosted in organization-owned data centers
• All systems housed in leased / colocation facilities, regardless of who provides the physical security
• All IaaS workloads (e.g., AWS EC2, Azure VMs, GCP Compute, private cloud)
• All PaaS services consumed by the organization (e.g., managed databases, container platforms, serverless functions)
• All SaaS applications used to process organizational data, including productivity, collaboration, HR, finance, ITSM, and security tooling
• All hybrid integrations between the above, including identity federation, VPN, ExpressRoute / Direct Connect, and API integrations
• All personnel and third parties with administrative or privileged access to in-scope systems

Note on OT and BES Cyber Systems

Grid and control system environments are governed by CERG-STD-OT-001. Where an enterprise IT system has direct or indirect connectivity to an OT environment, both standards apply, and the more stringent requirement controls.

1.2 The Shared Responsibility Reality

Cloud and SaaS providers operate under a shared responsibility model. The provider is accountable for security of the cloud, physical facilities, hypervisor, base platform, and the organization remains accountable for security in the cloud, data, identity, configuration, application logic, and access. Outsourcing the workload does not outsource the accountability.

The Shared Responsibility Trap

The single most common cause of cloud-related incidents is not a provider failure, it is a customer misunderstanding of which side of the line a given control sits on. Every cloud or SaaS service in use must have a documented shared responsibility mapping. Where the mapping is ambiguous, the organization assumes the obligation until the provider documents otherwise in writing.

1.3 Relationship to Parent Policy

This standard is subordinate to CERG-POL-001. It implements specific requirements; it does not limit any principle established in that policy. Where this standard is silent, the policy governs. Exceptions follow the process defined in CERG-POL-001 Section 7.

2. CERG Roles in Hosted and Cloud Environments

The three CERG pillars operate across all hosted and cloud estates with the same structure as on-premises IT, with adaptations that reflect the operating model of each environment.

The “Cloud Is Just Someone Else’s Computer” Fallacy

Cloud and SaaS are not a free pass on security obligations, but they also are not equivalent to on-premises systems. Treating a SaaS app as “out of scope because the vendor handles security” produces real, exploitable gaps. Treating an IaaS workload as just a virtual machine ignores the cloud control plane, often the most attractive attack surface. CERG treats each environment on its own terms, with controls calibrated to the actual operating model.

3. GOVERN: Cloud Program Foundation and Shared Responsibility

3.1 Approved Provider and Service Catalog

The organization shall not consume cloud or SaaS services that have not been assessed and approved through CERG. Shadow IT, services procured outside this process, is one of the most material sources of unmanaged risk in modern enterprises.

3.2 Data Classification and Placement

Where data lives determines what controls apply. Every workload and SaaS tenant shall be mapped to a documented data classification.

3.3 Tenancy, Account, and Subscription Governance

Cloud accounts and SaaS tenants are control boundaries. They are governed, not arbitrarily provisioned.

4. IDENTIFY: Visibility Across Estates

4.1 Inventory and Configuration Visibility

4.2 Vulnerability and Configuration Drift Identification

5. PROTECT: Architecture, Identity, and Data

5.1 Identity and Access

Identity Is the New Perimeter

In cloud and SaaS, traditional network boundaries are advisory at best. Identity, who is making this API call, from where, on what device, is the actual enforcement point. Identity controls in cloud environments must be treated with the same operational priority as firewall rules were in the data-center era.

5.2 Network and Architecture

5.3 Data Protection

5.4 Hardening and Secure Build

| Tier 2 SaaS (Restricted/CUI data) shall enforce: SSO via IdP, phishing-resistant MFA for admin, DLP policies, audit log export to SIEM, admin role review quarterly, tenant baseline scan (CIS / vendor). | Tier 2 SaaS | Engineering / Risk | NIST 800-53 IA-2, AC-2, CM-6, AU-2 · CIS SaaS Benchmarks | | Tier 3 SaaS (Internal data, narrow access) shall enforce: SSO via IdP, MFA for admin, admin role review semi-annually, tenant baseline scan annually. | Tier 3 SaaS | Engineering / Governance | NIST 800-53 IA-2, AC-2 · CIS SaaS Benchmarks | | Shadow IT discovery: SSPM / CASB / IdP log analysis shall run continuously. Unapproved SaaS with organizational data triggers 30-day remediation or block. | All SaaS | Risk / Governance | NIST 800-53 CM-8, CA-7 | | OAuth / third-party app grants in Tier 1/2 SaaS shall be inventoried, risk-ranked, and reviewed quarterly. High-risk grants (broad scopes, external publishers) require CISO approval. | Tier 1/2 SaaS | Engineering / Risk | NIST 800-53 AC-21 · CSA CCM IAM-13 |

5.5 SaaS Tenant Hardening Baselines

Each Tier 1 SaaS tenant shall maintain a documented baseline covering:

Baseline drift detected by SSPM → finding in PRC-VM-001 pipeline → remediation per SLA. Baseline changes require Engineering approval and evidence update.

6. DETECT: Cloud-Native and Cross-Estate Monitoring

6.1 Logging

6.2 Detection Engineering

7. RESPOND: Containment Without Crossing Tenant Boundaries

Cloud Response Has Different Rules

Response actions in cloud environments operate inside a multi-tenant control plane owned by the provider. Containment that would be straightforward on-premises, pulling a cable, isolating a VLAN, must be executed through provider APIs and with awareness of shared responsibility limits. Forensic acquisition in cloud and SaaS depends on what the provider exposes. Plans must be built around those realities, not against them.

7.1 Cloud and SaaS Incident Response

8. RECOVER: Resilience in Multi-Tenant Environments

8.1 Recovery Planning

8.2 Backup Testing and Restoration

9. Training and Personnel

10. Regulatory and Framework Alignment Summary

11. Exceptions and Escalation

No control in this standard may be waived without a documented exception. Exceptions to controls supporting SOX ITGC, CMMC, or Restricted-data handling carry additional obligations.

12. Document Control

Revision History

Review Triggers

This standard shall be reviewed annually and upon any of the following triggering events:

• Material change to the organization’s cloud or SaaS estate, new platform adoption, major migration, or significant provider consolidation
• Release of materially updated provider shared-responsibility documentation
• Significant cybersecurity incident affecting any in-scope cloud or SaaS system
• Changes to NIST 800-53, 800-171, CSA CCM, or SOX ITGC guidance that materially affect requirements herein
• Direction from the CISO, internal audit findings, or external regulatory examination

Governance owns this document. The Governance Pillar Leader (Enterprise IT/Cloud) is responsible for initiating reviews, managing the revision cycle, and obtaining CISO approval for all changes.

Related Documents

Source: standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md · Download .md · View on GitHub