What is ISO 27001 Annex A 5.23 – Information Security for Use of Cloud Services?

ISO 27001 Annex A 5.23 focuses on ensuring that information security is properly managed throughout the acquisition, use, management, monitoring, and termination of cloud services.

Modern organizations increasingly depend on cloud platforms such as:

• Amazon Web Services (AWS)
• Microsoft Azure
• Google Cloud Platform (GCP)
• Microsoft 365
• Google Workspace
• Salesforce
• GitHub
• Slack
• Dropbox
• Cloudflare
• HubSpot
• Atlassian
• Snowflake
• Datadog
• Cloud-based HR, finance, CRM, ERP, and security platforms

The objective is not simply to maintain a list of cloud vendors.

The organization should understand:

1. What cloud services it uses
2. What information is stored or processed in those services
3. What security responsibilities belong to the organization
4. What responsibilities belong to the cloud provider
5. What risks the cloud service introduces
6. How the service is monitored and reviewed
7. How security is managed when the service changes
8. How data and services will be handled when the organization exits the cloud service

Simple Explanation

Before using a cloud service, understand the security risks and responsibilities. While using it, manage and monitor those risks. When leaving it, securely remove or transfer your information.

---

Why is ISO 27001 Annex A 5.23 Important?

Cloud services can significantly improve scalability and reduce infrastructure costs.

However, moving systems to the cloud does not automatically transfer security responsibility to the cloud provider.

For example, a cloud provider may secure:

• Physical data centers
• Physical servers
• Core networking
• Hypervisor infrastructure
• Certain underlying services

But the customer may still be responsible for:

• User accounts
• Identity and access management
• MFA
• Cloud configuration
• Security groups
• Storage permissions
• Application security
• Data classification
• Encryption configuration
• Logging
• Monitoring
• Backups
• API keys
• Secrets
• Vulnerability management

This is commonly referred to as the shared responsibility model.

Simple Principle

Using a secure cloud provider does not mean your cloud environment is automatically secure.

A misconfigured storage bucket, excessive IAM permission, exposed API key, publicly accessible database, or poorly configured firewall can still create a security incident.

---

What Does Annex A 5.23 Require?

Organizations should establish processes for the secure acquisition, use, management, monitoring, and exit from cloud services.

The controls should be proportionate to the organization’s information-security risks.

A startup using a SaaS CRM to manage basic business contacts will not necessarily require the same level of controls as a fintech company processing sensitive financial information in a cloud environment.

The organization should therefore consider:

• Type of information
• Sensitivity of information
• Regulatory requirements
• Business criticality
• Cloud architecture
• Access requirements
• Geographic considerations
• Provider security capabilities
• Service availability
• Supplier dependencies
• Exit requirements

---

Cloud Security Lifecycle

A practical way to implement A.5.23 is:

Select → Assess → Contract → Configure → Use → Monitor → Review → Change → Exit

Each stage should have appropriate security controls.

---

1. Identify All Cloud Services

The first step is understanding what cloud services the organization actually uses.

Create a Cloud Services Register.

Examples:

Cloud Service	Purpose	Data	Criticality	Owner
AWS	Production infrastructure	Customer/application data	Critical	CTO
GitHub	Source code	Proprietary code	High	Engineering
Google Workspace	Email & documents	Business information	High	IT
Slack	Communication	Business information	Medium	Operations
HubSpot	CRM	Customer information	High	Sales
Cloudflare	DNS/CDN/WAF	Technical/network data	High	DevOps

Do not limit the register to services purchased directly by IT.

Employees may independently use:

• ChatGPT or other AI services
• File-sharing platforms
• Online productivity tools
• SaaS applications
• Collaboration platforms
• Developer tools
• Browser-based applications

This can create shadow IT.

---

2. Classify the Information Stored in Cloud Services

Understand what information is being stored or processed.

For example:

Cloud Service	Information	Classification
AWS	Customer application data	Confidential
GitHub	Source code	Confidential
Google Drive	Internal policies	Internal
Payroll SaaS	Employee information	Confidential
Public website hosting	Public website content	Public

This helps determine how much security control is required.

---

3. Perform Cloud Security Risk Assessment

Before adopting a critical cloud service, assess its security risks.

Consider:

Data Risk

• What information will be stored?
• Is personal information involved?
• Is financial information involved?
• Is customer information involved?
• Is confidential intellectual property involved?

Access Risk

• How are users authenticated?
• Is MFA supported?
• Can administrators use privileged accounts?
• Are roles and permissions configurable?

Technical Risk

• What encryption is available?
• What logging is available?
• What monitoring is available?
• What security controls are configurable?

Availability Risk

• What happens if the service becomes unavailable?
• Is there a backup?
• Is there an alternative provider?
• What are the provider’s availability commitments?

Compliance Risk

Consider applicable requirements such as:

• ISO 27001
• SOC 2
• GDPR
• DPDP Act
• HIPAA
• PCI DSS
• RBI requirements
• Contractual customer requirements

---

4. Understand the Shared Responsibility Model

One of the most important aspects of cloud security is understanding who is responsible for what.

For example:

Security Area	Cloud Provider	Customer
Physical data center	Usually Provider	No
Physical infrastructure	Usually Provider	No
Hypervisor	Usually Provider	No
Operating system	Depends on service	Often Customer
Application	No	Customer
User access	No	Customer
IAM configuration	Shared/Customer	Customer
Data	No	Customer
Encryption configuration	Shared	Customer
Logging configuration	Shared	Customer
Backup configuration	Often Shared	Customer responsibility varies
Security monitoring	Shared	Shared

The exact division of responsibility depends on the cloud service model.

For example:

• IaaS
• PaaS
• SaaS

should not automatically be treated the same way.

---

5. Perform Security Due Diligence Before Using a Cloud Service

Before adopting an important cloud service, evaluate the provider.

Possible evidence includes:

• ISO 27001 certification
• SOC 2 report
• Penetration-testing information
• Security whitepaper
• Data-processing agreement
• Privacy documentation
• Business continuity information
• Disaster recovery information
• Incident-management process
• Vulnerability-management information
• Subprocessor information
• Data-location information
• Encryption information

However:

A provider’s ISO 27001 certificate or SOC 2 report does not automatically mean your implementation is secure.

You should understand the scope and limitations of the assurance report.

---

6. Establish Cloud Security Requirements

Security requirements should be defined before using important cloud services.

Typical requirements may include:

Identity and Access

• MFA
• Role-based access
• Least privilege
• Privileged access management
• Access reviews

Data Protection

• Encryption
• Data classification
• Data retention
• Secure deletion
• Backup

Monitoring

• Logging
• Security monitoring
• Alerting
• Incident detection

Resilience

• Backup
• Disaster recovery
• Availability requirements
• Recovery objectives

Compliance

• Applicable laws
• Customer requirements
• Contractual requirements
• Audit requirements

---

7. Securely Configure Cloud Services

A cloud provider can offer strong security capabilities, but the customer must configure them appropriately.

Examples include:

• Enable MFA
• Disable unnecessary accounts
• Apply least privilege
• Restrict administrative access
• Configure network controls
• Disable public access where unnecessary
• Enable logging
• Enable monitoring
• Protect API keys
• Protect secrets
• Encrypt sensitive data
• Configure backups
• Monitor configuration changes

For infrastructure platforms such as AWS, Azure, or GCP, organizations should establish a baseline secure configuration.

---

8. Manage Cloud Access

Cloud environments often contain powerful administrative capabilities.

For example, a user with excessive AWS or Azure privileges could:

• Delete production systems
• Access customer data
• Disable logging
• Change network rules
• Create credentials
• Modify security controls

Therefore:

Cloud access should follow least privilege.

Access should be:

Requested → Approved → Granted → Reviewed → Modified → Removed

Privileged access should receive additional controls.

---

9. Protect Cloud Credentials and Secrets

Cloud environments frequently use:

• API keys
• Access keys
• Service accounts
• Tokens
• SSH keys
• Database credentials
• Application secrets
• CI/CD credentials

These should not be stored casually in:

• Source code
• Git repositories
• Public documents
• Chat messages
• Email
• Spreadsheets

Use appropriate secret-management mechanisms.

Examples include:

• Cloud secret managers
• Password managers
• Key management services
• Secure CI/CD secret stores

---

10. Monitor Cloud Security

Security management should continue after deployment.

Organizations should monitor:

• Failed login attempts
• Privileged activity
• Configuration changes
• Public exposure
• Security alerts
• Vulnerabilities
• Suspicious activity
• Unusual data access
• Cloud service incidents
• Provider security notifications

For critical cloud environments, security monitoring should be appropriately integrated with the organization’s incident-management process.

---

11. Review Cloud Services Periodically

Cloud services should not be approved once and then forgotten.

Periodic reviews should consider:

• Is the service still required?
• Is the data still appropriate?
• Has the provider changed?
• Has the service changed?
• Has the risk changed?
• Has the provider experienced incidents?
• Has the provider changed subprocessors?
• Has the data location changed?
• Has the organization changed its regulatory requirements?
• Are users still requiring access?

---

12. Manage Changes to Cloud Services

Cloud services continuously evolve.

Changes may include:

• New functionality
• New hosting locations
• New subprocessors
• New APIs
• New authentication mechanisms
• New pricing/service models
• Acquisitions
• Changes in ownership
• Changes to data processing
• Major architectural changes

Security impact should be assessed when significant changes occur.

This connects A.5.23 closely with A.5.22 – Monitoring, Review and Change Management of Supplier Services.

---

13. Plan for Cloud Service Exit

A common mistake is planning how to start using a cloud service but not how to leave it.

Organizations should consider:

• How data will be exported
• Whether data is portable
• How backups will be transferred
• How accounts will be closed
• How credentials will be revoked
• How data will be securely deleted
• How customers will be informed where required
• How applications will be migrated
• Whether another provider is available
• Whether vendor lock-in exists

Simple Principle

Every critical cloud service should have an exit strategy.

---

Startup Example

Consider a SaaS startup with the following environment:

• AWS – production infrastructure
• GitHub – source code
• Google Workspace – email
• Slack – communication
• Cloudflare – DNS/CDN/WAF
• Stripe – payments
• HubSpot – CRM
• Datadog – monitoring

The startup creates a Cloud Services Register.

Example

AWS

→ Critical service
→ Customer data processed
→ Production infrastructure
→ High availability requirement
→ MFA required
→ Privileged access restricted
→ Logging enabled
→ Backup configured
→ Security monitoring implemented
→ Disaster recovery plan established
→ Exit/migration strategy documented

GitHub

→ Source code hosted
→ High confidentiality requirement
→ MFA required
→ Branch protection
→ Privileged access restricted
→ Repository access reviewed
→ Security alerts enabled
→ Backup/export strategy considered

This demonstrates that cloud security is not simply about selecting a reputable cloud provider.

It is about managing the entire cloud service lifecycle.

---

Startup-Focused Quick Summary

For most startups, A.5.23 can initially be implemented through seven practical activities:

1. Create a Cloud Services Register

List all important cloud services.

2. Classify the Data

Identify what information each service processes.

3. Assess the Risk

Identify criticality and security risks.

4. Review the Provider

Check security assurance, contracts, data handling, and relevant certifications.

5. Configure Security

Implement MFA, least privilege, logging, encryption, backups, and secure configuration.

6. Monitor and Review

Monitor security and periodically reassess the service.

7. Prepare for Exit

Document how data and services would be migrated or terminated securely.

---

Example Cloud Services Register

Service	Purpose	Data	Criticality	Security Controls	Owner	Last Review
AWS	Production	Customer data	Critical	MFA, IAM, logging, backup	CTO	Jan 2026
GitHub	Source code	IP/source code	High	MFA, branch protection	Engineering	Jan 2026
Google Workspace	Email/docs	Business data	High	MFA, DLP, access review	IT	Jan 2026
Slack	Communication	Internal information	Medium	MFA, access control	IT	Jan 2026
CRM	Customer management	Customer data	High	MFA, RBAC	Sales	Jan 2026

---

Cloud Security Risk Assessment

A simple startup assessment can include:

Question	Yes/No	Risk
Does the service process confidential information?	Yes	High
Does it process personal information?	Yes	High
Does it support MFA?	Yes	Medium
Is administrative access restricted?	Yes	Medium
Is encryption available?	Yes	Medium
Are logs available?	Yes	Medium
Does the provider provide security assurance?	Yes	Low/Medium
Are backups available?	Yes	Medium
Is there an exit strategy?	No	High
Are subprocessors disclosed?	Yes	Medium

The assessment should be proportionate to the service’s importance.

---

Cloud Security Baseline for Startups

A practical baseline may include:

Control	Recommended Baseline
MFA	Required for administrative and important accounts
Least privilege	Implement
Privileged accounts	Restricted
Logging	Enabled for critical environments
Monitoring	Implement for critical systems
Encryption	Enabled where appropriate
Secrets	Stored securely
Backups	Defined for critical information
Vulnerability management	Implemented
Configuration management	Implemented
Access reviews	Periodic
Incident response	Defined
Provider review	Periodic
Exit strategy	Defined for critical services

---

Audit Evidence for Annex A 5.23

An auditor may ask for evidence showing that cloud services are being managed securely.

Typical evidence includes:

Governance

• Cloud security policy
• Information security policy
• Cloud usage standards
• Risk assessment methodology

Cloud Inventory

• Cloud Services Register
• SaaS inventory
• Approved cloud provider list

Risk Management

• Cloud risk assessments
• Supplier due diligence
• Security questionnaires
• Risk treatment plans

Provider Assurance

• ISO 27001 certificates
• SOC 2 reports
• Security whitepapers
• Penetration-test summaries where available
• Data-processing agreements

Technical Evidence

• IAM configuration
• MFA configuration
• Security-group rules
• Cloud security dashboards
• Logging configuration
• Backup configuration
• Encryption configuration
• Vulnerability reports

Operational Evidence

• Access reviews
• Security monitoring records
• Incident records
• Configuration reviews
• Cloud service reviews
• Change-management records

Exit Evidence

• Data export procedures
• Migration plans
• Data deletion procedures
• Contract termination records
• Account revocation records

---

Audit Checklist

An auditor can ask:

Cloud Inventory

• Has the organization identified its cloud services?
• Is there a cloud service register?
• Are critical cloud services identified?
• Are unauthorized or shadow cloud services addressed?

Risk

• Are cloud services risk assessed?
• Is data classification considered?
• Are regulatory requirements considered?
• Are critical dependencies identified?

Provider Security

• Has appropriate supplier due diligence been performed?
• Has provider security assurance been reviewed?
• Are relevant contractual requirements established?
• Are subprocessors considered?

Configuration

• Is MFA enabled?
• Is least privilege implemented?
• Is privileged access restricted?
• Is logging enabled?
• Is sensitive information protected?
• Are secrets securely managed?
• Are backups configured where required?

Monitoring

• Are cloud security events monitored?
• Are vulnerabilities monitored?
• Are significant configuration changes reviewed?
• Are provider security notifications monitored?

Review

• Are cloud services periodically reviewed?
• Are risks reassessed?
• Are unnecessary cloud services removed?

Exit

• Is there an exit strategy for critical services?
• Can important data be exported?
• Are credentials revoked during termination?
• Is data securely deleted or returned?

---

Common Mistakes

1. Assuming the Cloud Provider Handles Everything

Cloud providers secure their part of the environment, but customers retain responsibilities.

---

2. No Cloud Inventory

Organizations often discover during an audit that different teams are using dozens of SaaS applications that were never formally reviewed.

---

3. Treating ISO Certification as Complete Due Diligence

A provider’s ISO 27001 certification can provide useful assurance, but it does not eliminate the need to understand:

• Scope
• Service coverage
• Customer responsibilities
• Configuration responsibilities
• Contractual requirements

---

4. Poor IAM Configuration

Examples include:

• Shared administrator accounts
• Excessive permissions
• No MFA
• Former employees retaining access
• Permanent privileged access

---

5. Exposed Storage

Publicly accessible storage or databases can create significant security risks.

---

6. Secrets Stored in Source Code

API keys and credentials should not be casually stored in repositories.

---

7. No Logging

Organizations may have sophisticated cloud infrastructure but insufficient visibility into administrative activity and security events.

---

8. No Exit Strategy

A company may discover that migrating away from a cloud service is extremely difficult because it never considered data portability or dependency management.

---

9. Ignoring Shadow IT

Employees may adopt SaaS applications without security review.

A startup should establish a process for approving new cloud services without unnecessarily slowing employees down.

---

Practical Startup Implementation Model

A simple model for A.5.23 is:

Discover → Classify → Assess → Approve → Configure → Monitor → Review → Exit

Discover

Identify cloud services.

Classify

Understand the information and business importance.

Assess

Evaluate security and compliance risks.

Approve

Approve the service based on risk.

Configure

Implement security controls.

Monitor

Monitor security events, vulnerabilities, and provider changes.

Review

Periodically reassess the service.

Exit

Securely migrate or terminate the service when required.

---

Policy vs. Process vs. Evidence

Area	Policy	Process	Evidence
Cloud usage	Cloud Security Policy	Cloud onboarding	Approved service
Provider assessment	Supplier Security Policy	Due diligence	Assessment
IAM	Access Control Policy	Access provisioning	Access records
Configuration	Secure Configuration Standard	Configuration review	Configuration evidence
Monitoring	Security Monitoring Policy	Cloud monitoring	Logs/alerts
Backup	Backup Policy	Backup process	Backup reports
Exit	Cloud Exit Policy	Service termination	Deletion/migration evidence

---

Relationship with Other ISO 27001 Controls

A.5.23 should not operate independently.

A.5.19 – Information Security in Supplier Relationships

Addresses security risks associated with supplier relationships.

A.5.20 – Information Security Within Supplier Agreements

Defines security requirements in supplier agreements.

A.5.21 – Information Security in the ICT Supply Chain

Addresses broader ICT supply-chain security.

A.5.22 – Monitoring, Review and Change Management of Supplier Services

Addresses ongoing monitoring and changes to supplier services.

A.5.23 – Information Security for Use of Cloud Services

Specifically addresses the secure acquisition, use, management, monitoring, and exit of cloud services.

A.5.15 – Access Control

Defines broader access-control principles.

A.5.18 – Access Rights

Addresses granting, reviewing, changing, and removing access.

A.8.8 – Management of Technical Vulnerabilities

Relevant to cloud infrastructure and applications.

A.8.15 – Logging

Supports monitoring of cloud activity.

A.8.16 – Monitoring Activities

Supports detection and monitoring.

A.8.32 – Change Management

Relevant when significant cloud configuration or service changes occur.

---

Useful Documents for A.5.23

A startup may maintain the following documents:

1. Cloud Security Policy
   [Insert Draft Document Link]
2. Cloud Services Register
   [Insert Draft Document Link]
3. Cloud Security Risk Assessment
   [Insert Draft Document Link]
4. Cloud Provider Due Diligence Questionnaire
   [Insert Draft Document Link]
5. Cloud Secure Configuration Standard
   [Insert Draft Document Link]
6. Cloud Access Review Checklist
   [Insert Draft Document Link]
7. Cloud Exit Checklist
   [Insert Draft Document Link]
8. SaaS / Shadow IT Register
   [Insert Draft Document Link]
9. Cloud Incident Response Procedure
   [Insert Draft Document Link]
10. Cloud Backup and Recovery Procedure
    [Insert Draft Document Link]

---

Questions an Auditor May Ask Management

During an ISO 27001 audit, management may be asked:

What cloud services does your organization use?

Which cloud services are critical to your business?

What type of information is processed by those services?

How did you assess the security risks before selecting the provider?

What security responsibilities remain with your organization?

How do you control administrative access?

How do you monitor cloud security?

How do you review changes made by your cloud providers?

What happens if a critical cloud provider becomes unavailable?

How would you securely exit the service?

These questions are designed to determine whether cloud security is actually managed rather than merely documented.

---

Startup-Focused Final Takeaway

ISO 27001 Annex A 5.23 is not about avoiding cloud services.

It is about using cloud services in a controlled and secure manner.

For a startup, the practical approach is:

Identify your cloud services
↓
Understand what data they process
↓
Assess the risks
↓
Review the provider
↓
Define security responsibilities
↓
Configure security controls
↓
Monitor the environment
↓
Review changes and risks
↓
Maintain an exit strategy

The key principle is:

Do not assume that moving to the cloud means security is outsourced. The cloud provider secures the services it provides; your organization must still manage the security responsibilities that remain with you.

A well-implemented A.5.23 control gives the organization confidence that cloud services are not simply being purchased and used, but are being selected, configured, monitored, reviewed, and exited in a controlled manner.

Quick Auditor Test

If your organization can clearly answer these five questions, you are on the right track:

1. What cloud services do we use?
2. What information do they process?
3. What security responsibilities belong to us?
4. How do we monitor and review them?
5. How would we securely exit a critical cloud service?

Simple sequence:

Discover → Assess → Secure → Monitor → Review → Exit