Cloud services under ISO 27001: selection criteria and controls for integration into the ISMS

Many companies face the same tension today: Cloud services promise speed and scalability, the ISMS requires demonstrability, controlled operation and clear responsibilities. Exactly here the focus topic Cloud services under ISO 27001 becomes practically relevant. Not because the standard fundamentally complicates ‚cloud‘, but because it requires you to systematically identify risks, implement controls effectively and document everything in an audit-ready way. That sounds like paperwork — but in the cloud it quickly turns into concrete operational questions: Who is allowed to do what? Where is data stored? How is logging performed? How do we respond to incidents? And how do we exit if necessary?

This article provides a reliable selection and integration logic: decision criteria for procurement, concrete controls for integration into the ISMS, typical audit perspectives and implementation guidance from an operational viewpoint. The focus is on IaaS/PaaS/SaaS, i.e. infrastructure, platform and application services from the cloud — each with consequences for governance, administration and security.

Cloud services under ISO 27001 in practice

In audits and internal reviews recurring patterns appear that are not tied to individual configurations, but to unclear interfaces between provider and customer:

• Unclear responsibilities: The Shared Responsibility Model (shared responsibility between provider and customer) is not translated into tasks, roles and demonstrable evidence in day-to-day operations.
• Too broad scope: ‚We use the cloud‘ does not replace scope definition. Without a service map, data flows and dependencies, risk work is ad hoc.
• Vendor selection without a security addendum: Procurement and the business prioritize functionality; IT/Security are involved too late. Result: SLAs without security metrics, missing audit rights, unclear subcontractors.
• Missing logging design: Logs exist but are not centralized, not correlated, have no retention rules and no assigned ownership. In an incident, then ’nothing is provable‘.
• No exit plan: In the cloud, lock-in is rarely ‚only price‘. It involves data formats, IAM couplings, proprietary services and missing migration paths.

ISO 27001 does not require maximal control, but appropriate, justified control. The decisive step is therefore to treat cloud services as a supplier relationship plus a critical operational platform — with technical Controls that can be audited.

Context: ISO 27001, Annex A and what ‚cloud‘ changes

ISO 27001 requires an information security management system (ISMS) with a risk-based approach, measurable effectiveness and continuous improvement. Annex A (control objectives/Controls, restructured in ISO/IEC 27001:2022) is a toolbox, not a mandatory catalog of ‚everything always‘. In the cloud the implementation shifts:

• Controls become more contractual and procedural (e.g. supplier management, audit evidence, subcontractor transparency).
• Controls become more configuration-driven (e.g. IAM, encryption, network segmentation), because you control less ‚physically‘.
• Evidence becomes more data-driven (e.g. log extracts, configuration exports, change records), because classic server checklists no longer fit.

In practice it is helpful to classify by service model: With SaaS you primarily control identities, permissions, data, integrations and supplier management. With PaaS platform settings, network and runtime controls are added. With IaaS you bear significantly more responsibility for operating systems, hardening, patching and network architecture.

Selection criteria: How to evaluate cloud services before procurement

From an ISMS perspective the selection phase is the most cost-effective time to embed security and auditability. Later every gap becomes expensive: contract amendments, workarounds, shadow IT or additional tools.

1) Scope-fit and data flows: What exactly should go into the cloud?

Don’t start with features, but with information assets: Which types of data does the service process (personal, confidential, critical for operations)? Which systems are connected (ERP, IAM, email, ticketing)? A service that exports and distributes data requires different controls than an isolated tool.

Practical minimum evidence: service profile with purpose, data categories, interfaces, user groups, critical dependencies and operational windows. This later becomes the bridge to risk assessment, the Statement of Applicability (SoA) and internal audits.

2) Translate the Shared Responsibility Model into tasks

Many providers document the shared responsibility. For your ISMS that is not sufficient unless it is translated into concrete tasks: Who configures MFA? Who reviews logs? Who is responsible for keys? Who patches (in IaaS)?

A RACI matrix (Responsible, Accountable, Consulted, Informed) per control area has proven effective. Decisive is „Accountable“: an internal role that, if necessary, carries the responsibility toward auditors and management.

3) Supplier capability: Evidence, audit rights, subcontractors

ISO 27001 explicitly addresses supplier management. For cloud this means: you need reliable information on security measures, sub-processors/subcontractors, location/region issues and on notifications in the event of security incidents. Check in particular:

• Audit and evidence strategy: Do you receive appropriate reports/evidence (e.g. independent audit reports), and are these sufficient for your scope?
• Transparency regarding subcontractors: Are sub-service providers named, are changes announced, and is there a right to object?
• Reporting channels and deadlines: Security incident notification, contact persons, 24/7 contact, minimum contents of the notification.
• Service continuity: availability, maintenance windows, emergency processes, backup/RESTore (often the sticking point for SaaS).

If you want to deepen supplier risks: plan an internal link to your supplier management article (contract clauses, technical acceptance criteria, onboarding process).

4) Technical integration capability: IAM, logging, network, keys

A cloud service is not „a tool“, but part of your security architecture. Therefore, review the integration points in advance:

• IAM integration: SSO (Single Sign-On), SCIM (automated provisioning/deprovisioning), role model, support for MFA and Conditional Access.
• Logging: export to your central logging/SIEM, log details (admin actions, authentication, data access), retention, timestamp consistency.
• Network and access: private endpoints, IP RESTrictions, tenant isolation, API access, rate limits.
• Encryption/key management: encryption at REST/in transit, customer keys (BYOK/CMK), rotation, HSM options, key access by the provider.

These points are not „nice to have“. They determine whether controls are affordable and auditable in operation or whether you will have to perform manual rework on an ongoing basis.

5) Cost and operational consequences: Security is also an ongoing effort

Cloud costs are often understood as usage fees. However, additional costs relevant to ISO 27001 regularly arise in:

• Identity operations (SSO, role maintenance, recertification of privileges)
• Logging/monitoring (data volume, SIEM licenses, retention)
• Key and certificate management (HSM/Key Vault, rotation, processes)
• Audit and evidence effort (supplier reviews, annual assessments, internal audits)
• Exit readiness (data export, migration drills, parallel operation)

A clear decision document names these follow-up costs explicitly so that security measures do not start „underfunded“.

Controls for integration into the ISMS: pragmatic control families

Instead of memorizing individual Annex A numbers, it is more useful for implementation to structure cloud controls into control families. Each family should provide three things: (1) rule/policy, (2) technical implementation, (3) verifiable evidence.

Cloud governance: policies, roles, decision paths

Without governance, cloud security degenerates into case-by-case decisions. At a minimum you should define:

• Cloud service onboarding process (who approves, which checks, which minimum requirements)
• Role model (Service Owner, Information Owner, ISMS owner(s), operations/platform team, data protection)
• Change management (configuration changes, permissions, integrations; approvals and documentation)
• Exceptions management (risk acceptance with deadline, compensating controls, review date)

Audit perspective: auditors look less for „the perfect policy“ and more for evidence that decisions are made consistently, based on risk, and are repeatable.

Asset and data management: classification, data residency, lifecycle

In the cloud, data classification is the anchor: it determines which controls are mandatory (e.g., encryption, access RESTrictions, DLP). Define:

• Data classes (e.g., public, internal, confidential, strictly confidential) and clear examples.
• Permitted cloud usage per class (which service categories are allowed, which regions/locations).
• Retention and Deletion including evidence (Deletion Requests, Retention Policies, E-Discovery requirements).

Important in practice: With SaaS, „deletion“ is often a process (soft delete, retention, backups). Your ISMS must reflect and assess this reality, not idealize it.

Identity and Access Management (IAM): the most frequent cloud audit finding

IAM is the area with the most findings in cloud projects, because it grows rapidly and is closely aligned with business units. Minimum controls:

• SSO and MFA for all privileged accounts, preferably for all users.
• Least Privilege (minimum necessary permissions) and roles instead of individual special permissions.
• Joiner/Mover/Leaver: automated provisioning/deprovisioning, ideally with SCIM.
• Regular recertification of permissions (who reviews, how it is documented, what frequency based on risk).
• Break-Glass-Accounts: emergency access with strong safeguards, separate monitoring and documented use.

Evidence auditors accept: role export, MFA status, records of recertifications, tickets/changes for role modifications, logging of admin actions.

Encryption and key management: from „ticking a box“ to controlled practice

„Encryption enabled“ is not a control as long as key access, rotation and responsibilities are unclear. For cloud services you should define:

• Encryption in transit: TLS standards, certificate management, no insecure protocols.
• Encryption at REST: standard encryption, possibly customer-managed keys (Customer Managed Keys).
• Key Lifecycle: rotation, access (who may manage keys), separation of duties (Separation of Duties).
• Backups and exports: encryption also outside the platform, particularly for data exports.

Practical consequence: If you choose BYOK/CMK, you must be able to operate it (processes, monitoring, emergency access). Without this capability, „own keys“ are often only apparent control.

Logging, Monitoring and Detection: auditable instead of ‚we could‘

ISO 27001 does not mandate a specific SIEM solution, but it requires the ability to detect, investigate and demonstrate events. In the cloud you therefore need to clarify:

• Which events are logged? Authentication, admin actions, policy changes, data exports, API calls, errors/anomalies.
• Where do the logs end up? Centralized, tamper-protected (write-once/immutable storage where possible), with defined retention.
• Who responds? Responsibilities, alerting paths, on-call/backup, runbooks.

A common practical mistake is ‚too much logging without a plan.‘ Better is a risk-based logging profile per service class plus a minimal set that is always active (notably admin and IAM events).

Beispiel: Minimaler Audit-Nachweis-Ordner je Cloud-Service (Strukturvorschlag)
01_Service-Steckbrief.pdf
02_Risikoanalyse_und_Risikobehandlung.pdf
03_SoA_Zuordnung_Controls.pdf
04_Vertrag_und_Sicherheitsanhang.pdf
05_RACI_und_Betriebsmodell.pdf
06_IAM_Rollenexport_MFA_Nachweise/
07_Logging_Forwarding_Nachweise/
08_Change_Records_und_Ausnahmen/
09_Incident_Runbooks_und_Tests/
10_Exit_Plan_und_Exporttests/

Vulnerability and Patch Management: varies by service model

Here SaaS and IaaS clearly diverge:

• SaaS: Provider patches the platform and application. Your controls are in configuration, IAM, integrations, endpoints and in assessing the provider’s release/change information.
• PaaS: Provider patches base services; you may need to patch runtimes/dependencies in your application. Policies on supported versions and deployments are important.
• IaaS: You patch operating systems and applications. That’s a classic patching and hardening program, only using cloud tooling.

Audit perspective: It will be checked whether responsibilities are clear, whether vulnerability assessment takes place and whether there is a procedure to implement or mitigate critical updates in a timely manner.

Backup, RESTore and Business Continuity: RTO/RPO and real recovery

In cloud projects availability is often confused with ‚the provider is highly available.‘ For your ISMS, however, your business requirements matter. Define:

• RTO/RPO (Recovery Time Objective/Recovery Point Objective): How quickly and with what data loss must we be able to recover?
• Backup scope: Configurations (IAM, policies), data, key material (where permitted), integration configurations.
• RESTore tests: frequency, success criteria, records. Without tests, backup is weak in an audit.

With SaaS, the critical points are often: what export options exist? How quickly can you get data out in an emergency? Which dependencies on identity or email prevent access?

Incident Management and Forensics: what’s different in the cloud

Incident response in the cloud is primarily a matter of access to evidence and coordination. Define per service:

• Contact channels to the provider (security hotline, ticket priority, escalation).
• Evidence preservation: Which logs, snapshots or exports are possible? Which retention is active?
• Roles: Who leads, who decides on shutdown/isolation, who communicates internally/externally?

A verifiable proof is a tested runbook (a tabletop exercise is sufficient to start), including lessons learned and action tracking.

Change and configuration management: cloud-compliant, not server-centric

ISO 27001 expects controlled changes. In the cloud this means: changes often occur in configurations, policies and roles. Effective controls include:

• Baseline configurations per service class (e.g. MFA on, logging enabled, admin roles RESTricted).
• Change records for security-relevant changes (permissions, network, keys, logging).
• Regular configuration reviews and deviation handling.

If you use Infrastructure as Code (IaC): it supports traceability, but it is not automatic. What matters is the process: review, approval, rollback, and detection of manual changes.

Exit strategy and portability: a control against lock-in and operational risk

An exit plan is a very strong argument in risk treatment under ISO 27001 because it reduces dependencies and increases ability to act in a crisis. A practical exit plan includes:

• Data export: formats, completeness, frequency, encryption, integrity (checksums), responsible parties.
• Configuration export: roles, policies, integrations, automations.
• Migration path: target platform options, critical dependencies, minimum test (e.g. annual export/RESTore test).
• Contractual terms: deadlines, support, deletion, handover, costs.

Important: exit is not a „project at the end“, but a capability. Small, regular tests are more cost-effective than a large migration under time pressure.

Audit perspective: which evidences really matter in cloud setups

Many teams document too much in the wrong place (long text) and too little in the right place (auditable artifacts). In cloud audits, the following typically count:

• Scope and inventory: which cloud services are in the ISMS scope, with owners and purpose.
• Risk assessment: traceable risks per service or service class, including risk treatment.
• SoA: justified selection of controls, including implementation/status.
• Supplier record: contract, security appendix, evidence/reports, subcontractor information, reviews.
• Operational evidence: IAM exports, recertification protocols, logging forwarding, incident exercises, RESTore tests.

If you want to structure to be audit-ready, plan an internal link to an „Audit-Ready“ checklist. That improves both preparation and the quality of daily recordkeeping.

Practical checklist: Onboard a cloud service ISMS-compliantly in 10 steps

1. Create a service profile (purpose, data, interfaces, users, owner).
2. Establish data classification and permitted regions/residency.
3. Document Shared Responsibility as a RACI per control family.
4. Perform a supplier review including subcontractors, incident notification, evidence.
5. Perform a risk assessment, plan risk treatment (including compensating measures).
6. Finalize contract/security appendix (SLA, logging, support, exit, audit information).
7. Integrate IAM (SSO, MFA, roles, SCIM, break-glass).
8. Logging/Monitoring integrate, define retention and alerting.
9. BCM/Backup/RESTore clarify and plan at least one test.
10. Exit-Minimaltest define (export + validation) and include in the annual plan.

This sequence is deliberately chosen so that governance and evidence are not ‚retrofitted‘ afterwards, but procurement and operations are viable from the outset.

Responsibilities and governance in day-to-day operations: who must decide what?

Cloud integration into the ISMS often fails due to implicit assumptions: ‚Security will do it‘ or ‚the provider is responsible‘. For decisions that hold up, clear roles are required:

• Service Owner: functional responsibility, budget, accepts residual risks within the framework of governance.
• Information Owner: responsible for data protection requirements/data classification (often the business unit, supported by IT/Compliance).
• Cloud Platform/Operations: technical baselines, logging, accounts, automation, operations.
• ISMS/Compliance: methodology, risk assessment, SoA, evidence management, audit communication.
• Security: controls, monitoring, incident response, exception assessments.
• Datenschutz (if applicable): legal bases, data processing agreements, international transfers.

Executive management is not ‚responsible for the details‘, but must support governance: by issuing clear mandates, providing resources for controls, and defining the risk appetite.

Conclusion: Using cloud services in an ISO 27001-compliant way means making controlled decisions

Cloud services under ISO 27001 are not a contradiction — but only manageable if selection, contract, configuration and operation are understood as an integrated control system. The central lever is not a single tool but your ability to assign responsibilities clearly, document data flows and risks, and implement technical controls so they hold up in daily operations and audits.

If you want to start pragmatically: establish a service profile, a standard package of IAM and logging minimum requirements, a supplier security appendix and an exit minimal test. This reduces typical cloud risks (uncertainty, lack of evidence, lock-in) significantly — without overloading your ISMS with paperwork.

For this topic, ISMS Cloud Integration and Cloud Governance are also important. The article places these aspects into context in a comprehensible way and shows what matters in everyday operations.