Cloud Audit Checklist

STANDARD OPERATING PROCEDURE: Enterprise Cloud Audit Execution

Document ID: SOP-TR-OPS-4092
Effective Date: October 24, 2023
Version: 4.2
Review Cadence: Semi-Annual
Target Audience: Cloud Security Engineers, Compliance Officers, DevOps Leads, and Chief Operations Architects

---

1. Executive Summary & Scope

1.1 Purpose

This Standard Operating Procedure (SOP) defines the mandatory, repeatable framework for executing comprehensive security, compliance, and architectural audits across all multi-tenant and single-tenant cloud environments (AWS, Azure, GCP) managed by Template Registry.

1.2 Operational Boundaries

The procedures herein apply strictly to production, staging, and development infrastructure layers. This includes Identity and Access Management (IAM), network topologies, storage persistence buckets, cryptographic key lifecycles, and container orchestration clusters. Excluded from this scope are local developer workstations and third-party SaaS applications not directly integrated into the core pipeline infrastructure.

1.3 Regulatory Standards

All audit procedures are benchmarked against and engineered to maintain compliance with:

• SOC 2 Type II (Trust Services Criteria: Security, Availability, Confidentiality)
• ISO/IEC 27001:2013/2022 (Information Security Management Systems)
• PCI-DSS v4.0 (Payment Card Industry Data Security Standard - where applicable)
• GDPR / CCPA (Data Privacy and Protection mandates)

---

2. Prerequisites & Tool Requirements

2.1 Minimum Access & Authorizations

• IAM Permissions: ReadOnlyAccess, SecurityAudit, and custom cross-account audit roles mapped to the auditing administrative principal.
• Privileged Escalation: Break-glass access protocols must be verified and on standby via the Privileged Access Management (PAM) system.

2.2 Software & Toolchain Stack

• CLI Utilities: aws-cli (v2.13+), az-cli (v2.50+), gcloud (v440.0+)
• Infrastructure as Code (IaC) Scanners: Checkov (v3.0+), Tfsec (v1.28+), KICS
• Container & Vulnerability Scanners: Trivy (v0.45+), Scout Suite (v5.12+)
• Secret Management CLI: HashiCorp Vault CLI or cloud-native secrets manager SDKs

---

3. Roles & Responsibilities (RACI Matrix)

---

4. Step-by-Step Operational Procedure

Phase 1: Pre-Audit Discovery and Scope Verification

• 1.1 Confirm the audit perimeter by cross-referencing the active Configuration Management Database (CMDB) with active cloud resource inventories.
• 1.2 Generate an automated asset map using Scout Suite or cloud-native resource graph tools to identify unmanaged or rogue infrastructure deployments.
• 1.3 Verify that read-only API access tokens and cross-account IAM trust relationships are functioning and scoped down to least-privilege parameters.
• 1.4 Notify the Incident Response and Security Operations Center (SOC) teams regarding the initiation of high-volume read operations to prevent false-positive alert generation.

Phase 2: Identity and Access Management (IAM) Evaluation

• 2.1 Audit all root/master account access; verify that multi-factor authentication (MFA) is hardware-backed and that zero long-term access keys exist.
• 2.2 Execute automated parsing of IAM policies to detect wildcard permissions ("Action": "*", "Resource": "*") attached to production execution roles.
• 2.3 Review human user accounts; cross-reference active directory directories to ensure offboarded personnel accounts are permanently disabled or deleted.
• 2.4 Verify that programmatic access keys older than 90 days have been automatically rotated or invalidated in accordance with security policy.
• 2.5 Confirm that cross-account assumptions enforce strict External ID conditions and conditional source IP restrictions where applicable.

Phase 3: Network Topology and Perimeter Defense Assessment

• 3.1 Inspect all Virtual Private Clouds (VPCs/VNets) to ensure public subnets are strictly isolated to load balancers and edge proxies.
• 3.2 Audit Security Groups and Network Access Control Lists (NACLs) for open administrative ingress ports (e.g., SSH/22, RDP/3389, Database Ports) originating from 0.0.0.0/0.
• 3.3 Verify that Flow Logs (VPC Flow Logs / Azure Network Watcher) are enabled, centralized, and actively streaming to immutable storage buckets.
• 3.4 Confirm transit encryption status across all internal service-to-service communications (mTLS enforcement via service mesh).
• 3.5 Validate DNS security configurations, including DNSSEC deployment and route table propagation integrity.

Phase 4: Data Persistence, Encryption, and Backup Auditing

• 4.1 Enforce public access block configurations across all object storage buckets (S3, Azure Blob, GCS).
• 4.2 Validate that all data-at-rest across relational databases, block storage, and object stores is encrypted using customer-managed keys (CMK) via KMS/Key Vault.
• 4.3 Inspect KMS key policies to ensure key rotation is active (annual automated rotation) and administrative boundaries are strictly enforced.
• 4.4 Verify database snapshot replication schedules, encryption state of backups, and cross-region recovery point objectives (RPO).
• 4.5 Execute a sample data restoration drill from an immutable backup point to validate recovery mechanisms.

Phase 5: Logging, Monitoring, and Governance Validation

• 5.1 Ensure centralized audit logging (CloudTrail, Activity Logs, Cloud Audit Logs) is active in all regions, globally aggregated, and integrity-validated.
• 5.2 Validate SIEM ingestion pipelines (Splunk, Datadog, ELK) to ensure zero log-drop metrics over the preceding 30-day window.
• 5.3 Review real-time alerting rules for high-risk anomalies, including unauthorized API calls, security group modifications, and IAM policy alterations.
• 5.4 Check Cloud provider compliance dashboard scores (AWS Security Hub, Microsoft Defender for Cloud) and log baseline drift.

---

5. Quality Assurance & Verification Criteria

5.1 Audit Acceptance Benchmarks

An operational audit is designated as successfully passed when the following criteria are met:

• Critical Vulnerabilities: Zero (0) unmitigated critical-severity findings. All critical items must be resolved within 24 hours.
• High Vulnerabilities: Maximum tolerance of two (2) high-severity findings, provided an active remediation ticket with an SLA under 7 days is assigned.
• Compliance Drift: Configuration drift against the baseline CIS benchmarks must not exceed 2%.

5.2 Verification Checklist Sign-Off

• Automated IaC and CSPM scan reports archived to secure compliance repository.
• Manual verification logs signed by the Cloud Security Engineer.
• Executive summary report generated and routed to the Chief Operations Architect.

---

6. Practical Troubleshooting Scenarios

Scenario A: Orphaned Administrative Access Keys Discovered During IAM Audit

• Symptom: Scout Suite flags an active programmatic access key belonging to an external contractor whose contract terminated 6 months prior, bypassing standard IAM cleanup workflows.
• Immediate Corrective Action Protocol:
  1. Immediately deactivate (do not delete) the access key via CLI/Console to preserve evidence: aws iam update-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive --user-name [Username].
  2. Pull CloudTrail logs for the preceding 7 days filtered by the compromised AccessKeyId to assess potential exfiltration or unauthorized data access.
  3. Notify the Incident Response Lead and initiate an internal security review to determine if lateral movement occurred.
  4. Permanently delete the access key and user profile post-investigation sign-off.

Scenario B: Storage Bucket Public Access Policy Drift

• Symptom: A periodic Checkov scan reports a critical compliance failure: a primary customer data bucket has had its public access block disabled by an automated deployment script.
• Immediate Corrective Action Protocol:
  1. Re-enable the cloud-provider-level Public Access Block immediately via CLI/API.
  2. Review the bucket access policy JSON for explicit Principal: "*" declarations granting s3:GetObject.
  3. Inspect the associated CI/CD pipeline run logs that executed the deployment to identify the commit responsible for the policy override.
  4. Revert the IaC manifest commit, open an emergency change ticket, and enforce a repository branch protection rule requiring security team approval for storage policy modifications.