Cloud Security Posture Assessment: CIS Benchmarks, IAM Audits, and Vulnerability Scanning

Introduction

Cloud security posture assessment (CSPA) has become non-negotiable for any organization operating in AWS, Azure, GCP, or multi-cloud environments. According to Gartner's 2025 Cloud Security Outlook, 99% of cloud breaches through 2025 will result from preventable misconfigurations—not sophisticated zero-day exploits or advanced threats. The problem isn't complexity; it's visibility.

A security posture assessment evaluates your cloud infrastructure against industry frameworks (CIS Benchmarks, NIST, ISO 27001), identifies gaps and vulnerabilities, and creates a prioritized remediation roadmap. Done systematically, this 2-4 week assessment dramatically reduces your attack surface, achieves compliance faster, and prevents the $4.45M average cost of a data breach (IBM 2024).

This guide covers the complete cloud security posture assessment workflow across three critical stages:

1. Pre-Audit Planning & Scoping - Define objectives, stakeholders, and create resource inventory baseline
2. Cloud Security Posture Assessment - Evaluate IAM, network security, data protection, logging, and threat detection
3. Compliance & Governance Validation - Map findings to CIS, NIST, ISO 27001, PCI-DSS, HIPAA, GDPR, SOC 2

Why This Matters Now

Recent 2025 research reveals the urgency:

• 31% of APIs lack HTTPS encryption - Basic transport security still missing (API7.ai)
• Shadow IT proliferates - Undocumented resources in multi-cloud environments bypass security controls
• Configuration drift accelerates - Manual console changes override IaC definitions in 80%+ of organizations
• Compliance complexity increases - PCI-DSS 4.0, FedRAMP updates, GDPR enforcement intensifies scrutiny

This guide applies the AWS Well-Architected Framework Security Pillar, Azure Cloud Adoption Framework, and GCP Security Best Practices to provide a unified assessment methodology across all three major clouds.

---

Stage 1: Pre-Audit Planning & Scoping (1-2 days)

Objectives

Before diving into technical assessment, establish clear scope, align stakeholders, discover all cloud resources, and create baseline metrics for comparison.

Step 1.1: Define Audit Scope & Objectives

Critical Questions to Answer:

1. Which clouds are in scope? AWS accounts, Azure subscriptions, GCP projects, Oracle Cloud, hybrid on-premises?
2. How many environments? Development, staging, production, sandbox?
3. Which workloads? Web applications, databases, APIs, data lakes, ML pipelines, legacy systems?
4. Compliance drivers: PCI-DSS, HIPAA, GDPR, SOC 2, ISO 27001, FedRAMP, HITRUST?
5. Business context: Post-migration validation, M&A due diligence, annual audit, incident investigation, cost optimization tied to security?

Example Audit Charter:

AUDIT CHARTER: Cloud Infrastructure Security Assessment

Cloud Providers: AWS (8 production accounts, 5 dev accounts), Azure (3 subscriptions)
Workloads: E-commerce platform, customer data warehouse, ML training pipelines
Scope: All production and staging infrastructure
Out of Scope: Developer sandbox accounts, on-premises data centers
Compliance: PCI-DSS Level 1 (credit card processing), GDPR (EU customers), SOC 2 Type II
Timeline: 3-week audit + 4-week remediation
Success Criteria:
  - Zero critical security findings
  - 100% CIS Benchmark Level 1 compliance
  - 95%+ CIS Benchmark Level 2 compliance
  - All high-risk findings remediated within 30 days
  - Evidence package prepared for external SOC 2 auditors

Tool Recommendation: Start with our Cloud Security Self-Assessment (iCSAT) to get instant benchmark scores across AWS, Azure, and GCP. The iCSAT framework provides quick wins and identifies priority areas before the formal audit begins.

Step 1.2: Stakeholder Alignment & RACI Matrix

Establish clear roles and decision-making authority:

Stakeholder	Role	Responsibility
CISO / Chief Security Officer	Accountable	Final approval, risk acceptance, security policy decisions
Cloud Security Architect	Responsible	Technical audit execution, findings validation, remediation oversight
Platform Engineering Lead	Consulted	Infrastructure details, deployment patterns, remediation implementation
Compliance Officer	Consulted	Regulatory framework interpretation, audit evidence collection
Finance / FinOps Team	Consulted	Cost impact analysis, budget implications of remediation
DevOps/Engineering Teams	Informed	Remediation tasks, deployment changes, monitoring updates
Executive Sponsor	Accountable	Budget approval, strategic alignment, board reporting

Step 1.3: Cloud Resource Discovery

Create comprehensive baseline of all resources before detailed analysis.

AWS Discovery Tools:

• AWS Config - Continuous resource inventory, configuration changes, compliance tracking
• AWS Systems Manager Inventory - EC2 instances, software inventory, network configurations
• AWS Resource Groups Tagging API - Validate tag compliance across all resources
• AWS Cost Explorer - Identify all accounts, services, spending patterns
• Open-source: Prowler (240+ security checks), ScoutSuite, CloudMapper

Azure Discovery Tools:

• Azure Resource Graph - Query all resources across subscriptions at scale
• Azure Policy - Automated compliance assessment and remediation
• Azure Resource Manager - Complete infrastructure inventory
• Open-source: Azure-cli, Scorecards

GCP Discovery Tools:

• Cloud Asset Inventory - Real-time snapshot of all GCP resources
• Resource Manager API - Project and organization hierarchy
• GCP Recommender - Optimization and security suggestions
• Open-source: Forseti Security, GCP Policy Intelligence

Multi-Cloud Inventory Tools:

• Prisma Cloud (Palo Alto) - Unified security posture across AWS, Azure, GCP, Kubernetes
• CloudHealth (VMware) - Multi-cloud visibility and cost management
• Cloudanix - CIS Benchmark compliance across clouds

Key Inventory Data Points to Capture:

Identity & Access:
  - Total IAM users, roles, service accounts
  - Privileged account count (root, admins)
  - MFA adoption percentage
  - External identity federated accounts

Compute:
  - EC2/VM instance count and ages
  - Container registry and image count
  - Kubernetes clusters (nodes, pods, namespaces)
  - Lambda/Functions deployment count

Storage & Databases:
  - S3 buckets / Azure Storage accounts / GCS buckets
  - Database instances (RDS, Azure SQL, Cloud SQL)
  - Data warehouse resources (Redshift, Azure Synapse, BigQuery)

Networking:
  - VPC/VNet count, CIDR ranges
  - Security groups / NSGs / Firewall rules
  - NAT Gateways, Load Balancers
  - VPN tunnels, Direct Connect/ExpressRoute circuits

Compliance & Governance:
  - Encryption status (data at rest, in transit)
  - Logging service configuration (CloudTrail, Activity Logs, Cloud Logging)
  - Backup and disaster recovery setup
  - Resource tagging compliance percentage

Tool Recommendation: Use our Risk Matrix Calculator to document discovered findings with likelihood and impact scores aligned to NIST and ISO 27005 standards.

Step 1.4: Establish Baseline Metrics

Capture metrics before remediation for later comparison:

Security Baseline Metrics:

• IAM users with MFA status (target: 100% for console access)
• Publicly accessible resources count (S3 buckets, databases, VMs)
• Encrypted vs. unencrypted data stores
• CloudTrail/audit logging coverage across regions
• Active security group rules allowing 0.0.0.0/0 on sensitive ports

Compliance Baseline:

• CIS Benchmark compliance percentage (Level 1 and Level 2)
• Number of findings by severity (critical, high, medium, low)
• Encryption key rotation status
• Audit log retention compliance

Example Baseline Report:

Pre-Audit Baseline (AWS Account: 123456789012):
  IAM Security:
    Root account MFA: ✓ Enabled
    Console users without MFA: 23 users (18%)
    Access keys > 90 days old: 12 keys
    Root account access keys: 0 ✓

  Network Security:
    Security groups allowing 0.0.0.0/0 on port 22 (SSH): 14 groups
    Security groups allowing 0.0.0.0/0 on port 3389 (RDP): 8 groups
    Public RDS instances: 2 (CRITICAL)
    Public S3 buckets: 5 (11% of total)

  Data Protection:
    Encrypted EBS volumes: 87% (13 unencrypted)
    Encrypted S3 buckets: 92% (4 unencrypted)
    KMS key rotation: ✓ Enabled
    RDS encryption: 95% (1 unencrypted legacy instance)

  Logging & Monitoring:
    CloudTrail enabled: All regions ✓
    CloudTrail S3 bucket encrypted: ✓ Yes
    VPC Flow Logs: Partial (only 2 of 5 VPCs)
    CloudWatch log groups with retention: 65%

  CIS Benchmark Compliance:
    Level 1: 78% (142/150 controls)
    Level 2: 72% (85/115 controls)

Step 1.5: Communication Plan

Establish regular touchpoints:

Weekly Status Reports (All Stakeholders):

• Audit progress vs. timeline
• Critical/high findings requiring immediate attention
• Blockers and dependencies
• Estimated completion date

Daily Standups (Audit Team):

• What was completed yesterday?
• What's planned for today?
• Any blockers or questions?
• Resource needs

Executive Briefings:

• Week 1: Kickoff and scope confirmation
• Week 2: Mid-audit findings summary
• Week 3: Final audit results preview
• Post-audit: Remediation roadmap walkthrough and approval

---

Stage 2: Cloud Security Posture Assessment (3-5 days)

Objectives

Evaluate security controls across IAM, network security, data protection, logging, and threat detection aligned to cloud-native security frameworks.

Step 2.1: Identity & Access Management (IAM) Audit

IAM vulnerabilities are the leading cause of cloud breaches. Assess across three dimensions: authentication, authorization, and privilege escalation risk.

AWS IAM Assessment

Critical Authentication Checks:

1. Root Account Security

   • Root account has MFA enabled: Yes ✓ / No ✗
   • Root account has no active access keys: Yes ✓ / No ✗
   • Root account last used: >90 days ago: Yes ✓ / Within 30 days: ✗
   • Root account CloudTrail logging: Verify all API calls logged

2. User MFA Enforcement

   • Percentage of console users with virtual MFA: Target 100%
   • Percentage of console users with hardware MFA: Optional, higher security
   • Percentage with no MFA: Remediate immediately

3. Access Key Hygiene

   • Access keys older than 90 days: Rotate immediately
   • Access keys with no recent usage (90+ days): Disable or delete
   • Root account access keys exist: Critical finding

Authorization Analysis:

4. Principle of Least Privilege

   • Identify policies with "Action": "*" wildcards (overly permissive)
   • Identify policies with "Effect": "Allow" and "Principal": "*" (public access)
   • Review role trust relationships (cross-account, external account access)
   • Check for inline policies (centralize to managed policies)

5. Service Control Policies (SCPs)

   • SCPs defined at organization root: Yes ✓ / No ✗
   • SCP prevents disabling GuardDuty: Verify
   • SCP enforces MFA: Verify
   • SCP restricts root API access: Verify

Example Finding:

Finding: Excessive IAM Permissions
Severity: HIGH
Description: 14 IAM users have AdministratorAccess policy attached
  - Limited to 2 users (CISO, Cloud Architect)
  - Recommend: 12 users should use roles with specific permissions
  - Risk: Single compromised credential = full account access

Remediation:
  1. Remove AdministratorAccess from 12 users
  2. Create service-specific roles (EC2Manager, RDSAdmin, S3Editor)
  3. Enable CloudTrail logging for all policy changes
  4. Implement SCPs to prevent policy removal

Privilege Escalation Risk Detection:

6. Privilege Escalation Paths
   • Check if users can create new access keys: iam:CreateAccessKey
   • Check if users can attach policies: iam:PutUserPolicy
   • Check if users can assume roles with higher privileges
   • Check if users can create temporary credentials

Tools for AWS IAM Audit:

• AWS IAM Access Analyzer - Identifies external account access and public resources
• AWS Access Advisor - Shows permissions last used (refine privileges)
• Prowler - Open-source CIS-aligned IAM checks
• AWS CloudTrail - Audit trail of IAM permission changes

Azure IAM Assessment

Critical Checks:

1. Privileged Identity Management (PIM)

   • PIM enabled for Azure AD: Yes ✓ / No ✗
   • Global Admin accounts in PIM: Yes ✓ / No ✗
   • Just-in-time (JIT) access enforced: Yes ✓ / No ✗
   • PIM approval required: Yes ✓ / No ✗
   • PIM session duration: <4 hours recommended

2. Conditional Access Policies

   • MFA required for all users: Yes ✓ / No ✗
   • Trusted locations defined: Yes ✓ / No ✗
   • Legacy authentication blocked: Yes ✓ / No ✗
   • High-risk sign-ins blocked: Yes ✓ / No ✗

3. Azure AD Identity Protection

   • Risk-based policies configured: Yes ✓ / No ✗
   • Compromised accounts detected: Review findings
   • Sign-in risk alerts: Configured and monitored
   • MFA registration enforced: Yes ✓ / No ✗

4. Service Principals & App Registrations

   • Service principals with "Owner" role: High risk, remediate
   • Sensitive permissions (Mail.Read, Files.Read.All): Audit usage
   • Certificate/secret expiration: Monitor for expirations
   • Unused app registrations: Archive or delete

GCP IAM Assessment

Critical Checks:

1. Eliminate Primitive Roles

   • Owner role usage: Should be limited to service accounts, not users
   • Editor role usage: Replace with custom roles with specific permissions
   • Viewer role usage: Still overly permissive, use custom roles
   • Cloud Org Policy: Constraints prevent primitive role assignment

2. Service Account Management

   • Service accounts with no keys: Preferred, use Workload Identity
   • Long-lived service account keys: Security risk, prefer Workload Identity
   • Unused service accounts: Archive or delete
   • Service account impersonation: Audit who can impersonate

3. VPC Service Controls

   • Service perimeters defined: Yes ✓ / No ✗
   • Sensitive resources in perimeters: Cloud SQL, BigQuery, Cloud Storage
   • Ingress policies restrict external access: Yes ✓ / No ✗
   • Egress policies restrict data exfiltration: Yes ✓ / No ✗

4. Organization Policies

   • constraints/iam.disableServiceAccountKeyCreation: Enforced ✓
   • constraints/compute.requireShieldedVm: Enforced ✓
   • constraints/storage.uniformBucketLevelAccess: Enforced ✓

Multi-Cloud IAM Anti-Patterns (Flag These):

Anti-Pattern #1: Shared Credentials
  ✗ Entire team shares single AWS access key
  ✓ Each user has unique IAM credentials with MFA

Anti-Pattern #2: Long-Lived API Keys
  ✗ Service account key created 3 years ago, never rotated
  ✓ AWS: Use STS AssumeRole (temporary, 1-hour default)
  ✓ Azure: Use Managed Identities (automatic token refresh)
  ✓ GCP: Use Workload Identity (no service account keys)

Anti-Pattern #3: Wildcard Principals
  ✗ S3 bucket policy: "Principal": "*"
  ✗ Azure Key Vault: All users in tenant can access
  ✓ Restrict to specific roles, accounts, identities

Anti-Pattern #4: No Separation of Duties
  ✗ Same person: Admin + Developer + Deployer
  ✓ Separate roles: Admin (creates roles), Developer (uses roles), Deployer (applies roles)

Tool Recommendation: Use our Cybersecurity Maturity Assessment to benchmark IAM capabilities across People, Process, and Technology dimensions for a holistic improvement roadmap.

Step 2.2: Network Security Assessment

Network Segmentation Validation:

AWS VPC Assessment:

1. Architecture Review

   • VPC structure: Multi-tier (public, private, database subnets): Yes ✓ / No ✗
   • Public subnets: Only for load balancers, NAT Gateways
   • Private subnets: Application and database servers
   • Isolated subnets: No outbound Internet (for compliance-restricted workloads)

2. Security Group Analysis

   • Count security groups allowing 0.0.0.0/0 on SSH (port 22): Target 0
   • Count security groups allowing 0.0.0.0/0 on RDP (port 3389): Target 0
   • Count security groups allowing 0.0.0.0/0 on database ports (5432, 3306, 1433): Target 0
   • Security group rules with descriptions: Target 100% (enable triage)

3. Network ACL (NACL) Review

   • Overly permissive NACLs allowing all traffic: Tighten rules
   • Default NACLs (allow all): Review and restrict if needed

Azure Network Security Assessment:

1. Virtual Network (VNet) Design

   • VNet segmentation: Production, staging, development separated: Yes ✓ / No ✗
   • Subnets by tier (web, app, database): Yes ✓ / No ✗
   • Service endpoints enabled (Storage, SQL, Cosmos): Yes ✓ / No ✗

2. Network Security Group (NSG) Analysis

   • NSGs with rules allowing 0.0.0.0/0 on management ports: Target 0
   • NSG rules with descriptions: 100% required
   • Default deny rules in place: Yes ✓ / No ✗
   • NSG flow logs enabled: Yes ✓ / No ✗

3. Application Security Groups (ASGs)

   • Implemented for application-centric security: Yes ✓ / No ✗
   • Reduces NSG complexity: Compared to port-based rules

GCP Network Security Assessment:

1. VPC Network Design

   • Custom VPC (not default VPC): Yes ✓ / No ✗
   • Subnets by environment (prod, staging, dev): Yes ✓ / No ✗
   • VPC Flow Logs enabled: Yes ✓ / No ✗
   • Private Google Access enabled: Yes ✓ / No ✗

2. Firewall Rules

   • Firewall rules allowing 0.0.0.0/0 on SSH (port 22): Target 0
   • Firewall rules allowing 0.0.0.0/0 on RDP (port 3389): Target 0
   • Egress deny rules preventing data exfiltration: Yes ✓ / No ✗

3. VPC Service Controls

   • Service perimeters created: Yes ✓ / No ✗
   • Sensitive APIs/services in perimeters: Yes ✓ / No ✗
   • Ingress policies restrict external access: Yes ✓ / No ✗

Encryption in Transit:

Validate TLS/SSL enforcement across all protocols:

Protocol Checks:
  ✓ HTTPS required (TLS 1.2+): All endpoints
  ✓ TLS certificate valid: Check expiration dates
  ✓ Self-signed certificates: Remediate or whitelist
  ✓ VPN tunnels: IPsec encryption enabled
  ✓ Database connections: TLS enforced (require_secure_transport)
  ✓ Load balancer listeners: HTTPS for production

Step 2.3: Data Protection & Encryption

Encryption at Rest Assessment:

AWS:

• S3 buckets: Default encryption enabled (SSE-S3, SSE-KMS, SSE-C)?
• EBS volumes: All encrypted with KMS keys? (Cannot be enabled post-creation)
• RDS databases: Encryption enabled at instance creation?
• Secrets Manager: Secrets encrypted with AWS KMS?
• Backup/Snapshots: Encrypted to match source?

Azure:

• Storage accounts: Encryption enabled (Microsoft-managed or customer-managed keys)?
• Managed disks: Customer-managed encryption keys enabled?
• SQL Database: Transparent Data Encryption (TDE) enabled?
• Azure Key Vault: Secrets encrypted and access audited?

GCP:

• Cloud Storage: Default encryption (Google-managed) or customer-managed keys (CMEK)?
• Persistent Disks: Encrypted by default (validate CMEK for sensitive)?
• Cloud SQL: Encryption enabled at rest?
• Secret Manager: Secrets encrypted and access logged?

Key Management Audit:

KMS/Key Vault Review:
  1. Encryption keys documented: Yes ✓ / No ✗
  2. Key rotation enabled:
     - AWS KMS: Automatic annual rotation ✓
     - Azure Key Vault: 90-day rotation policy ✓
     - GCP: Customer-managed key rotation ✓
  3. Key access restricted:
     - Root/admin override: Disable if possible
     - Separation of duties: Key creator ≠ Key user
  4. Hardware Security Module (HSM):
     - Critical keys in CloudHSM/Dedicated HSM: Yes ✓ / No ✗
     - Cost-benefit: For compliance-critical systems only
  5. Key versioning enabled: Yes ✓ / No ✗
  6. Orphaned keys (no usage): Audit quarterly

Data Classification & Handling:

1. Sensitive Data Discovery
   • PII (Personally Identifiable Information): Names, emails, phone numbers, SSNs
   • PHI (Protected Health Information): Medical records, diagnoses
   • PCI (Payment Card Industry): Credit card numbers, CVVs
   • Financial data: Bank account numbers, transaction history

Tools:

• AWS Macie: Automatically discovers and classifies PII in S3
• Azure Purview: Data governance and discovery platform
• GCP Cloud DLP API: Sensitive data inspection and redaction

2. Data Loss Prevention (DLP) Policies

   • DLP rules prevent email/export of sensitive data: Yes ✓ / No ✗
   • Data classification labels applied: Yes ✓ / No ✗
   • Access controls tied to classification: Yes ✓ / No ✗

3. Backup & Disaster Recovery

   • Backup encryption matches source: Yes ✓ / No ✗
   • Backup retention periods documented: Yes ✓ / No ✗
   • Cross-region replication enabled: Yes ✓ / No ✗
   • Backup immutability (ransomware protection): Yes ✓ / No ✗
   • Recovery time objective (RTO) tested: Yes ✓ / No ✗
   • Recovery point objective (RPO) validated: Yes ✓ / No ✗

Step 2.4: Logging, Monitoring & Threat Detection

Audit Logging Validation:

AWS CloudTrail:

1. CloudTrail Configuration

   • CloudTrail enabled in all regions: Yes ✓ / No ✗
   • Multi-region trail enabled: Yes ✓ / No ✗
   • S3 bucket encrypted: Yes ✓ / No ✗
   • Log file validation enabled: Yes ✓ / No ✗
   • CloudTrail logs retention: >=90 days (PCI-DSS requirement)

2. Critical Events Logged

   • Root account API calls: Monitored
   • IAM policy changes: Monitored
   • EC2 instance launches/terminations: Monitored
   • Security group modifications: Monitored
   • KMS key usage: Monitored

Azure Activity Log:

1. Activity Log Configuration

   • Activity Log exported to Log Analytics: Yes ✓ / No ✗
   • Retention period: >=90 days
   • Diagnostic settings enabled for all resources: Yes ✓ / No ✗

2. Resource Monitoring

   • VM creation/deletion: Monitored
   • Network security group changes: Monitored
   • SQL database access attempts: Monitored
   • Storage account configuration changes: Monitored

GCP Cloud Logging:

1. Cloud Audit Logs Configuration

   • Admin Activity logs enabled: Yes ✓ / No ✗
   • Data Access logs enabled: Yes ✓ / No ✗ (high-volume, cost consideration)
   • System Event logs enabled: Yes ✓ / No ✗
   • Log retention: >=90 days

2. Centralized Log Aggregation

   • Logs exported to Cloud Storage/BigQuery: Yes ✓ / No ✗
   • Real-time analysis configured: Yes ✓ / No ✗

Threat Detection Enablement:

AWS GuardDuty & Security Hub:

GuardDuty Configuration:
  - Enabled in all regions: Yes ✓ / No ✗
  - S3 protection enabled: Yes ✓ / No ✗
  - EKS runtime monitoring: Yes ✓ / No ✗
  - Findings reviewed weekly: Yes ✓ / No ✗
  - SNS notifications configured: Yes ✓ / No ✗

Security Hub Setup:
  - Enabled with CIS Foundations Benchmark: Yes ✓ / No ✗
  - CloudTrail events analyzed: Yes ✓ / No ✗
  - GuardDuty findings aggregated: Yes ✓ / No ✗
  - Automatic remediation enabled: Partial / Full / None
  - Findings reviewed weekly: Yes ✓ / No ✗

Azure Microsoft Defender for Cloud:

Defender for Cloud:
  - Enabled for VMs: Yes ✓ / No ✗
  - Enabled for App Service: Yes ✓ / No ✗
  - Enabled for SQL: Yes ✓ / No ✗
  - Enabled for Storage: Yes ✓ / No ✗
  - Enabled for Containers: Yes ✓ / No ✗
  - Alerts reviewed weekly: Yes ✓ / No ✗
  - SIEM integration (Sentinel): Yes ✓ / No ✗

GCP Security Command Center:

Security Command Center:
  - Premium tier enabled: Yes ✓ / No ✗ (required for threat detection)
  - Event Threat Detection active: Yes ✓ / No ✗
  - Cloud IDS deployed: Yes ✓ / No ✗ (network-based IDS)
  - Container threat detection: Yes ✓ / No ✗
  - Findings reviewed weekly: Yes ✓ / No ✗

SIEM Integration:

Centralize logs and alerts in a SIEM platform:

SIEM Configuration:
  Platform: Splunk / Elastic / Datadog / Sumo Logic
  Log Sources:
    - CloudTrail, Azure Activity Log, Cloud Logging
    - VPC Flow Logs, NSG Flow Logs, VPC Flow Logs
    - GuardDuty, Defender for Cloud, SCC findings
    - Application logs (structured JSON preferred)

  Retention: >=1 year for compliance
  Real-time Alerting:
    - Suspicious sign-in patterns (impossible travel)
    - Privilege escalation attempts
    - Data exfiltration patterns
    - Malware detection (antivirus integration)

Step 2.5: Security Posture Scorecard

At the end of Stage 2, produce a security scorecard across all dimensions:

Domain	AWS Score	Azure Score	GCP Score	Target	Status
IAM	78%	85%	92%	90%	⚠️ Needs Work
Network Security	82%	80%	88%	90%	⚠️ Needs Work
Data Protection	90%	88%	95%	95%	✓ On Track
Logging & Monitoring	75%	70%	80%	85%	✗ Critical Gap
Threat Detection	80%	85%	82%	90%	⚠️ Needs Work
Incident Response	70%	72%	75%	85%	✗ Critical Gap
Overall Security Posture	79%	80%	85%	90%	⚠️ Room to Improve

Critical Findings Summary:

CRITICAL (Remediate within 7 days):
  1. 2 public RDS instances accessible from 0.0.0.0/0
  2. 12 users with AdministratorAccess policy
  3. CloudTrail logging disabled in 2 regions
  4. Root account accessed 15 times in past month

HIGH (Remediate within 30 days):
  1. 23 IAM users without MFA enabled
  2. 45 unencrypted EBS volumes (legacy systems)
  3. 5 S3 buckets with public read access
  4. VPC Flow Logs disabled on 3 of 5 VPCs
  5. 8 security groups allowing 0.0.0.0/0 on port 22

MEDIUM (Remediate within 60 days):
  1. KMS key rotation not enabled (6 keys)
  2. 34 IAM access keys older than 90 days
  3. Secrets Manager not used (credentials hardcoded in 5 Lambda functions)

---

Stage 3: Compliance & Governance Validation (2-4 days)

Objectives

Map security findings to compliance frameworks, validate control effectiveness, and establish continuous compliance monitoring.

Step 3.1: CIS Benchmarks Assessment

The Center for Internet Security (CIS) Benchmarks provide prescriptive security configurations for cloud platforms. They establish two levels:

Level 1 (Essential Controls):

• Recommended for all organizations
• Minimal functionality impact
• Budget: 40-50 hours per 50 services
• Target: 100% compliance for production

Level 2 (Defense-in-Depth Controls):

• Recommended for highly regulated industries (finance, healthcare, government)
• May require testing before implementation
• Budget: Additional 20-30 hours
• Target: 95%+ compliance for sensitive workloads

CIS Benchmark Coverage by Cloud (2025 Versions):

AWS CIS Amazon Web Services Foundations Benchmark v3.0.0:
  Total Controls: 150
  Categories:
    - Identity and Access Management: 28 controls
    - Logging: 16 controls
    - Monitoring: 17 controls
    - Networking: 24 controls
    - Compliance: 35 controls
    - CloudTrail: 14 controls
    - Reserved sections: 16 controls

Azure CIS Microsoft Azure Foundations Benchmark v2.1.0:
  Total Controls: 95
  Categories:
    - Identity and Access Management: 22 controls
    - Logging and Monitoring: 18 controls
    - Networking: 12 controls
    - Virtual Machines: 14 controls
    - Storage: 13 controls
    - Database: 16 controls

GCP CIS Google Cloud Platform Foundations Benchmark v2.0.0:
  Total Controls: 85
  Categories:
    - Identity and Access Management: 20 controls
    - Logging: 18 controls
    - Networking: 14 controls
    - Virtual Machines: 12 controls
    - Storage: 12 controls
    - BigQuery: 9 controls

Automated CIS Scanning Tools:

AWS:

• Prowler (Open-source) - 240+ CIS checks, CIS-aligned reports
• AWS Security Hub - Native CIS Foundations Benchmark standard
• CloudSploit - Cloud security and compliance auditor

Azure:

• Azure Policy - Built-in CIS Benchmark initiatives
• Microsoft Defender for Cloud - CIS compliance dashboard
• Azure Security Benchmark - Microsoft's compliance standard

GCP:

• Security Command Center - CIS Benchmark monitoring
• Forseti Security (Open-source) - GCP security scanner
• GCP Policy Intelligence - Policy validation

Common CIS Benchmark Failures:

### CIS AWS 1.1: Avoid the use of root account
Status: ✓ PASS - Root account MFA enabled, no recent access

### CIS AWS 1.2: Ensure MFA is enabled for all IAM users
Status: ✗ FAIL - 23 users without MFA (23%)
Findings:
  - 18 development team members
  - 3 contractors
  - 2 service account users
  - Recommendation: Require MFA for all console access

### CIS AWS 1.20: Ensure IAM policies that allow full "*:*" administrative privileges are not attached
Status: ✗ FAIL - 14 users with AdministratorAccess policy
Findings:
  - Risk: Single compromised credential = full account access
  - Recommendation: Attach service-specific managed policies instead

### CIS AWS 2.1: Ensure CloudTrail is enabled in all regions
Status: ✗ FAIL - CloudTrail disabled in eu-west-1 and ap-southeast-1
Action Items:
  1. Enable CloudTrail in disabled regions
  2. Configure S3 bucket encryption and validation
  3. Set retention policy (min 90 days for PCI-DSS)
  4. Configure CloudWatch alarms for API activity

### CIS AWS 4.1: Ensure no security groups allow ingress from 0.0.0.0/0 to port 22
Status: ✗ FAIL - 14 security groups allow SSH from anywhere
Findings:
  - 8 production security groups (CRITICAL)
  - 6 staging security groups (HIGH)
  - Recommendation: Restrict to bastion/jump host security group

CIS Benchmark Implementation Timeline:

Priority	Control	Effort	Timeline	Risk
P0 (Critical)	No root account usage	Low	Immediate	None
P0	MFA for all users	Low	1 week	None
P0	CloudTrail in all regions	Low	1 day	None
P0	No public databases	Medium	2 weeks	Medium (migration)
P1 (High)	Encryption at rest	Medium	2-3 weeks	Medium (restart)
P1	No overly permissive IAM policies	Low	1 week	Low
P2 (Medium)	VPC Flow Logs enabled	Low	2-3 days	Low (cost)
P2	Centralized logging	Low	1-2 weeks	Low

Step 3.2: NIST Cybersecurity Framework Mapping

Map cloud security controls to NIST CSF functions:

NIST CSF Functions:

Function	Purpose	Cloud Security Controls
Identify (ID)	Asset and risk management	AWS Config inventory, IAM Access Analyzer, tagging strategy
Protect (PR)	Access control & data security	IAM policies, encryption, security groups, VPCs, MFA
Detect (DE)	Anomaly detection & monitoring	GuardDuty, Security Hub, CloudTrail, VPC Flow Logs
Respond (RS)	Incident response procedures	Runbooks, incident templates, escalation procedures
Recover (RC)	Recovery planning & testing	Backup automation, disaster recovery testing, RTO/RPO

Practical Mapping Example:

Cloud Control: AWS KMS automatic key rotation
  NIST Function: Protect (PR)
  NIST Category: PR.PS Protective Technology
  NIST Requirement: Encrypt sensitive data at rest
  Implementation:
    - Enable automatic key rotation on all KMS keys
    - Audit rotation history via CloudTrail
    - Alert on rotation failures

Cloud Control: CloudTrail logging with integrity validation
  NIST Function: Detect (DE)
  NIST Category: DE.AE Anomaly detection
  NIST Requirement: Monitor for unauthorized activity
  Implementation:
    - Enable CloudTrail in all regions
    - Enable log file validation (HMAC-SHA256)
    - Export to SIEM for analysis
    - Alert on suspicious API patterns (impossible travel, privilege escalation)

Tool Recommendation: Cross-reference your CIS findings with our Cybersecurity Maturity Assessment to build a comprehensive security improvement roadmap aligned to NIST, ISO, and CIS standards.

Step 3.3: Regulatory Compliance Validation

PCI-DSS (Payment Card Industry Data Security Standard):

If you process credit card payments, PCI-DSS is mandatory. The standard encompasses 6 control areas mapped to cloud infrastructure:

PCI-DSS Control Areas:

1. Install and maintain firewall configuration
   Cloud Implementation:
     - Security groups: Restrict traffic to cardholder data environment (CDE)
     - Network ACLs: Ingress/egress rules for data isolation
     - WAF: Protect APIs from web-based attacks

2. Do not use vendor-supplied defaults
   Cloud Implementation:
     - Custom AMIs/Golden Images (no default passwords)
     - Azure managed images with hardened configuration
     - GCP custom images with security patches

3. Protect stored cardholder data
   Cloud Implementation:
     - AES-256 encryption at rest (S3, Azure Storage, Cloud Storage)
     - Tokenization: Replace sensitive data with tokens
     - Restricted access: IAM least privilege to encrypted data

4. Encrypt transmission of cardholder data
   Cloud Implementation:
     - TLS 1.2+ for all data in transit
     - VPN/PrivateLink for hybrid connectivity
     - Certificate pinning for mobile apps

5. Protect systems against malware
   Cloud Implementation:
     - GuardDuty: Threat detection and protection
     - Defender for Endpoint: Antivirus and EDR
     - Vulnerability scanning: ECR, ACR, Artifact Registry

6. Develop and maintain secure systems
   Cloud Implementation:
     - Automated patching: EC2 Systems Manager, Update Management
     - Vulnerability scanning: AWS Inspector, Azure Defender, GCP scanning
     - Quarterly assessments: Run Prowler, Qualys scans

7. Restrict access by business need-to-know
   Cloud Implementation:
     - IAM least privilege: Specific roles for specific team members
     - Database access controls: Encrypted credentials, VPC-only access
     - Logging: All access to cardholder data logged

8. Identify and authenticate access
   Cloud Implementation:
     - Unique IDs: No shared credentials
     - MFA: All administrative access
     - Password policies: 12+ characters, complexity, 90-day rotation

9. Restrict physical access
   Cloud Implementation:
     - AWS/Azure/GCP data centers: PCI-DSS Level 1 certified
     - Shared responsibility model: Verify cloud provider's certifications
     - BAA (Business Associate Agreements) signed

10. Track and monitor network access
    Cloud Implementation:
      - CloudTrail: All API access logged
      - VPC Flow Logs: Network traffic captured
      - Database audit logs: All queries logged

11. Regularly test security systems
    Cloud Implementation:
      - Quarterly vulnerability scans: AWS Inspector, Qualys
      - Annual penetration testing: Approved external firm
      - Config scanning: Infrastructure-as-Code vulnerabilities

12. Maintain security policy
    Cloud Implementation:
      - ISMS documentation: Policies, procedures, evidence
      - Security awareness: Annual training with sign-off
      - Third-party management: SLA reviews, risk assessments

HIPAA (Health Insurance Portability and Accountability Act):

If you handle Protected Health Information (PHI), HIPAA compliance is mandatory. HIPAA focuses on confidentiality, integrity, and availability:

HIPAA Technical Safeguards (Cloud Implementation):

1. Access Control
   - Unique user identification: No shared logins
   - User authentication: MFA required
   - Automatic logoff: Session timeout (15 minutes)
   - Encryption: PHI encrypted at rest and in transit

2. Audit Controls
   - Activity logging: CloudTrail, Activity Logs, Cloud Logging
   - Log retention: Minimum 6 years (HIPAA requirement)
   - Integrity validation: Prevent log tampering
   - Real-time alerts: Suspicious PHI access patterns

3. Integrity Controls
   - Checksums/Hashing: Detect unauthorized modifications
   - Digital signatures: Non-repudiation for critical transactions
   - Transmission security: TLS for all PHI transfers

4. Transmission Security
   - Encryption protocols: TLS 1.2+ mandatory
   - Encryption algorithms: AES-256 minimum
   - Key management: HSM for key storage

Required AWS Services (HIPAA-eligible):
  - ✓ EC2, RDS, EBS (all with encryption)
  - ✓ S3 (with encryption and versioning)
  - ✓ CloudTrail (for audit logging)
  - ✓ KMS (for key management)
  - ✗ DynamoDB (not HIPAA-eligible; use Aurora instead)
  - ✗ SQS (not HIPAA-eligible; use SNS/SES instead)

Required Agreement:
  - Business Associate Agreement (BAA) signed with AWS, Azure, or GCP
  - AWS HIPAA BAA: Available
  - Azure HIPAA BAA: Available
  - GCP HIPAA BAA: Available

GDPR (General Data Protection Regulation):

If you have EU customers, GDPR applies. Key principles:

GDPR Principles for Cloud:

1. Lawfulness, fairness, transparency
   - Privacy policy: Clear, accessible, updated
   - Consent: Explicit opt-in (not pre-checked boxes)
   - Transparency: Data processing records, purpose limitation

2. Data minimization & purpose limitation
   - Collect only necessary data
   - Use data only for stated purposes
   - Don't repurpose without explicit consent

3. Storage limitation
   - Retention policies: Delete data after retention period
   - Automated deletion: Lambda scheduled tasks for data purging
   - Backup cleanup: Remove backups after retention period

4. Integrity & confidentiality
   - Encryption: AES-256 at rest, TLS in transit
   - Access controls: IAM least privilege
   - Pseudonymization: Hash or encrypt PII for analytics

5. Accountability (GDPR Articles 5 & 32)
   - Data Protection Impact Assessment (DPIA): Required for processing
   - Data Processing Agreement (DPA): Signed with cloud providers
   - Incident response: 72-hour breach notification requirement

GDPR Data Residency:
  EU customer data must be stored in EU regions:
    - AWS: eu-west-1 (Ireland), eu-central-1 (Frankfurt)
    - Azure: West Europe (Netherlands), North Europe (Ireland)
    - GCP: europe-west1 (Belgium), europe-west4 (Netherlands)

  Never transfer to US regions without Standard Contractual Clauses (SCCs)
  (Note: Schrems II ruling requires additional safeguards)

GDPR Data Subject Rights:
  - Right to access: User can download their data (DPIA automation)
  - Right to rectification: User can correct inaccurate data
  - Right to erasure ("Right to be Forgotten"): User can request deletion
  - Right to restrict processing: User can limit how data is used
  - Right to portability: User can export data in machine-readable format
  - Right to object: User can opt-out of processing

Implementation:
  - Data export automation: S3 export, blob storage export
  - Automated deletion: Scheduled tasks delete after retention
  - Consent management: Require explicit opt-in
  - DPA templates: Signed with cloud providers

SOC 2 Type II:

For SaaS companies, SOC 2 Type II certification is critical for enterprise sales. SOC 2 evaluates five Trust Service Criteria (TSC):

SOC 2 Trust Service Criteria:

1. Security (CC - Common Criteria)
   - Access controls: IAM least privilege, MFA, separation of duties
   - Infrastructure hardening: OS patching, security groups, encryption
   - Incident response: Documented procedures, response team trained
   Cloud Evidence:
     - CloudTrail audit logs (6-12 month assessment period)
     - GuardDuty findings (zero critical findings target)
     - Configuration baseline (AWS Config, Azure Policy)

2. Availability (A)
   - Monitoring & alerting: Uptime >=99.9% (43 min downtime/month max)
     Cloud Services:
       - CloudWatch (AWS), Monitor (Azure), Cloud Monitoring (GCP)
     SLA: Document in customer-facing agreements
   - Change management: Controlled deployments, rollback procedures
   - Incident logging: Documented incident tracking and resolution

3. Processing Integrity (PI)
   - Data validation: Checksums, field validation rules
   - Error handling: Graceful degradation, retry logic
   - System monitoring: Alerts for processing failures
   Cloud Evidence:
     - Application logs (Lambda, App Service, Cloud Functions)
     - Database integrity checks (foreign keys, constraints)
     - Automated testing (unit, integration, E2E)

4. Confidentiality (C)
   - Encryption: AES-256 at rest, TLS in transit
   - Access controls: IAM policies restrict to authorized users
   - Data classification: Tagging and handling per sensitivity level
   Cloud Evidence:
     - KMS key audit logs (key creation, rotation, deletion)
     - IAM policy reviews (least privilege assessment)
     - Encryption configuration (S3, EBS, databases)

5. Privacy (P)
   - Data collection: Only necessary data collected
   - Consent: Explicit opt-in for processing
   - Data retention: Automated deletion after retention period
   - GDPR/CCPA compliance: Privacy policies updated
   Cloud Evidence:
     - Privacy policy (customer-facing)
     - Consent forms (user opt-in for marketing)
     - Data retention policies (automated deletion rules)
     - DPIA documentation (data protection impact assessment)

SOC 2 Type II Assessment Period: Minimum 6 months (typically 12 months)
Auditor: Big 4 accounting firm (Deloitte, EY, KPMG, PwC) or Big 3 audit firms
Cost: $15,000-$50,000+ depending on organization size

Step 3.4: Continuous Compliance Monitoring

Automated Compliance Dashboards:

AWS Audit Manager & Security Hub:

AWS Audit Manager:
  - Automated evidence collection for SOC 2, PCI-DSS, HIPAA
  - Control frameworks: Predefined mappings to assessments
  - Audit reports: Auto-generated evidence packages
  - Assessment schedule: Continuous or per-assessment basis
  - Cost: $2 per evidence per region per month

AWS Security Hub:
  - Aggregated findings from GuardDuty, Inspector, Macie
  - Compliance standards: CIS, PCI-DSS, AWS Foundational Best Practices
  - Automatic remediation: SNS → Lambda workflows
  - Custom insights: Saved queries for trend analysis
  - Cost: $0.001-$0.003 per finding per month

Azure Policy & Defender for Cloud:

Azure Policy:
  - Built-in initiatives: CIS benchmarks, NIST, PCI-DSS
  - Continuous evaluation: Non-compliant resources flagged
  - Automated remediation: Deploy compliant configurations
  - Assignment scopes: Management groups, subscriptions, resource groups
  - Cost: Included in Microsoft Defender for Cloud subscription

Regulatory Compliance Dashboard:
  - Compliance % by standard: CIS, NIST 800-53, PCI-DSS, HIPAA, ISO 27001
  - Remediatio guidance: Links to Azure docs for non-compliant controls
  - Evidence collection: Automated audit logs export

GCP Security Command Center Compliance Dashboard:

Security Command Center:
  - Compliance standards: CIS, PCI-DSS, NIST 800-53, ISO 27001
  - Real-time compliance scoring: % of compliant controls
  - Custom compliance frameworks: Define org-specific controls
  - Evidence export: Automated compliance reports for auditors
  - Cost: Included with SCC Premium tier ($100+/month)

Compliance Reporting Cadence:

• Weekly: Internal security team (new findings, remediation progress)
• Monthly: Executive dashboard (compliance %, trend analysis, risk register)
• Quarterly: Audit committee (control effectiveness, remediation status)
• Annually: External auditors (SOC 2, ISO 27001, PCI-DSS certification)

Step 3.5: Compliance Gap Analysis & Remediation Planning

At the end of Stage 3, produce compliance matrix:

Framework	Compliant Controls	Non-Compliant Controls	Compliance %	Gap Severity
CIS Benchmark Level 1	142/150	8	94.7%	High
NIST CSF	89/98	9	90.8%	Medium
ISO 27001	110/114	4	96.5%	Low
PCI-DSS	267/275	8	97.1%	Medium
HIPAA	45/48	3	93.8%	High
GDPR	32/35	3	91.4%	High
SOC 2	55/60	5	91.7%	Medium

Top 10 Compliance Gaps to Address:

1. Root Account MFA: CRITICAL (CIS 1.1, NIST PR.AC, PCI-DSS 8.3)
   Effort: 15 minutes
   Timeline: Immediate (day 1)

2. MFA for All IAM Users: HIGH (CIS 1.2, NIST, PCI-DSS, HIPAA)
   Effort: 2-4 hours
   Timeline: 1 week

3. CloudTrail in All Regions: CRITICAL (CIS 2.1, PCI-DSS 10.5, HIPAA Audit Logs)
   Effort: 30 minutes
   Timeline: 1 day

4. Remove Public Database Access: CRITICAL (CIS 4.13, NIST, PCI-DSS)
   Effort: 4-8 hours (downtime required)
   Timeline: 2 weeks

5. Enable Encryption at Rest: HIGH (CIS 2.3.1, NIST PR.DS, PCI-DSS 3.4, HIPAA, GDPR)
   Effort: 8-16 hours (migration required)
   Timeline: 4 weeks

6. Restrict IAM Policies: HIGH (CIS 1.20, NIST PR.AC)
   Effort: 2-4 hours
   Timeline: 1-2 weeks

7. Enable VPC Flow Logs: MEDIUM (CIS 4.4, NIST DE.AE, PCI-DSS 12.3)
   Effort: 2 hours
   Timeline: 1-2 days

8. Enable S3 Default Encryption: MEDIUM (CIS 2.3.1, PCI-DSS 3.4)
   Effort: 30 minutes (non-breaking)
   Timeline: 1 day

9. Data Classification & Tagging: MEDIUM (GDPR, PCI-DSS, SOC 2)
   Effort: 4-8 hours (organizational)
   Timeline: 2 weeks

10. Incident Response Runbooks: MEDIUM (NIST RS, HIPAA, GDPR breach notification)
    Effort: 8-16 hours (documentation)
    Timeline: 2-3 weeks

---

Conclusion & Next Steps

Cloud security posture assessment is not a one-time project—it's the foundation for continuous security improvement. After completing Stages 1-3:

1. Remediate critical and high findings within 30 days
2. Implement automated compliance monitoring using native cloud tools (Security Hub, Defender for Cloud, SCC)
3. Establish quarterly re-assessments to track progress and identify new risks
4. Integrate findings into your incident response and change management processes
5. Train your teams on security best practices and policy enforcement

The path from "unaware" to "optimized" takes 90-180 days with disciplined execution. Start with CIS Benchmark Level 1 (40-50 hours per organization), then expand to Level 2 and regulatory frameworks as your maturity increases.

Your cloud security posture directly impacts your organizational risk, compliance standing, and customer trust. Make it a priority.

---

References & Resources

• CIS Benchmarks - Center for Internet Security
• AWS Well-Architected Framework Security Pillar
• Azure Cloud Adoption Framework - Security Governance
• GCP Security Best Practices
• NIST Cybersecurity Framework
• ISO 27001/27017/27018 Standards
• Prowler - Open-Source Security Auditor
• Gartner 2025 Cloud Security Outlook
• IBM Cost of a Data Breach 2024