ISO 27001 and the CISPE Code: Cloud Privacy Assurance

ISO/IEC 27001 certification and adherence to the CISPE Data Protection Code can both support cloud assurance, but they answer different questions.

ISO/IEC 27001 is an international standard for an information security management system. Certification assesses whether an organisation’s in-scope ISMS conforms to the standard’s requirements. The CISPE Code is a sector-specific GDPR code of conduct focused on cloud infrastructure services acting in a processor role. Adherence applies to declared services and is subject to the Code’s governance and monitoring arrangements.

Neither signal removes the customer’s responsibility to assess its own processing, configuration, contracts and legal obligations.

Compare purpose and scope

Question	ISO/IEC 27001	CISPE Code
Primary purpose	Manage information-security risks through an ISMS	Address data-protection responsibilities for declared IaaS services
Unit of scope	Defined organisational ISMS scope	Specific declared cloud infrastructure service
Main assurance	Certification by a competent certification body when certification is sought	Adherence and monitoring under the Code’s approved arrangements
Focus	Confidentiality, integrity and availability across people, process and technology	Processor obligations, transparency and safeguards for IaaS processing
Customer result	Evidence about the provider’s in-scope management system	Evidence about a declared service’s Code adherence
Does it prove the customer’s compliance?	No	No

The official ISO/IEC 27001 overview explains the standard’s risk-management purpose. The current CISPE Code site describes its IaaS focus, independent monitoring and service declaration model.

Understand the service boundary

Cloud provider evidence is useful only when it covers the service, region, functions and responsibility boundary the customer will use.

For ISO 27001, inspect:

• certificate status and issuing body;
• exact certified organisation;
• scope statement;
• included locations and services;
• standard edition;
• issue and expiry dates; and
• relevant exclusions or boundaries.

For the CISPE Code, inspect:

• provider and declared service;
• declaration status;
• current public-register entry;
• whether the service is candidate or independently verified as compliant;
• monitoring body information;
• applicable locations or service conditions; and
• the current Code version and evidence.

A provider may hold ISO 27001 certification while only some services are within scope. Likewise, a CISPE declaration is service-specific. Do not extend either claim to an entire cloud portfolio without evidence.

Keep shared responsibility explicit

Infrastructure providers secure facilities, physical hardware, core networking, virtualisation and other platform elements within their control. Customers normally retain important responsibilities for what they deploy and how they configure it.

Customer responsibilities commonly include:

• lawful purpose and data governance;
• identity and access;
• guest operating systems and applications;
• network configuration;
• encryption choices and key management;
• logging and monitoring;
• data classification and retention;
• vulnerability and change management;
• backup and recovery design;
• incident response; and
• user and administrator behaviour.

The exact boundary depends on the service and contract. Record it as a control ownership model rather than relying on a marketing phrase.

The supplier audit guide explains how to connect contract, risk and operating evidence.

Use ISO 27001 evidence for management-system assurance

An ISO 27001 certificate can support confidence that the provider operates a structured ISMS within the stated scope. It does not disclose every selected control or guarantee that the customer’s configuration is secure.

Ask for evidence proportionate to risk, such as:

• certificate and scope;
• relevant statement about control applicability;
• independent assurance reports where contractually available;
• security responsibility documentation;
• incident and vulnerability processes;
• continuity and recovery information;
• subprocessor or supplier governance;
• customer configuration guidance; and
• remediation status for material findings.

The Annex A selection and evidence guide can help customers distinguish a control theme from proof that it operates in the relevant scope.

Use CISPE evidence for IaaS privacy assurance

The current CISPE Code is focused on IaaS providers acting as processors. Its service-level status can support due diligence about processor obligations, transparency, data handling and security responsibilities.

The European Data Protection Board register explains that adherence to an approved code provides a structured approach to GDPR compliance and lists Cloud Infrastructure Service Providers Europe as a code owner.

For a candidate service, distinguish self-assessment from independent verification. The CISPE site states that the compliant mark is for services whose adherence has been verified by an independent monitoring body. Record the exact mark and date observed.

Do not rely on an old CISPE page describing the pre-May 2021 version. CISPE itself directs readers from that historical page to the current Code site.

Build an evidence-led due-diligence file

1. Define the processing

Record the intended service, data categories, data subjects, purposes, locations, users, integrations, retention and risk. Determine whether the organisation is a controller, processor or part of a longer processing chain.

2. Map responsibility

Assign provider, customer and shared responsibilities. Include security configuration, rights requests, incident notification, deletion, transfer, backup and evidence access.

3. Verify assurance scope

Match the planned service to the ISO certificate scope and CISPE declaration. Resolve different legal entities, product names and regions.

4. Evaluate gaps

Identify requirements not answered by either assurance signal. These may include sector residency rules, customer-managed keys, log retention, recovery targets, penetration evidence or subprocessor restrictions.

5. Put material commitments in the contract

Use enforceable terms for processing instructions, confidentiality, security, subprocessors, assistance, incident notification, deletion or return, audit information, location and exit.

Legal counsel should determine the terms required for the organisation’s role and jurisdiction.

6. Test the customer side

Review architecture and configuration before production use. Evidence may include identity settings, network restrictions, logging, encryption, key custody, recovery tests and monitoring.

7. Monitor change

Reassess material changes to service, processing, region, assurance status, subprocessors, incidents or law. Supplier approval is not permanent.

The evidence register guide shows how to index proof while preserving ownership and freshness.

Evidence freshness matters

Certificates, declarations and reports are time-bound. Record:

• source URL or provider channel;
• collection date;
• service and legal entity;
• assurance period;
• scope;
• reviewer;
• identified limitations;
• next review date; and
• change triggers.

Do not preserve a screenshot alone. Retain enough context to show what was verified and what decision it supported.

Audit sampling

For a cloud-supplier audit, build a population of in-scope services and select samples by data sensitivity, criticality, region, recent change and assurance status.

For each sample:

1. trace the processing purpose and risk;
2. confirm the exact provider and service;
3. verify certificate and declaration scope;
4. inspect responsibility allocation;
5. test selected customer configurations;
6. compare contract commitments with operating evidence;
7. review incidents and changes; and
8. confirm reassessment and action.

Include at least one service with a recent architecture or region change and one material exception. The readiness checker can help teams identify wider ISMS gaps before assurance review.

Audit questions

Ask:

• Which exact service and legal entity do the assurance claims cover?
• Is the ISO certificate current and is the relevant service in scope?
• Is the CISPE status candidate or independently verified?
• What processing role does each party perform?
• Which security and privacy controls remain with the customer?
• Do contracts reflect material commitments and escalation needs?
• Are data location and transfer assumptions technically enforced?
• Has the customer tested its own configuration?
• How are changes to scope, service or status detected?
• What happens if assurance lapses or a material finding appears?

Pass, partial and fail examples

Pass: The customer matched both assurance signals to the exact service, documented shared responsibility, closed gaps through contract and configuration, and monitored material change.

Partial: Certificates and declarations were current, but responsibility for logging and deletion was ambiguous and regional scope had not been reconciled.

Fail: Approval relied on a provider logo. The service was outside the certificate scope, the CISPE status applied to a different offering and no one had tested customer access configuration.

These examples describe evidence strength, not legal conclusions or mandatory audit grades.

Common weaknesses

Avoid:

• treating ISO 27001 as privacy-law certification;
• assuming a provider certificate covers every product;
• extending a service declaration across the whole portfolio;
• confusing candidate and independently verified CISPE status;
• relying on a historical Code version;
• ignoring the customer’s configuration duties;
• treating data location as the only privacy question;
• accepting marketing claims without public-register evidence;
• failing to monitor assurance expiry or scope change; or
• assuming either signal guarantees legal compliance.

Practical conclusion

ISO 27001 and the CISPE Code are complementary assurance inputs. ISO 27001 provides evidence about a scoped information-security management system. The CISPE Code adds sector-specific evidence for declared IaaS services operating in a processor role.

Use both at the level where they actually apply. Verify scope and status, map shared responsibility, close unanswered requirements through contract and configuration, and monitor change. The strongest cloud decision rests on a traceable evidence set, not a collection of logos.