ISO 27001 A.5.23: Information Security for Use of Cloud Services

Quick Reference (60 Seconds)

What the Control Asks For

ISO 27001:2022 A.5.23 Text

ISO 27001:2022 Annex A 5.23 asks organizations to establish processes to acquire, use, manage, and exit cloud services in line with the organization's security requirements.

Do you need this control?

A.5.23 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. Almost every organisation that uses cloud services includes it. If you use no cloud services at all, you could exclude it with that reason, but this is now very rare.

ISO 27002:2022 Implementation Guidance

ISO/IEC 27002 5.23 asks for a topic-specific policy on cloud services, communicated to relevant parties, which defines (paraphrased):

• (a) the security requirements for using cloud services
• (b) selection criteria and the scope of cloud use
• (c) roles and responsibilities for using and managing cloud services
• (d) which controls the cloud provider manages and which you manage (the shared responsibility split)
• (e) how to obtain and use the provider's security capabilities
• (f) how to obtain assurance on the provider's controls
• (g) how to manage controls, interfaces and changes across multiple cloud services
• (h) how to handle incidents involving cloud services
• (i) how to monitor, review and evaluate ongoing cloud use
• (j) how to change or stop using cloud services, including exit strategies

27002 notes that cloud agreements are often pre-defined and not negotiable. Review them anyway, check they address confidentiality, integrity, availability and information handling with suitable service-level objectives, assess the risks, and have management accept the residual risk. Where possible the agreement should cover: industry-standard architecture; access control meeting your needs; malware protection; processing and storage in approved locations or jurisdictions; dedicated incident support; your requirements flowing to sub-contractors (or a ban on sub-contracting); support for digital evidence collection; support during exit; backups of data and configuration; and return of your configuration files, code and data on request or at termination. Consider requiring advance notice of changes to infrastructure, new jurisdictions and new sub-contractors, and keep close contact with providers to share security information.

What Auditors Actually Check

Why Cloud Security Matters

The Cloud-First Reality

But cloud-first does not mean secure-first. The shared responsibility model creates dangerous ambiguity: the cloud provider secures the cloud, but the customer must secure everything in the cloud. Misconfiguration, weak IAM, and lack of visibility are the leading causes of cloud breaches.

The Indian Context

Indian organizations face unique cloud security challenges:

• Data Localization Requirements: The DPDP Act 2023 does not require localisation: Section 16 allows transfers abroad except to countries the government restricts. Localisation comes from sector rules: RBI's 2018 directive requires payment system data to be stored only in India, SEBI's cloud framework (2023) requires regulated entities' data to stay in India, and CERT-In requires logs to be kept in India. Where these apply, use India regions (AWS Mumbai/Hyderabad, Azure Pune, GCP Mumbai/Delhi) and contractual data-residency terms.
• Shadow Cloud in Startups: Indian SaaS and fintech startups grow fast. Employees sign up for cloud services without security review, and ungoverned cloud accounts are common storing customer data.
• Skills Gap: There is a severe shortage of cloud security architects in India. Many organizations rely on cloud providers' default settings, which are rarely secure by default.
• Regulatory Expectations: RBI's Master Direction on Outsourcing of IT Services (2023) sets conditions for cloud use by regulated entities, and SEBI's CSCRF (2024) and its Framework for Adoption of Cloud Services (2023) require cloud security governance for SEBI-regulated entities.

Scope and Applicability

What A.5.23 Covers

A.5.23 applies to all cloud services used by the organization, regardless of who procured them, how they are funded, or where they are deployed. This includes:

• SaaS (Software as a Service): Google Workspace, Microsoft 365, Salesforce, Slack, Zoom, Jira, ServiceNow, Notion, Figma, GitHub
• PaaS (Platform as a Service): AWS Elastic Beanstalk, Azure App Service, Google App Engine, Heroku, Vercel, Netlify, Firebase
• IaaS (Infrastructure as a Service): AWS EC2/S3/RDS, Azure VMs/Storage, Google Compute Engine, DigitalOcean, Linode, OVHcloud
• Cloud Storage: Dropbox, Box, Google Drive, OneDrive, AWS S3, Azure Blob Storage, Wasabi
• Cloud Databases: AWS RDS, Azure SQL, Google Cloud SQL, MongoDB Atlas, Snowflake, Databricks
• Cloud Security Services: WAF, DDoS protection, CASB, SIEM-as-a-Service, cloud identity providers
• Shadow Cloud: Any cloud service used by employees without security or procurement approval

What A.5.23 Does NOT Cover

• On-premises infrastructure (covered by A.8.1, A.8.15, A.8.16)
• Managed hosting with dedicated bare metal (treated as supplier, not cloud, A.5.19–A.5.22)
• Personal cloud use by employees (covered by A.5.10, A.6.3, A.8.1)

Cloud Deployment Models and Risk Implications

Service Model Responsibility Matrix (Shared Responsibility Model)

Critical insight: As you move from SaaS to IaaS, your security responsibility increases dramatically. A SaaS customer must secure data, endpoints, and identity. An IaaS customer must secure everything above the hypervisor.

Key Definitions and Terminology

Relationship to Other Controls

A.5.23 does not exist in isolation. It intersects with at least 15 other Annex A controls:

Implementation Roadmap (Week-by-Week)

Phase 1: Discovery and Governance (Weeks 1–3)

Phase 2: Hardening and Controls (Weeks 4–7)

Phase 3: Contracts and Compliance (Weeks 8–10)

Phase 4: Maturity and Continuous Improvement (Weeks 11–12)

Detailed Implementation Guidance

Cloud Service Governance Framework

A cloud governance framework is the foundation of A.5.23. Without governance, cloud usage becomes a free-for-all. The framework must include:

1. Cloud Security Policy: The organization's stance on cloud adoption, risk appetite, prohibited services, and mandatory controls.
2. Cloud Service Review Board (CSRB): A cross-functional committee that approves new cloud services, reviews risk assessments, and governs cloud strategy.
3. Cloud Service Register: The single source of truth for all cloud services, owners, data types, risk scores, and review dates.
4. Approval Workflow: A defined process for requesting, assessing, approving, and onboarding cloud services.
5. Decommissioning Process: A structured offboarding process for cloud services, including data retrieval, verification of deletion, and access revocation.

Cloud Service Register Fields:

Cloud Risk Assessment Process

Every cloud service must undergo a risk assessment before approval and annually thereafter. The assessment should cover:

Step 1: Identify Data and Assets

• What data will be stored, processed, or transmitted?
• What is the data classification and sensitivity?
• What business processes depend on this service?
• What integrations exist with other systems?

Step 2: Evaluate CSP Security Posture

• What certifications does the CSP hold? (ISO 27001, SOC 2 Type II, ISO 27017, CSA STAR, PCI DSS, HIPAA)
• What is the CSP's breach history?
• What is the CSP's security transparency? (Do they publish whitepapers, pen test summaries, architecture diagrams?)
• What is the financial stability of the CSP?

Step 3: Evaluate Technical Controls

• Does the CSP support MFA, SSO (SAML/OIDC), and SCIM?
• Does the CSP support encryption at rest and in transit?
• Does the CSP support BYOK or KYOK?
• Does the CSP provide audit logs and API access for monitoring?
• Does the CSP support data residency and geo-fencing?

Step 4: Evaluate Legal and Regulatory Compliance

• Does the CSP have an Indian data center or region?
• Does the CSP comply with DPDP Act 2023, GDPR, and local regulations?
• Does the CSP provide a Data Processing Agreement (DPA)?
• Does the CSP support data subject rights (access, deletion, portability)?

Step 5: Evaluate Operational Risks

• What is the CSP's SLA for availability? (e.g., 99.99%)
• What is the CSP's disaster recovery capability? (RTO/RPO)
• What is the CSP's incident response and notification process?
• Does the CSP have a documented exit process?

Step 6: Score and Treat Risk

• Calculate inherent risk based on data sensitivity + service model + deployment model.
• Identify and evaluate existing controls.
• Calculate residual risk.
• If residual risk exceeds risk appetite, define treatment: avoid, mitigate, transfer, or accept.
• Document risk acceptance rationale if applicable.

AWS-Specific Security Implementation

Identity and Access Management (IAM):

• Enable AWS IAM Identity Center (SSO) for all human access. No long-term access keys for users.
• Enforce MFA for root accounts, IAM Identity Center, and all privileged roles.
• Use IAM roles with temporary credentials for applications (never hardcode keys).
• Implement least privilege with AWS IAM Access Analyzer to identify over-permissive policies.
• Enable AWS CloudTrail in all regions with log file validation and multi-region trail.
• Enable AWS Config for continuous configuration monitoring and compliance rules.

Data Protection:

• Enable default encryption on all S3 buckets using SSE-S3 or SSE-KMS. Use bucket policies to deny unencrypted uploads.
• Enable AWS Macie for automatic sensitive data discovery in S3.
• Use AWS KMS for key management; consider BYOK for highly sensitive data.
• Enable TLS 1.2+ on all ELB, CloudFront, and API Gateway endpoints.

Network Security:

• Use VPCs with private subnets for sensitive workloads. No public IP on databases.
• Implement AWS WAF on CloudFront and ALB with managed rule sets.
• Enable AWS Shield Advanced for DDoS protection on critical applications.
• Use AWS PrivateLink for secure service-to-service communication without internet exposure.
• Implement security groups with least privilege (no 0.0.0.0/0 except where justified).

Monitoring and Compliance:

• Enable AWS Security Hub for centralized security findings across GuardDuty, Inspector, Macie, and Config.
• Enable Amazon GuardDuty for intelligent threat detection.
• Enable AWS Inspector for automated vulnerability scanning of EC2 and container images.
• Use AWS Systems Manager for patch management and session manager (no SSH keys on bastion hosts).

Azure-Specific Security Implementation

Identity and Access Management:

• Use Microsoft Entra ID (formerly Azure AD) for all authentication. Enable PIM (Privileged Identity Management) for just-in-time admin access.
• Enforce Conditional Access policies: MFA for all users, device compliance for sensitive apps, and location-based restrictions.
• Implement least privilege with Azure RBAC and custom roles. Use Azure AD Access Reviews for quarterly access certification.
• Enable passwordless authentication (FIDO2, Windows Hello, Microsoft Authenticator) for privileged users.

Data Protection:

• Enable Azure Storage Service Encryption (SSE) with Microsoft-managed keys or customer-managed keys (CMK) in Azure Key Vault.
• Use Azure Purview for data classification and sensitive data scanning across Azure, M365, and on-prem.
• Enable Azure Policy to enforce encryption on all storage accounts and databases.
• Configure TLS 1.2+ on all Azure App Services, Front Door, and API Management.

Network Security:

• Use Azure Virtual Network (VNet) with Network Security Groups (NSG) and Azure Firewall.
• Implement Azure Private Link for private connectivity to Azure PaaS services.
• Enable Azure DDoS Protection Standard for critical applications.
• Use Azure Application Gateway with WAF for web application protection.
• Implement Azure Bastion for secure RDP/SSH without public IPs.

Monitoring and Compliance:

• Enable Microsoft Defender for Cloud for unified security posture management and threat protection.
• Enable Microsoft Sentinel as cloud-native SIEM and SOAR for Azure and multi-cloud.
• Use Azure Monitor and Log Analytics for centralized logging and alerting.
• Enable Azure Policy for compliance enforcement and drift detection.

Google Cloud Platform (GCP) Specific Security Implementation

Identity and Access Management:

• Use Google Cloud IAM with organization policies, folders, and projects for resource hierarchy.
• Enforce 2-Step Verification (2SV) for all Google Workspace and Cloud Console users.
• Use Cloud Identity-Aware Proxy (IAP) for zero-trust application access without VPN.
• Implement least privilege with IAM Recommender and Policy Analyzer.
• Enable Cloud Audit Logs (Admin Activity, Data Access, System Event) for all projects.

Data Protection:

• Enable default encryption with Cloud KMS. Use CMEK (Customer-Managed Encryption Keys) for sensitive data.
• Use Cloud DLP for automatic sensitive data discovery and classification in Cloud Storage, BigQuery, and Dataflow.
• Configure VPC Service Controls to create security perimeters around sensitive data.
• Enable TLS 1.2+ on all Cloud Load Balancing and Cloud Run endpoints.

Network Security:

• Use VPCs with private Google access. No public IPs on databases or internal services.
• Implement Cloud Armor for WAF and DDoS protection.
• Use Cloud NAT for outbound internet access without public IPs.
• Implement firewall rules with least privilege using Firewall Insights.

Monitoring and Compliance:

• Enable Security Command Center (SCC) for asset inventory, vulnerability detection, and threat intelligence.
• Enable Chronicle (or Security Command Center Premium) for advanced threat detection and SIEM.
• Use Cloud Asset Inventory for continuous asset discovery and change tracking.
• Enable Policy Intelligence for IAM policy analysis and remediation recommendations.

Multi-Cloud Governance

Organizations using multiple cloud providers face unique governance challenges:

1. Unified Identity: Use a cloud-agnostic identity provider (Okta, Microsoft Entra ID, Ping Identity) for SSO across all clouds. Avoid siloed IAM.
2. Unified Policy: Define security policies in cloud-agnostic terms (e.g., "all storage must be encrypted") and translate to each provider's native controls.
3. Unified Monitoring: Aggregate logs and security findings into a single SIEM (Splunk, Sentinel, Chronicle, or Elastic) for cross-cloud visibility.
4. Unified Cost and Risk View: Use cloud management platforms (Flexera, CloudHealth, FinOps) to track spend and risk across providers.
5. Skills Strategy: Train teams on cloud-agnostic security concepts rather than over-investing in one provider's certifications.
6. Vendor Lock-in Mitigation: Use cloud-native abstractions (Kubernetes, Terraform, CloudFormation) to maintain portability.

Cloud Access Security Broker (CASB) Implementation

A CASB sits between cloud users and cloud services, providing four pillars of security:

1. Visibility: Discover all cloud services in use, including shadow cloud. Map data flows and user behavior.
2. Data Security: Enforce DLP policies, encryption, and tokenization for sensitive data in cloud apps.
3. Threat Protection: Detect and prevent compromised accounts, insider threats, and malware in cloud uploads.
4. Compliance: Ensure cloud usage meets regulatory requirements (DPDP, GDPR, PCI DSS) with automated policy enforcement.

Leading CASB Solutions:

Cloud Data Loss Prevention (DLP)

Cloud DLP prevents sensitive data exfiltration from cloud environments. Implementation steps:

1. Data Classification: Classify all cloud data using automated discovery tools (AWS Macie, Azure Purview, Google Cloud DLP, or third-party tools like BigID, Varonis).
2. Policy Definition: Define DLP policies based on data type (PII, PHI, PCI, IP) and action (block, quarantine, alert, encrypt).
3. Endpoint Enforcement: Deploy endpoint DLP agents (Microsoft Endpoint DLP, Symantec DLP, Forcepoint) to monitor and control data movement to cloud from endpoints.
4. Cloud App Enforcement: Use CASB DLP modules to enforce policies within SaaS apps (e.g., prevent downloading customer lists from Salesforce to personal Google Drive).
5. Network Enforcement: Use network DLP (proxies, firewalls) to inspect and control data in transit to cloud services.
6. Monitoring and Response: Integrate DLP alerts with SOC/SIEM for incident response and forensics.

Data Residency and Sovereignty

Indian organizations must navigate complex data residency requirements:

DPDP Act 2023 Requirements:

• The DPDP Act requires that "digital personal data" of Indian citizens be processed in accordance with the Act's provisions, including purpose limitation, data minimization, and storage limitation.
• The Act has no general localisation duty. The DPDP Rules 2025 let the government require Significant Data Fiduciaries to keep specified categories of personal data in India. Check for any such notification before relying on overseas processing.
• Cross-border transfers are allowed except to countries the government restricts by notification (s.16, a negative list).

RBI Requirements:

• RBI's directive on Storage of Payment System Data (April 2018, with 2019 FAQs) requires payment system data to be stored only in India.
• For cloud usage, RBI requires that data stored in cloud must be accessible for audit and regulatory examination within India. The cloud provider must have an Indian presence and contractual data residency guarantees.
• RBI's Master Direction on Outsourcing of Information Technology Services (2023) sets the conditions for cloud use by regulated entities: risk assessment, data location and access, audit and RBI inspection rights, and exit planning. Check your own RBI instruments for any stricter location or key-management conditions.

SEBI Requirements:

• SEBI's CSCRF (20 August 2024) (MIIs) and 2024 guidelines for intermediaries require that cloud usage must be approved by the board, with data residency and security controls documented.
• SEBI mandates that cloud providers for MIIs must be evaluated for security, resilience, and compliance. Data must be stored in Indian regions unless specifically approved otherwise.

Implementation Approach:

1. Map Data to Regions: Create a data residency matrix that maps every data type to its required geographic location.
2. Contractual Commitments: Use the provider's region commitments and DPA; where terms are not negotiable, enforce location through configuration (region restrictions) and record the residual risk.
3. Geo-Fencing: Use cloud-native geo-fencing controls (AWS S3 Object Lock with region constraints, Azure Policy for region restriction, GCP Resource Location Restriction) to prevent accidental data movement.
4. Key Jurisdiction: Ensure encryption keys are managed in the same jurisdiction as the data (e.g., AWS KMS in Mumbai, Azure Key Vault in Central India, Cloud KMS in Mumbai).
5. Audit Trail: Maintain logs of all data movement, replication, and backup across regions.

Cloud Exit Strategy

Every cloud service must have a documented exit strategy. The strategy must cover:

1. Data Retrieval: How to export all data in a usable format (open standards, not proprietary). Include APIs, bulk export tools, and professional services options.
2. Data Deletion Verification: How to request and verify deletion of all data from the provider's systems, including backups, replicas, and logs. Obtain a deletion certificate.
3. Service Transition: How to transition to an alternative provider or on-premises solution with minimal business disruption.
4. Contractual Terms: Notice period, termination fees, data return timeline, and post-termination support.
5. Testing: Conduct an annual tabletop exercise or pilot retrieval test to validate the exit strategy.

Exit Strategy Template:

Tools, Technologies, and Solutions

Cloud Security Posture Management (CSPM)

Cloud Workload Protection Platform (CWPP)

Cloud-Native SIEM and Monitoring

Policy and Procedure Templates

Cloud Security Policy (Outline)

1. Purpose and Scope: Define the policy's purpose, scope (all cloud services), and applicability (all employees, contractors, and third parties).
2. Governance: Define the Cloud Security Review Board (CSRB), roles, and meeting cadence.
3. Risk Appetite: Define acceptable risk levels for cloud services based on data classification and service model.
4. Prohibited Services: List categories of cloud services prohibited (e.g., personal cloud storage for work data, unapproved file sharing, unencrypted communication).
5. Mandatory Controls: Define controls required for all cloud services: MFA, encryption, IAM, logging, monitoring, and DLP.
6. Data Residency: Define requirements for data storage location based on data type and regulatory requirements.
7. Approval Process: Step-by-step workflow for requesting, assessing, and approving cloud services.
8. Monitoring and Review: Define monitoring requirements, review frequencies, and reporting.
9. Incident Response: Define how cloud security incidents are detected, reported, and remediated.
10. Exit Strategy: Require exit strategies for all critical cloud services.
11. Training and Awareness: Define cloud security training requirements for all users and administrators.
12. Violations and Consequences: Define consequences for policy violations, including unauthorized cloud usage.

Cloud Service Approval Procedure (Outline)

1. Request: Business owner submits Cloud Service Request Form with business justification, data types, user count, and integration details.
2. Initial Screening: Security team screens the request against the prohibited services list and known risk indicators.
3. Risk Assessment: Security team completes the Cloud Risk Assessment using the standardized template.
4. DPO Review: DPO reviews data protection and residency requirements.
5. Legal Review: Legal reviews contract terms, DPA, and liability clauses.
6. CSRB Review: CSRB reviews the risk assessment, DPO input, and legal input. Approves, rejects, or approves with conditions.
7. Contract Negotiation: Procurement negotiates security clauses and DPA based on CSRB conditions.
8. Technical Onboarding: IT/Security configures IAM, MFA, encryption, logging, and monitoring.
9. Register Entry: Cloud Service Register is updated with all fields.
10. User Communication: Approved users are trained on secure usage and policy requirements.
11. Review Schedule: Review date is set based on risk tier.

Risk Assessment and Treatment

Cloud-Specific Risk Scoring Model

Use the same likelihood × impact method as the rest of your ISMS, and let cloud factors drive the ratings:

• Impact: the sensitivity of the data (Public to Restricted), how many records, and how critical the service is to operations
• Likelihood: how much configuration you control (IaaS gives you the most to get wrong), exposure to the internet, identity controls, provider assurance (certifications, SOC 2 scope) and your monitoring coverage
• Treatment: configuration standards, CSPM, encryption and key control, region restrictions, contract terms where negotiable, and management acceptance of residual risk

Example: A SaaS service (4) storing customer PII (4) in public cloud (3) with 7 controls (7) = (4×4×3) − 7 = 48 − 7 = 41. Risk threshold: >30 = High, requires CSRB review and enhanced controls.

Common Cloud Risks and Treatments

Audit and Compliance Checklist

Auditor Checklist (25 Questions)

Metrics and KPIs

Cloud Security Metrics (15 Metrics)

Common Pitfalls and How to Avoid Them

Pitfall 1: Assuming the Cloud Provider Secures Everything

Problem: Organizations adopt the "cloud is secure by default" fallacy. AWS, Azure, and GCP secure the infrastructure, but the customer must secure data, IAM, applications, and configurations. Solution: Distribute the shared responsibility model to every cloud user and administrator. Conduct quarterly training on customer-side responsibilities. Use CSPM to verify configurations.

Pitfall 2: Unmanaged Shadow Cloud

Problem: Employees sign up for SaaS apps with corporate email, store customer data in personal Dropbox accounts, and use unapproved collaboration tools. Security has no visibility. Solution: Deploy CASB for discovery. Implement SSO-only access for approved services. Run quarterly DNS and expense report scans. Enforce a "no cloud without approval" policy with consequences.

Pitfall 3: Weak Cloud IAM

Problem: Over-permissive roles, shared admin accounts, long-lived access keys, and no MFA on privileged accounts. Root credentials are shared in spreadsheets. Solution: Enforce MFA with hardware tokens for privileged users. Eliminate shared accounts. Avoid long-lived access keys altogether (use SSO and short-lived role credentials); where a key is unavoidable, rotate it at least every 90 days. Use IAM Access Analyzer (AWS), Entra ID PIM (Azure), or IAM Recommender (GCP) to find excess permissions.

Pitfall 4: Ignoring Data Residency

Problem: Data is stored in the default region (often US East) without considering DPDP Act, RBI, or SEBI requirements. Backups and replicas are silently created in other regions. Solution: Create a data residency matrix. Configure geo-fencing and region locks. Verify backup and replication configurations. Include data residency clauses in all contracts. Audit quarterly.

Pitfall 5: No Cloud Exit Strategy

Problem: Organizations become deeply dependent on a single cloud provider with no plan for retrieval, transition, or termination. When a breach or regulatory change occurs, they are trapped. Solution: Require an exit strategy for every critical cloud service before approval. Test retrieval annually. Negotiate data portability clauses. Use open data formats.

Pitfall 6: Treating SaaS as "Set and Forget"

Problem: SaaS applications are procured by business teams, onboarded by IT, and then never reviewed. Access accumulates, dormant accounts remain, and security settings drift. Solution: Include SaaS in the Cloud Service Register. Conduct quarterly access reviews for all SaaS apps. Monitor SaaS security posture with CASB. Review SaaS security settings (MFA, password policy, session timeout) annually.

Pitfall 7: Inadequate Cloud Logging

Problem: Cloud audit logs are enabled but never reviewed. Logs are not forwarded to SIEM. An attacker deletes logs after compromise, and there is no tamper-proof backup. Solution: Forward all cloud logs to a centralized SIEM in real time. Enable log file integrity validation (AWS CloudTrail log file validation, Azure Monitor immutable logs). Retain logs for at least 12 months (3 years for regulated data). Define alert rules for critical events (root login, policy change, key deletion).

Pitfall 8: Misunderstanding Encryption Responsibility

Problem: Organizations believe "the cloud provider encrypts everything" without understanding who manages keys, who can decrypt, and whether the provider has access. Solution: Document the encryption model for every cloud service: provider-managed keys (SSE-S3), customer-managed keys (SSE-KMS/CMEK), or customer-provided keys (SSE-C). For Restricted data, use BYOK or KYOK with HSM. Audit key access logs.

Pitfall 9: Over-Engineering for Low-Risk Services

Problem: Organizations apply the same rigorous controls to a public marketing website hosted on cloud as they do to a customer database. This wastes resources and creates friction. Solution: Use risk-based tiering. Low-risk cloud services (public data, no PII) need basic controls (MFA, TLS). High-risk services need the full control stack (CASB, DLP, CSPM, BYOK, geo-fencing).

Pitfall 10: Ignoring Cloud Cost as a Security Risk

Problem: Cryptojacking, unauthorized resource provisioning, and data exfiltration via cloud storage all show up as cost anomalies first. Finance sees the bill; security misses the threat. Solution: Integrate cloud cost monitoring with security operations. Define cost anomaly thresholds and route alerts to the SOC. Use FinOps tools (CloudHealth, Finout) to detect unusual spending patterns.

Pitfall 11: Neglecting API and Integration Security

Problem: Cloud services are integrated via APIs with weak authentication, no rate limiting, and excessive permissions. API keys are hardcoded in repositories. Solution: Use OAuth 2.0 / OIDC for API authentication. Store API keys in secret managers (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager). Implement API gateways with rate limiting, WAF, and authentication. Scan code repositories for hardcoded secrets with GitLeaks or TruffleHog.

Pitfall 12: Inadequate Cloud Incident Response

Problem: Incident response playbooks are designed for on-premises networks. When a cloud breach occurs, responders don't know how to revoke cloud access, isolate cloud resources, or forensically image cloud VMs. Solution: Create a cloud-specific incident response playbook. Train the SOC on cloud-native forensics (AWS Detective, Azure Sentinel, GCP Chronicle). Pre-provision isolation tools (IAM deny policies, security group isolation, snapshot automation). Run a cloud IR tabletop exercise annually.

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: Indian Growing SaaS Company, FinTech Enablement Platform (A.5.23 Implementation)

Company Profile:

• Name: CloudPay Solutions Pvt. Ltd. (fictionalized composite)
• Industry: B2B FinTech SaaS
• Size: 180 employees
• Location: Bangalore, India
• Cloud Environment: AWS (primary), GCP (analytics), 47 SaaS applications
• Challenge: Rapid growth led to unmanaged cloud adoption. Customer data (including UPI transaction metadata) was stored across multiple AWS regions without governance. No CASB, no CSPM, and shadow AWS accounts were discovered during a customer audit.

Specific Challenge: CloudPay's largest enterprise customer (a major Indian bank) required ISO 27001 certification as a condition for contract renewal. A pre-audit assessment revealed 23 critical cloud security gaps: unencrypted S3 buckets, shared root AWS credentials, no data residency controls, 12 unapproved SaaS apps storing customer data, and no cloud exit strategies.

Implementation Steps:

1. Week 1–2: Emergency Cloud Inventory: The CISO hired an external security consultant to conduct a 48-hour cloud discovery. Using AWS Config, SSO logs, and DNS scans, we identified 47 cloud services (only 18 were registered). 12 shadow SaaS apps were immediately blocked at the firewall.

2. Week 3: Risk Assessment and Classification: All cloud services were classified by data sensitivity. AWS services storing UPI metadata were classified as Restricted. GCP analytics (anonymized) were Internal. A risk score was calculated for each service using the formula in Section 11.

3. Week 4: IAM Hardening: AWS IAM Identity Center was deployed with SSO for all users. MFA was enforced with hardware tokens for 12 privileged users. 34 over-permissive IAM policies were identified by Access Analyzer and remediated. All long-lived access keys were replaced with IAM roles and temporary credentials.

4. Week 5: Encryption and Data Residency: Default encryption was enabled on all 127 S3 buckets using SSE-KMS with keys in AWS Mumbai (ap-south-1). AWS Macie was deployed to discover and classify sensitive data. TLS 1.3 was enforced on all ALB and CloudFront endpoints. Geo-fencing was configured to prevent data replication outside ap-south-1.

5. Week 6: CASB and CSPM Deployment: Netskope CASB was deployed for SaaS monitoring and DLP. Wiz CSPM was deployed for AWS and GCP misconfiguration detection. Within 48 hours, Wiz identified 156 misconfigurations, including 11 public S3 buckets and 7 security groups with 0.0.0.0/0. All critical findings were remediated within 72 hours.

6. Week 7: Contract and Compliance Review: All 47 cloud contracts were reviewed. Standard terms and DPAs were reviewed for all 47; 23 smaller vendors agreed security addenda, and gaps with the large providers were closed through configuration and recorded as accepted risk. AWS and GCP certifications (ISO 27001, SOC 2 Type II, ISO 27017) were verified and recorded.

7. Week 8: Exit Strategies and Documentation: Exit strategies were documented for AWS, GCP, and all 8 critical SaaS apps. A tabletop exercise simulated an AWS region outage and validated the data retrieval procedure (estimated 18 hours for 2.3 TB).

8. Week 9–10: Training and Internal Audit: All 180 employees completed cloud security awareness training. The IT team (12 people) completed AWS Security Essentials. An internal audit was conducted by an independent internal auditor who had not been involved in the implementation, resulting in 4 minor findings, all remediated before the external audit.

9. Week 11–12: External Audit and Certification: The external audit (Stage 1 and Stage 2) was conducted by a UKAS-accredited certification body. A.5.23 was assessed with zero non-conformities. The bank's contract was renewed, and CloudPay won two additional enterprise clients citing the certification.

Measurable Outcomes:

• Cloud misconfiguration count: 156 → 0 Critical/High in 6 weeks
• Shadow cloud services: 12 → 0 (ongoing CASB monitoring)
• Encryption coverage: 45% → 100% (at rest and in transit)
• MFA coverage: 23% → 100%
• Data residency compliance: 0% → 100% for Restricted data
• External audit result: Zero non-conformities for A.5.23
• Business outcome: contract renewal + new business attributed to ISO 27001
• Implementation cost: (including tools, consulting, and training)
• ROI: 110:1 in first year

Illustrative Scenario 2: Large Indian Enterprise, Manufacturing Conglomerate with Multi-Cloud Complexity

Company Profile:

• Name: BharatForge Industries Ltd. (fictionalized composite)
• Industry: Manufacturing (Automotive and Industrial Components)
• Size: 12,000 employees, 8 manufacturing plants across India
• Cloud Environment: Azure (primary, 70%), AWS (20%, for IoT/ML), Google Workspace (10%), 200+ SaaS applications
• Challenge: Decades of decentralized IT across 8 plants led to inconsistent cloud governance. Each plant had its own Azure subscriptions, AWS accounts, and SaaS procurement. The corporate IT team had no visibility into plant-level cloud usage. A ransomware incident at a European competitor (via a compromised SaaS account) triggered a board-level mandate for cloud security governance.

Specific Challenge: BharatForge's board demanded ISO 27001 certification within 9 months to meet OEM customer requirements (Tata Motors, Mahindra, Bajaj Auto). The initial assessment revealed:

• 347 cloud services in use (only 89 were registered)
• 43 Azure subscriptions with no centralized governance
• 12 AWS accounts with no organization-level controls
• 67 SaaS applications procured by individual plants without security review
• 3 SaaS apps storing product design IP (CAD files) with no DLP or access controls
• No data residency controls for employee PII across 8 plants
• No cloud-specific incident response capability
• Cloud spend had grown 340% in 3 years with no security oversight

Implementation Steps:

1. Month 1: Governance Architecture: BharatForge established a Corporate Cloud Security Office (CCSO) with a CISO, 2 cloud security architects, and a compliance manager. A Cloud Security Steering Committee was formed with plant CIOs, legal, procurement, and HR. The first policy issued was the "One Cloud, One Governance" mandate: no new cloud subscriptions without CCSO approval.

2. Month 1–2: Complete Cloud Discovery: Using Microsoft Defender for Cloud Apps (CASB), Flexera, and manual surveys, the team discovered 347 cloud services. 89 were already in a corporate register. 258 were unregistered. Services were classified: 23 Critical (product IP, financials, employee PII), 67 High, 145 Medium, 112 Low. 18 shadow services were immediately decommissioned.

3. Month 2: Azure Governance Hardening: All 43 Azure subscriptions were consolidated under a single Azure AD tenant with Management Groups. Azure Policy was deployed with 28 built-in policies (encryption, region restriction, MFA, tagging). Microsoft Defender for Cloud was enabled across all subscriptions. PIM was deployed for just-in-time admin access. Conditional Access policies enforced MFA and compliant devices for all corporate apps.

4. Month 3: AWS Organization and Security: All 12 AWS accounts were consolidated under AWS Organizations with SCPs (Service Control Policies). SCPs enforced: no account creation without CCSO approval, mandatory CloudTrail, mandatory Config, encryption on S3, and region restriction to ap-south-1 and ap-south-2. AWS Security Hub was enabled as the central security dashboard. AWS IAM Identity Center was deployed for SSO.

5. Month 3: Data Residency and DLP: A data residency matrix was created mapping every data type to its required region. All employee PII (8,000+ records) was identified and migrated to Azure Central India and AWS Mumbai. Azure Purview was deployed for data classification. Microsoft Purview DLP was deployed across Azure, M365, and endpoints. Product design IP (CAD files) was protected with Azure Information Protection (AIP) labels and encryption.

6. Month 4: SaaS Governance and CASB: A SaaS governance program was launched. All 200+ SaaS apps were reviewed. 47 were decommissioned (redundant or unused). 89 were approved with standard security configurations. 67 required enhanced controls (CASB monitoring, DLP, access reviews). The top 20 SaaS apps were integrated with Azure AD SSO and SCIM for automated provisioning/deprovisioning.

7. Month 4–5: Multi-Cloud SIEM and Monitoring: Microsoft Sentinel was deployed as the central SIEM, ingesting Azure Monitor, AWS CloudTrail, Google Workspace audit logs, and CASB alerts. KQL (Kusto Query Language) queries were developed for cloud-specific detections: anomalous IAM changes, public S3 bucket creation, mass data download, and failed MFA attempts. A dedicated cloud SOC team (4 analysts) was trained.

8. Month 5: Cloud Incident Response and Forensics: A cloud-specific incident response playbook was developed covering Azure, AWS, and SaaS. The playbook included: IAM isolation procedures, snapshot forensics, log preservation, and OEM/customer notification triggers. A tabletop exercise simulated a compromised Azure AD admin account. The response time from detection to isolation was 23 minutes.

9. Month 6: Exit Strategies and Business Continuity: Exit strategies were documented for all 23 critical cloud services. For the product lifecycle management (PLM) SaaS (storing 15 years of CAD designs), a 6-month data retrieval test was conducted. 2.8 TB of design data was exported to Azure Blob Storage in 14 hours. The board was briefed on cloud exit readiness.

10. Month 7–8: Internal Audit and Remediation: An internal audit was conducted by a third-party firm (not the certification body). 12 findings were identified, including inconsistent tagging, missing access reviews for 3 plants, and incomplete DLP coverage for one SaaS app. All findings were remediated within 4 weeks.

11. Month 9: External Certification Audit: The Stage 1 audit focused on documentation and governance. The Stage 2 audit tested controls across 3 randomly selected plants. A.5.23 was assessed with one minor finding (incomplete cloud access review for one plant, which was already scheduled). BharatForge received ISO 27001:2022 certification.

Measurable Outcomes:

• Cloud services governed: 89 → 347 (100% registered and risk-assessed)
• Azure subscriptions: 43 ungoverned → 1 unified tenant with Management Groups
• AWS accounts: 12 standalone → 1 Organization with SCPs
• Shadow cloud services: 258 unregistered → 0 (with CASB continuous discovery)
• Cloud misconfigurations: 312 open → 14 open (all Low)
• Data residency compliance: 0% → 100% for all employee PII and product IP
• DLP policy coverage: 0% → 100% for Critical and High data
• Cloud incident response time: N/A → 23 minutes (mean detection to isolation)
• Certification achieved: ISO 27001:2022 with one minor finding

Multi-Framework Mapping

A.5.23 maps to multiple frameworks. Organizations operating under multiple compliance regimes can use this table to streamline implementation.

ISO 27001 ↔ SOC 2 Trust Services Criteria

ISO 27001 ↔ PCI DSS v4.0.1

ISO 27001 ↔ NIST 800-53 Rev 5

ISO 27001 ↔ CIS Controls v8

ISO 27001 ↔ COBIT 2019

ISO 27001 ↔ GDPR / DPDP Act 2023

Regulatory and Industry Context

India: Regulatory Landscape for Cloud Security

Digital Personal Data Protection (DPDP) Act 2023

• The DPDP Act establishes India's first complete data protection framework. It has no general localisation rule: Section 16 lets the Central Government restrict transfers to notified countries, and the DPDP Rules 2025 let it require Significant Data Fiduciaries to keep specified personal data in India.
• For B2B companies processing personal data of Indian citizens in the cloud, the Act requires:
  • Appropriate technical and organizational measures and reasonable security safeguards (Section 8(4), 8(5))
  • Breach intimation to the Data Protection Board and each affected Data Principal without delay, with a detailed report to the Board within 72 hours (Section 8(6) and the DPDP Rules)
  • Appointment of a Data Protection Officer (for Significant Data Fiduciaries) (Section 10(2)(a))
  • Data Protection Impact Assessment (DPIA) for high-risk processing (Section 10(2)(c))
• Cloud providers must be bound by Data Processing Agreements that specify security measures, subprocessor governance, and breach notification.

Information Technology Act 2000 (as amended)

• Section 43A (with the SPDI Rules 2011, until DPDP s.44(2) omits it, about May 2027): compensation for failure to protect sensitive personal data. Cloud security failures that expose data can trigger liability.
• Section 66C (Identity theft), 66D (Cheating by impersonation), 66E (Violation of privacy): Cloud account takeover and data theft are criminal offenses.
• Section 69 (Cybersecurity powers): Government can direct cloud providers to intercept, monitor, or decrypt information for national security.
• Section 70B (CERT-In powers): CERT-In can issue directions to organizations and cloud providers for cybersecurity incident response.
• CERT-In Directions 2022: Mandate reporting of cybersecurity incidents within 6 hours, maintenance of logs for 180 days, and KYC for data centers.

RBI Regulations

• Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (2023): Applies to banks and NBFCs (it replaced the 2017 NBFC IT framework); requires IT governance, risk management and data protection.
• Master Direction on Outsourcing of Information Technology Services (2023): Board-approved outsourcing policy; specific conditions for cloud use, including data location, access for audit and RBI inspection, and exit.
• Cyber Security Framework in Banks (2016): Cyber security policy, baseline controls and incident reporting; read it with the 2023 outsourcing direction for cloud use. Encryption keys should be managed within Indian jurisdiction.
• Storage of Payment System Data (2019): All payment system data must be stored in India. Cloud providers for payment data must have Indian data centers and contractual guarantees.
• Guidelines on Regulation of Payment Aggregators and Payment Gateways (2020) and Master Direction on Digital Payment Security Controls (2021): Security baselines, encryption and incident reporting for payment systems, including cloud-hosted ones.

SEBI Regulations

• Framework for Adoption of Cloud Services by SEBI Regulated Entities (March 2023): Cloud usage must be approved by the board; data must stay within India's legal jurisdiction. Data residency, security controls, and incident reporting must be documented. Cloud providers for MIIs must be evaluated for security and resilience.
• CSCRF (20 August 2024): Consolidated cyber security and resilience requirements for all SEBI-regulated entities, including cloud. Cloud data must be protected with encryption, access controls, and audit trails.

IRDAI Regulations

• IRDAI Information and Cyber Security Guidelines (2023): Insurers using cloud must ensure data protection, business continuity, and regulatory compliance. Cloud providers must meet IRDAI's security standards.
• Records in India: The IRDAI (Maintenance of Insurance Records) Regulations, 2015 require policy and claim records to be held in data centres in India.

Telecom Sector (DoT / TRAI)

• National Security Directive on the Telecommunication Sector (issued 2020, in force 2021): Requires telecom operators to use "trusted sources" for cloud and telecom equipment. Cloud providers for telecom must be evaluated for security and supply chain integrity.
• Data Localization for Telecom: Subscriber data and CDRs must be stored in India.

Government and Public Sector

• MeitY Guidelines for Cloud Adoption by Government: Government data must be stored in India. Cloud providers must be empaneled by MeitY and meet security requirements under the "Policy on Adoption of Cloud by Government."
• State Data Centers: Many state governments mandate that all e-governance data must be hosted in state data centers or MeitY-empaneled cloud providers.

International Regulatory Context

GDPR (EU)

• Cloud providers processing EU personal data must comply with GDPR Article 28 (processor obligations), Article 32 (security), and Article 33 (breach notification).
• Cross-border transfers require adequacy decisions, SCCs, or Binding Corporate Rules. Cloud providers must support data subject rights (access, rectification, erasure, portability).

CCPA / CPRA (California, USA)

• California consumers have rights to know, delete, and opt-out of sale of personal information. Cloud providers must support these rights through APIs and data management.
• CPRA introduces data minimization, purpose limitation, and risk assessments for cloud processing.

HIPAA (USA, Healthcare)

• Cloud providers handling PHI must sign Business Associate Agreements (BAA). Technical safeguards include encryption, access controls, and audit controls.
• Cloud providers must be configured to meet HIPAA's audit log, backup, and incident response requirements.

SOX (USA, Financial Reporting)

• Cloud services supporting financial reporting must meet SOX IT General Controls (ITGC) requirements. Change management, access controls, and logging must be auditable.
• Cloud providers must support auditor access and evidence retrieval for SOX audits.

Sector-Specific Cloud Security Requirements

BFSI (Banking, Financial Services, Insurance)

• RBI and SEBI mandate Indian data residency for sensitive financial data.
• Cloud providers must support real-time regulatory reporting, audit trails, and encryption.
• Multi-factor authentication is mandatory for all cloud banking applications.
• Cloud DR must meet RTO/RPO requirements (typically RTO < 4 hours, RPO < 1 hour for core banking).

Healthcare

• The DPDP Act and, for ABDM participants, the ABDM Health Data Management Policy (in force since 2020, revised 2022) require safeguards such as encryption and access controls for health data in the cloud.
• Cloud providers must support HIPAA-like controls if serving US patients or clinical trial data.
• Cloud telemedicine platforms must ensure patient data privacy and video encryption.

Telecom

• DoT mandates trusted sources and Indian data residency for subscriber data.
• Cloud-based BSS/OSS must meet high availability and security standards.
• 5G network functions in cloud (cloud-native RAN, core) require strict tenant isolation and zero-trust architecture.

Manufacturing

• Industrial IoT (IIoT) data in cloud requires edge-to-cloud encryption and OT/IT separation.
• Product design IP (CAD, CAM) in cloud requires DLP and strict access controls.
• Cloud-based supply chain platforms must ensure data integrity and anti-tampering.

Government / E-Governance

• MeitY mandates Indian data residency for all government data.
• Cloud providers must be empaneled and meet security requirements.
• Citizen data in cloud (Aadhaar-linked, tax, health) requires highest security controls.

Roles and Responsibilities

RACI Matrix for Cloud Security Activities

R = Responsible, A = Accountable, C = Consulted, I = Informed

Documentation and Evidence Requirements

Required Documents for A.5.23 Audit

Continuous Improvement

Figure · Tiers

Maturity levels for for use of cloud services

Cloud Security Maturity Model (Levels 1–5)

Improvement Roadmap by Maturity Level

FAQ

General Questions

Q1: Does A.5.23 apply to personal cloud accounts used by employees?

No. A.5.23 applies to organizational cloud services. However, if employees use personal cloud accounts (e.g., personal Google Drive, Dropbox) to store or process organizational data, this is a violation of A.5.10, A.6.3, and A.8.1. The organization must prohibit this through policy and technical controls (DLP, CASB, endpoint monitoring).

Q2: What is the difference between A.5.22 and A.5.23?

• A.5.22 is the general control for monitoring, reviewing, and managing changes to all supplier services.
• A.5.23 is the specific control for information security when using cloud services. A.5.23 covers cloud-specific risks (data residency, shared responsibility, shadow IT, multi-cloud) that A.5.22 does not address in depth.

Q3: Is A.5.23 required for ISO 27001:2013 transition?

A.5.23 is new in the 2022 version. Include it in your Statement of Applicability unless you genuinely use no cloud services (the 2013-to-2022 transition deadline of 31 October 2025 has passed). The closest 2013 controls were A.15.1.2 (Addressing Security Within Supplier Agreements) and A.15.2.1 (Monitoring and Review of Supplier Services), but neither addressed cloud-specific security requirements. If you are transitioning from 2013 to 2022, you must consider A.5.23 in your risk treatment and record it in your updated Statement of Applicability, as included or excluded with a reason. Almost every organisation that uses cloud services includes it.

Q4: Do I need a separate risk assessment for every SaaS application?

Yes, but the depth varies. For Critical SaaS (storing Restricted data), a full 50-point risk assessment is required. For Low SaaS (storing Public data), a lightweight 10-point assessment is sufficient. The key is that every cloud service is registered, classified, and assessed according to its risk tier.

Q5: Can we use a single cloud provider to avoid multi-cloud complexity?

Yes, and many organizations do. However, most growing companies and enterprise organizations end up with multiple providers due to SaaS procurement (different SaaS apps run on different clouds), cost optimization, or resilience requirements. If you have more than one cloud provider, you need multi-cloud governance (Section 8.6).

Q6: How do we validate a cloud provider's ISO 27001 or SOC 2 certificate?

1. Request the certificate and note the certificate number, accreditation body, scope, and expiry date.
2. Verify the certificate via the accreditation body's online registry (e.g., ANAB, UKAS, JAS-ANZ, NABCB in India).
3. Check that the scope covers the specific cloud service and region you are using.
4. Check that the certificate is current and not suspended.
5. For additional assurance, request the latest surveillance audit report (sanitized) and the SOC 2 Type II report.

Q7: What is the "shared responsibility model" and why does it matter for audit?

The shared responsibility model divides security obligations between the cloud provider and the customer. For IaaS, the customer is responsible for nearly everything above the hypervisor. For SaaS, the customer is responsible for data, endpoints, and identity. Auditors will test your side of the responsibility model. If you cannot demonstrate that you have configured IAM, encryption, and monitoring correctly, you will fail the audit regardless of the provider's certifications.

Q8: How often should we review our cloud services?

• Critical cloud services: Quarterly
• High cloud services: Bi-annually
• Medium cloud services: Annually
• Low cloud services: Bi-annually or annually

Your Cloud Security Policy should define these frequencies and justify them based on risk. Auditors will check that you adhere to your own defined frequencies.

Q9: What is shadow cloud, and how do we find it?

Shadow cloud (or shadow IT) refers to cloud services used by employees without security or IT approval. Discovery methods:

• CASB discovery (e.g., Netskope, Microsoft Defender for Cloud Apps)
• DNS log analysis (look up queries to cloud service domains)
• Network traffic analysis (unauthorized cloud API traffic)
• Expense report scanning (reimbursement for cloud subscriptions)
• SSO log analysis (look for non-SSO logins to known apps)
• Employee surveys and self-reporting campaigns

Q10: Do we need a CASB if we already have a firewall?

Yes. Firewalls inspect north-south traffic at the perimeter. CASBs inspect east-west traffic within cloud applications and provide visibility into SaaS usage, DLP, and user behavior analytics that firewalls cannot. A modern cloud security stack requires both.

Technical Questions

Q11: Should we use provider-managed encryption keys or customer-managed keys?

For most data, provider-managed keys (SSE-S3, SSE-Azure) are sufficient and easier to manage. For Restricted data (customer PII, financial records, product IP), use customer-managed keys (SSE-KMS, CMEK) with key rotation and strict IAM. For the highest sensitivity, use BYOK or KYOK with HSM-backed key management.

Q12: How do we prevent cloud misconfigurations?

1. Use Infrastructure as Code (Terraform, CloudFormation, ARM) with security policies baked in.
2. Deploy CSPM (Wiz, Prisma Cloud, Orca) for continuous scanning.
3. Implement automated remediation for critical findings (e.g., public S3 bucket → auto-remediate to private).
4. Conduct quarterly cloud security reviews with architecture diagrams.
5. Train cloud administrators on secure configuration (AWS Well-Architected, Azure Security Benchmark, CIS Benchmarks).

Q13: What is the best SIEM for cloud security?

• Azure-heavy: Microsoft Sentinel (best integration, KQL, efficient for Microsoft shops)
• AWS-heavy: Amazon Security Lake + OpenSearch, or Splunk with AWS integration
• GCP-heavy: Google Chronicle (best threat intelligence, YARA-L)
• Multi-cloud: Splunk Cloud, Elastic Cloud, or Datadog Security (best multi-cloud support)
• Budget-conscious: Elastic Cloud (open-source core, flexible pricing)

Q14: How do we handle cloud account takeover?

1. Enforce MFA for all accounts (hardware tokens for privileged users).
2. Implement conditional access (block logins from impossible locations, unknown devices).
3. Enable anomaly detection (GuardDuty, Sentinel, Chronicle) for unusual login patterns.
4. Define an account takeover response playbook: disable account, revoke sessions, force password reset, investigate lateral movement, notify affected users.
5. Implement zero-standing privileges (PIM, just-in-time access) to limit blast radius.

Q15: Do we need a cloud-specific incident response plan?

Yes. Cloud incidents differ from on-premises incidents in key ways: IAM is the primary attack vector, logs are in cloud APIs, isolation requires cloud-native tools, and forensics requires cloud snapshots. Your IR playbook must include cloud-specific procedures for AWS, Azure, and GCP.

Q16: How do we manage cloud costs while maintaining security?

Cloud cost optimization and security are aligned. Unused resources (orphaned VMs, old snapshots) are both damaging and risky. Use FinOps tools (CloudHealth, Finout, Azure Cost Management) to identify waste. Integrate cost anomaly alerts with the SOC. Use reserved instances and savings plans for stable workloads to reduce cost without compromising security.

Q17: What is the difference between CSPM and CWPP?

• CSPM scans cloud configurations (IAM policies, storage buckets, network rules, encryption settings) for misconfigurations and compliance violations. It is agentless and runs against the cloud control plane.
• CWPP protects workloads (VMs, containers, serverless functions) with runtime protection, vulnerability scanning, and behavioral monitoring. It requires an agent or sidecar on the workload.

For complete cloud security, you need both CSPM (configuration) and CWPP (runtime).

Q18: How does A.5.23 relate to Clause 8.1 (Operation) and Clause 9.1 (Monitoring)?

• Clause 8.1 requires planned and controlled operations. Your cloud security operations (IAM reviews, CSPM monitoring, log analysis) must be planned and documented.
• Clause 9.1 requires monitoring and measurement of the ISMS. Your cloud security metrics (Section 13) are a key input to Clause 9.1. They should be reviewed in management review (Clause 9.3) and used to drive improvement (Clause 10).

Q19: Can we use open-source tools for cloud security instead of commercial CSPM?

Yes, with caveats. Open-source tools like Prowler (AWS), CloudSploit, ScoutSuite, and Cloud Custodian provide excellent CSPM capabilities. However, they require more engineering effort, lack commercial support, and may not have the same audit-ready reporting. For growing companies and enterprise organizations, commercial CSPM is usually more efficient when considering overall value.

Q20: What is the minimum viable A.5.23 program for a startup with 20 employees?

1. Cloud Service Register (spreadsheet) with all services, data types, and owners.
2. MFA on all cloud admin accounts (Google Workspace, AWS root, GitHub).
3. Encryption at rest on all cloud storage and databases.
4. TLS 1.2+ on all cloud endpoints.
5. Basic cloud logging (CloudTrail, Google Workspace audit logs) retained for 12 months.
6. A simple cloud security policy (2 pages) with approval workflow and prohibited services list.
7. Annual access review.
8. Verified CSP certifications (SOC 2 or ISO 27001) for services storing customer data.

This can be implemented in 2–3 weeks. At Stage 2, expect the auditor to sample the cloud register, a risk assessment, provider assurance evidence, configuration of one or two key services, and an exit plan.

References and Further Reading

Standards and Frameworks

• ISO/IEC 27001:2022, Information Security, Cybersecurity and Privacy Protection, Information Security Management Systems, Requirements
• ISO/IEC 27002:2022, Information Security, Cybersecurity and Privacy Protection, Information Security Controls
• ISO/IEC 27017:2015, Information Technology, Security Techniques, Code of Practice for Information Security Controls Based on ISO/IEC 27002 for Cloud Services
• ISO/IEC 27018:2019, Information Technology, Security Techniques, Code of Practice for Protection of Personally Identifiable Information (PII) in Public Clouds
• NIST SP 800-53 Rev 5, Security and Privacy Controls for Information Systems and Organizations
• NIST CSF 2.0, Cybersecurity Framework
• CIS Controls v8, CIS Controls
• COBIT 2019, Framework for the Governance and Management of Enterprise IT

Regulatory References

• Digital Personal Data Protection Act, 2023 (India)
• Information Technology Act, 2000 (as amended) and IT Rules, 2011
• Reserve Bank of India, Master Direction on Information Technology Framework for NBFCs (2017, updated 2024)
• Reserve Bank of India, Cybersecurity Framework for Banks (2016, updated 2024)
• Reserve Bank of India, Storage of Payment System Data (2019)
• SEBI, Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities (20 August 2024)
• SEBI, SEBI CSCRF (Cybersecurity and Cyber Resilience Framework for SEBI Regulated Entities, 20 August 2024)
• IRDAI, Information and Cyber Security Guidelines (2023, which replaced the 2017 guidelines)
• Ministry of Electronics and Information Technology (MeitY), Policy on Adoption of Cloud by Government (2023)
• CERT-In, Directions under Section 70B of the IT Act (2022)
• GDPR Regulation (EU) 2016/679
• PCI DSS v4.0.1, Payment Card Industry Data Security Standard
• SOC 2 Trust Services Criteria, AICPA

Cloud Provider Security Documentation

• AWS Well-Architected Framework, Security Pillar (2024)
• AWS Security Documentation (aws.amazon.com/security)
• Microsoft Azure Security Benchmark (2024)
• Microsoft Defender for Cloud Documentation (learn.microsoft.com)
• Google Cloud Security Foundations Guide (2024)
• Google Cloud Security Command Center Documentation (cloud.google.com/security)

Industry Resources

• Cloud Security Alliance (CSA), Security Guidance for Critical Areas of Focus in Cloud Computing v4.0
• CSA STAR (Security, Trust, Assurance, and Risk) Program (cloudsecurityalliance.org/star)
• OWASP Cloud Security Project (owasp.org)
• SANS Institute, Cloud Security Curriculum
• ISACA, Cloud Computing Management Audit/Assurance Program

Books and Publications

• Kohnke, A., The Canadian Press, and A. Cloud Security: A Complete Guide to Secure Cloud Computing (2022)
• Rittinghouse, J.W., and J.F. Ransome. Cloud Computing: Implementation, Management, and Security (2017)
• Krutz, R.L., and R.D. Vines. Cloud Security: A Complete Guide to Secure Cloud Computing (2010)
• SANS Reading Room: Cloud Security papers (sans.org/reading-room)