Markdown Editor

Cloud Service Controls Template (ISO/IEC 27017:2026)

Cloud customer and provider controls: role determination, shared responsibility matrix, implementation table, extra cloud controls, disclosures, monitoring

SGSI e ISO/IEC 27001CompletaISO/IEC 27001:2022 6.1.3, A.5.19 to A.5.23 (cited only); ISO/IEC 27017:2026; ISO/IEC 27002:2022cloud27017controls

Cómo usar: Use it when cloud services are in the ISMS scope and you must show, control by control, what you do as a cloud customer, what providers do, and what you do as a provider. Fill the role determination and the shared responsibility matrix first. The main pitfall is copying a provider's responsibility diagram or the 2015 edition instead of recording your own split against ISO/IEC 27017:2026.

Vista previa

Cloud Service Controls (ISO/IEC 27017): [Organization name]

Records how [Organization name] applies cloud-specific information security controls as a cloud service customer, a cloud service provider, or both: role determination, a shared responsibility matrix per control area, a customer and provider implementation table, the additional cloud controls, provider disclosures and cloud service monitoring. It supports ISO/IEC 27001:2022 + Amd 1:2024 (6.1.3 and Annex A, in particular A.5.19 to A.5.23) using the guidance of ISO/IEC 27017:2026, the new edition that replaced the 2015 edition, and ISO/IEC 27002:2022. Replace every [bracketed] value and every row marked Example.

Document control

FieldValue
Document IDDOC-ISMS-102
Version[1.0]
Status[Draft / In review / Approved / Superseded]
Owner[@isms-manager]
Approvers/reviewers[@cto], [@head-of-cloud-platform], [@security-lead], [@dpo]
Last updatedYYYY-MM-DD
Classification[Internal; provider disclosures in section 7 may be shared with customers]
Standard and editionISO/IEC 27001:2022 + Amd 1:2024 (6.1.3, A.5.19 to A.5.23); ISO/IEC 27017:2026; ISO/IEC 27002:2022
Next scheduled reviewYYYY-MM-DD (at least every 12 months, and after a new cloud provider, a new cloud product or a major cloud incident)
Cloud role(s)[Cloud service customer / Cloud service provider / Both]
Cloud services covered[List from the cloud service register in DOC-ISMS-044 section 12]
Parent documentsCloud services security policy DOC-ISMS-044; Statement of Applicability DOC-ISMS-011

Approvals

RoleNameDecisionDate
Document owner[@isms-manager][Prepared]YYYY-MM-DD
Top management sponsor[@cto][Approved / Approved with changes]YYYY-MM-DD
Cloud platform lead[@head-of-cloud-platform][Reviewed]YYYY-MM-DD
Privacy[@dpo][Reviewed]YYYY-MM-DD

Revision history

VersionDateAuthorChange
0.1YYYY-MM-DD[@author]First draft
1.0YYYY-MM-DD[@author]Approved for issue
[x.y]YYYY-MM-DD[@author][Change summary]

Contents

1. Purpose, scope and role determination

This document shows how [Organization name] implements information security controls for cloud services within the ISMS scope (DOC-ISMS-002). It applies the cloud services security policy (DOC-ISMS-044) at control level and records the responsibilities split between the organization and each cloud provider or cloud customer.

Two roles are possible. As a cloud service customer, the organization uses services provided by others and remains accountable for its own information, identities and configuration. As a cloud service provider, the organization delivers a service to its own customers and must both protect that service and tell customers enough for them to meet their own obligations. Many organizations hold both roles at once. Suppliers that support either party (for example a managed service provider operating a tenant, or an auditor of the cloud service) are treated as cloud service partners and handled through the supplier process (DOC-ISMS-066, DOC-ISMS-068).

ServiceOur roleCounterpartyService modelRationale
[Production platform][Customer][Public cloud provider][IaaS and PaaS][We run our product on it]
[Product name][Provider][Our business customers][SaaS][We sell it as a hosted service]
[Collaboration suite][Customer][SaaS provider][SaaS][Mail, files and chat for staff]

2. About ISO/IEC 27017:2026

ISO/IEC 27017 is a guidance standard: it gives guidance, not management system requirements. It supplements ISO/IEC 27002 with cloud-specific implementation guidance for both customers and providers, and adds a small number of cloud-specific controls. Facts relied on in this template:

ItemStatus as of 2026-11-01Action
Current editionISO/IEC 27017:2026, second edition, publication date July 2026 in the ISO catalogue (some secondary summaries say August 2026, and European adoption followed in August 2026); it replaces ISO/IEC 27017:2015Cite the 2026 edition in new documents
BasisAligned with the ISO/IEC 27002:2022 control structure (organizational, people, physical and technological themes) according to the ISO abstract and published summariesMap to ISO/IEC 27001:2022 Annex A numbers in section 5
Guidance layoutPublished summaries report guidance written side by side for customers and providersMirror this with the two columns in section 5
Additional controlsAt least two independent published summaries report four cloud-specific controls added to the 93 in ISO/IEC 27002:2022 (see section 6); one reports that only 5.38 and 5.39 are visible in the free ISO previewVerify numbers and wording against the 2026 text, especially 8.35 and 8.36
AnnexesPublished summaries report an annex mapping the 2015 edition to the 2026 edition and an annex on cloud service monitoringUse the mapping when migrating older SoA entries prefixed CLD
CertifiabilityNot a certification standard on its ownSee section 10

Organizations that implemented the 2015 edition should run a short transition: map each old entry (including the extended controls with the CLD prefix) to the 2026 structure using the mapping annex, update the SoA extension table (section 9), and tell customers who receive provider disclosures that the reference has changed. Record the transition in the ISMS change plan (DOC-ISMS-025) if it changes scope, contracts or customer commitments.

3. Cloud services and parties in scope

IDServiceRoleModelRegionsContract or termsProvider responsibility statementRegister ref
CSV-001 (Example)Public cloud IaaS and PaaS, productionCustomerIaaS, PaaSPrimary and DR regionEnterprise agreement and DPAProvider shared responsibility page, version captured YYYY-MM-DDCLD-001
CSV-002 (Example)Collaboration suiteCustomerSaaSTenant regionOnline terms and DPAProvider trust documentationCLD-002
CSV-003 (Example)Analytics platform sold to business customersProviderSaaSSame two regions as CSV-001Master agreement, customer security addendum (DOC-ISMS-117), DPAOur responsibility statement, section 7Product catalogue
[CSV-004][Service][Role][Model][Regions][Contract][Statement][Ref]

Parties and partners relevant to cloud security:

PartyTypeRelevance
[Public cloud provider]Provider to usInfrastructure, physical and hypervisor security
[Managed service partner]Cloud service partnerOperates part of our tenant under contract (DOC-ISMS-068)
[Business customers]Customers of our serviceRely on our disclosures and notifications
[Sub-processors of our service]Suppliers in our chainListed in the supplier register DOC-ISMS-066

4. Shared responsibility matrix by control area

Legend: C customer, P provider, S shared (both parties hold duties, detailed in section 5). The table shows the organization's default view; record differences per service in section 3.

Control area (ISO/IEC 27001:2022 Annex A)IaaSPaaSSaaSNotes
Policies, roles and segregation (A.5.1 to A.5.4)SSSEach party governs its own side; roles agreed in writing (section 6)
Asset inventory and classification (A.5.9 to A.5.13)CCSCustomer classifies its data; SaaS provider inventories platform assets
Information transfer (A.5.14)CSSProvider secures its interfaces; customer decides what is transferred
Identity and access (A.5.15 to A.5.18, A.8.2, A.8.5)CCSCustomer manages users and roles; provider secures its admin access and authentication features
Supplier and cloud management (A.5.19 to A.5.23)CCCEach party manages its own suppliers; provider manages sub-processors
Incident management (A.5.24 to A.5.28)SSSNotification paths both ways; evidence handling agreed
Continuity and ICT readiness (A.5.29, A.5.30, A.8.13, A.8.14)SSSProvider resilience plus customer backup and region choice
Legal, privacy and records (A.5.31 to A.5.34)SSSData location, processor duties, lawful access requests
People controls (A.6.1 to A.6.8)SSSEach party screens, trains and binds its own staff
Physical controls (A.7.1 to A.7.14)PPPCustomer relies on provider assurance; disposal of provider media is provider work
Endpoints and malware (A.8.1, A.8.7)CSSCustomer endpoints always customer; provider protects its hosts
Vulnerability and configuration (A.8.8, A.8.9)CSSGuest OS on IaaS is customer; managed runtime is provider
Deletion, masking and leakage (A.8.10 to A.8.12)SSSCustomer requests and configures; provider deletes and confirms
Logging, monitoring and time (A.8.15 to A.8.17)SSSProvider supplies logs and time source; customer collects and reviews
Network security and segregation (A.8.20 to A.8.22)SSPTenant network rules are customer on IaaS; tenant isolation is provider
Cryptography (A.8.24)SSSKey ownership model recorded per service
Development and change (A.8.25 to A.8.34)CSPProvider change affecting customers needs notice

5. Implementation table

Columns: Customer side is what the organization does when it consumes a cloud service. Provider side is what the organization does when it delivers its own cloud service. Evidence names the record an auditor can sample. Control labels are short descriptions, not the official titles.

5.1 Organizational controls

IDControlCustomer sideProvider sideEvidenceStatus
CLC-001 (Example)A.5.2 security rolesNamed business and technical owner per cloud serviceNamed service owner, security contact published to customersCloud service register, RACI DOC-ISMS-006Implemented
CLC-002 (Example)A.5.9 asset inventoryTenant resources tagged with owner and classification, exported monthlyPlatform asset inventory includes customer-facing components and their locationsTag compliance report, CMDB exportImplemented
CLC-003 (Example)A.5.12 classificationData stores labelled by classification before production useCustomer data treated as Confidential by default, regardless of customer labelsData store list, classification standardImplemented
CLC-004 (Example)A.5.14 information transferApproved transfer methods into and out of the tenantEncrypted APIs and export functions documented for customersArchitecture notes, API documentationImplemented
CLC-005 (Example)A.5.15 to A.5.18 accessSSO with the corporate identity provider, roles by group, quarterly review of admin rolesCustomer admins manage their own users; our staff access to customer tenants only by ticket and time-limited roleAccess review records, privileged access logsImplemented
CLC-006 (Example)A.5.19 to A.5.22 suppliersProvider assessed and contracted under DOC-ISMS-067 and DOC-ISMS-068Sub-processors listed, assessed and flowed down; customers notified before changesSupplier register, sub-processor listImplemented
CLC-007 (Example)A.5.23 cloud service useEvery service registered, owned, reviewed and given an exit route under DOC-ISMS-044Not applicable to the provider side (covered by sections 6 and 7)Cloud service registerImplemented
CLC-008 (Example)A.5.24 to A.5.26 incidentsProvider notifications received in a monitored mailbox and triaged under DOC-ISMS-020Customer notification process with stated time, contact list per customer, status pageIncident register DOC-ISMS-021, notification logImplemented
CLC-009 (Example)A.5.28 evidenceProvider log export and snapshot procedure for investigationsProcedure to preserve and supply evidence for a customer on request, without exposing other tenantsForensic procedure, request logPartially implemented
CLC-010 (Example)A.5.30 ICT readinessRecovery in the DR region tested twice a yearService resilience design and recovery objectives stated in customer documentationDR test report, service descriptionImplemented
CLC-011 (Example)A.5.31 legal requirementsData location rules checked for each regionApplicable law, region list and lawful access request handling disclosedLegal register DOC-ISMS-014, disclosure pageImplemented
CLC-012 (Example)A.5.34 privacy and PIIProcessor terms in place; transfer assessment where neededProcessor duties under customer DPAs; see isms/cloud-pii-27018-processorDPA, records of processingImplemented

5.2 People and physical controls

IDControlCustomer sideProvider sideEvidenceStatus
CLC-013 (Example)A.6.3 awareness and trainingCloud administrators trained on the platform baseline and shared responsibilitySupport and operations staff trained on customer data handling and tenant isolationTraining records DOC-ISMS-026Implemented
CLC-014 (Example)A.6.6 confidentialityNot applicable beyond normal staff agreementsStaff with access to customer environments sign confidentiality terms covering customer dataSigned agreements DOC-ISMS-051Implemented
CLC-015 (Example)A.7.1 to A.7.8 physicalReliance on provider assurance reports, reviewed each yearPhysical security inherited from the IaaS provider; reliance stated to customersAssurance report review notesImplemented
CLC-016 (Example)A.7.14 disposal of equipmentProvider media sanitization covered by its assurance reportSame reliance, disclosed to customers; no own data centre equipmentAssurance report extract referenceImplemented

5.3 Technological controls

IDControlCustomer sideProvider sideEvidenceStatus
CLC-017 (Example)A.8.2 privileged accessAdmin roles held by named people, phishing-resistant MFA, break-glass accounts sealedOperations access to production through a bastion with session recordingRole assignment export, session logsImplemented
CLC-018 (Example)A.8.6 capacityQuotas and cost alerts monitoredCapacity planning per region, customer-facing limits documentedCapacity plan, alert configurationImplemented
CLC-019 (Example)A.8.8 vulnerabilitiesContainer images and guest systems scanned, patched to isms/vulnerability-remediation-tracker timelinesVulnerabilities affecting customers communicated through security advisoriesScan reports, advisory logImplemented
CLC-020 (Example)A.8.9 configurationInfrastructure as code with policy checks against the baselineSecure default settings for new customer tenants, documentedPolicy check results, tenant defaults documentImplemented
CLC-021 (Example)A.8.10 deletionDeletion of retired resources verified; provider deletion confirmation keptCustomer data deleted within a stated period after contract end, confirmation on requestDeletion log, confirmation lettersPartially implemented
CLC-022 (Example)A.8.13 backupBackups copied to the DR region, restore tested quarterlyBackup scope and retention for customer data stated in the service descriptionRestore test log DOC-ISMS-071Implemented
CLC-023 (Example)A.8.15 loggingProvider audit logs exported to the central log store, 365 daysCustomers can export their own audit logs; retention statedLog source inventory, product documentationImplemented
CLC-024 (Example)A.8.16 monitoringPosture findings and alerts reviewed under DOC-ISMS-064Service monitoring for abuse and unauthorized use, see section 8Monitoring tickets, monthly reportImplemented
CLC-025 (Example)A.8.17 clock synchronizationProvider time service used by all workloadsTime source for logs disclosed so customers can correlate eventsConfiguration evidence, disclosure pageImplemented
CLC-026 (Example)A.8.20 to A.8.22 networksPrivate networking, security groups reviewed quarterly, production separated from non-productionTenant isolation at application and data layers, tested in each penetration testFirewall rule review, penetration test reportImplemented
CLC-027 (Example)A.8.24 cryptographyCustomer-managed keys for production data storesEncryption at rest and in transit for all customer data; key ownership model disclosedKey register DOC-ISMS-070Implemented
CLC-028 (Example)A.8.32 change managementPlatform changes through the change processCustomers notified of changes that affect security or their obligations, with notice periodChange records, release notesImplemented

6. Additional cloud-specific controls

Published summaries of ISO/IEC 27017:2026 (at least two independent secondary sources as of 2026-11-01) report four additional cloud-specific controls, numbered after the last ISO/IEC 27002:2022 control in each theme. One summary describes 8.36 as mainly a customer concern. Use the mapping annex of the 2026 edition to see which 2015 extended controls (CLD prefix) each one replaces. Treat the numbering as provisional until checked against the standard.

IDReported number and topic (own label)Customer sideProvider sideEvidenceStatus
CLX-001 (Example)5.38: shared roles in a cloud environmentResponsibility split documented per service (section 4) and assigned to named ownersResponsibility statement published to customers, kept current, version-controlledSection 4 matrix, published statement with version dateImplemented
CLX-002 (Example)5.39: agreed roles with a cloud service partnerManaged service partner duties written into the contract and its security schedulePartners supporting the service (support providers, resellers) bound by written dutiesContracts, DOC-ISMS-068 clause selectionPartially implemented
CLX-003 (Example)8.35: separation of virtual environmentsProduction, staging and development in separate accounts with no shared credentialsTenants separated logically at compute, storage and network layers; separation testedAccount structure diagram, penetration test resultsImplemented
CLX-004 (Example)8.36: detecting and preventing unauthorized cloud service useShadow IT detection and unauthorized resource alerts under DOC-ISMS-044 section 11Abuse detection on the service (account takeover, fraud, resource misuse), with response stepsDetection reports, abuse case logPlanned

If your copy of the standard shows a different set, update this table, section 9 and the SoA extension at the same time.

7. Provider disclosures to customers

As a provider, the organization keeps the following information current and makes it available to customers under the stated channel.

IDDisclosure topicContent we provideChannelOwnerLast reviewed
DIS-001 (Example)Responsibility statementSplit between us and the customer per control area, matching section 4Trust centre pageISMS managerYYYY-MM-DD
DIS-002 (Example)Certifications and reportsCertificate scope, issuing body accreditation, report periodsTrust centre, under NDA for reportsISMS managerYYYY-MM-DD
DIS-003 (Example)Data locationRegions for storage, processing and support accessService descriptionHead of Engineering OperationsYYYY-MM-DD
DIS-004 (Example)Sub-processorsList with purpose and location; change notice periodSub-processor pageDPOYYYY-MM-DD
DIS-005 (Example)Incident notificationNotification commitment, contact route, information includedCustomer security addendum DOC-ISMS-117Security leadYYYY-MM-DD
DIS-006 (Example)Logging available to customersLog types, retention, export methodProduct documentationProduct ownerYYYY-MM-DD
DIS-007 (Example)Backup and recoveryScope, frequency, retention, recovery objectivesService descriptionHead of Engineering OperationsYYYY-MM-DD
DIS-008 (Example)Encryption and keysAlgorithms in use, key ownership optionsSecurity whitepaperSecurity leadYYYY-MM-DD
DIS-009 (Example)Data return and deletionExport formats, deletion period after contract end, confirmationMaster agreement and help centreLegal counselYYYY-MM-DD
DIS-010 (Example)Changes affecting securityNotice period and channel for material changesRelease notes and e-mail noticeProduct ownerYYYY-MM-DD
DIS-011 (Example)Vulnerability informationAdvisory process, coordinated disclosure contactSecurity pageSecurity leadYYYY-MM-DD
DIS-012 (Example)Lawful access requestsHow government requests for customer data are handled and reportedTransparency statementLegal counselYYYY-MM-DD

Incident notification between the provider and its customers follows the sequence below. The same pattern applies in reverse when the organization is the customer of an upstream provider.

8. Cloud service monitoring

IDWhat is monitoredRoleSourceFrequency (Example)Response route
MON-001 (Example)Administrative activity in the tenantCustomerProvider audit log exported to central log storeContinuous, alerting on high-risk actionsDOC-ISMS-064 alert triage
MON-002 (Example)Configuration drift against baselineCustomerPosture management toolDaily scan, weekly reviewTicket to technical owner
MON-003 (Example)Provider service health and security bulletinsCustomerProvider status feedContinuous subscriptionChange or incident record
MON-004 (Example)Unusual usage or cost spikesCustomerBilling and usage alertsDailyCheck for compromised credentials
MON-005 (Example)Customer account takeover indicatorsProviderProduct authentication logsContinuousLock account, notify customer admin
MON-006 (Example)Abuse of the service (scraping, resource misuse)ProviderRate limiting and anomaly detectionContinuousAbuse case procedure
MON-007 (Example)Tenant isolation failuresProviderAutomated isolation tests in the release pipelineEvery releaseBlock release, incident if in production
MON-008 (Example)Sub-processor status and incidentsProviderSupplier notificationsContinuousDOC-ISMS-020, customer notice if affected

9. Statement of Applicability and risk integration

  1. Keep the Annex A rows in the SoA (DOC-ISMS-011) as the master list. For controls with a cloud angle, reference the CLC rows in section 5 in the SoA "where implemented" column.
  2. Add an extension table to the SoA for the additional controls in section 6, with inclusion decision, justification and status, exactly as for Annex A controls.
  3. Link each cloud risk in the risk register (DOC-ISMS-016) to the CLC or CLX rows that treat it. Typical cloud risks: tenant misconfiguration, provider outage in one region, compromised administrator credentials, unclear deletion at exit, unexpected data location change, and concentration on one provider.
  4. When a control is shared (S in section 4), the risk owner checks both halves: the organization's own implementation and the evidence that the other party performs its part (assurance report, contract clause, test).
SoA extension row (Example)IncludedJustificationStatusReference
ISO/IEC 27017:2026 5.38 shared rolesYesCustomer and provider roles both held; contracts require a responsibility splitImplementedCLX-001
ISO/IEC 27017:2026 8.35 separation of virtual environmentsYesMulti-tenant SaaS on shared infrastructureImplementedCLX-003
ISO/IEC 27017:2026 8.36 unauthorized cloud useYesRisk RISK-044 (Example), account takeover and shadow ITPlanned, due YYYY-MM-DDCLX-004

10. Assurance, attestation and certification

  • ISO/IEC 27017 contains guidance and controls, not management system requirements, so it is not certified on its own. Some certification bodies assess the cloud controls as part of an ISO/IEC 27001 audit and state this in the certificate scope, an annex or a separate statement. The certification body decides what it can verify and how it records it; ask before you plan the audit (DOC-ISMS-090).
  • Customer assurance depends on the scope: check that the certificate scope names the cloud service, and that any reference to ISO/IEC 27017 names the 2026 edition once your audit has covered it.
  • As a customer, accept provider statements of alignment only with evidence: certificate scope, assurance report, or contractual commitment, reviewed under DOC-ISMS-067.
  • Cloud-related questionnaires (for example the CSA Cloud Controls Matrix and CAIQ, cited by name only) can be answered from sections 5 to 8. Map them in isms/control-framework-crosswalk.

11. Size tiers

AspectSmall: Quillmere Analytics Ltd (46 staff)Medium: Quillmere Health Systems (320 staff)Large: Quillmere Group (2,400 staff, 6 sites)
Roles heldCustomer of one public cloud provider (two regions, primary and DR); provider of its SaaS analytics platformCustomer of one public cloud plus a colocation suite; provider of a managed clinical scheduling serviceMainly customer of several providers across 4 countries; internal platform team acts as provider to business units
Matrix depthOne matrix for the platform, one for the collaboration suiteMatrix per Tier 1 service, hospital-specific variations recordedMatrix per provider and region, plus an internal matrix for the platform team
Implementation table owner0.5 FTE ISMS manager (Head of Engineering Operations) with two platform engineersISMS manager and the 3-person security teamCISO office (14 people) with regional cloud owners
Provider disclosuresTrust centre page and security whitepaperCustomer-specific disclosures for hospitals, contractual notice periodsInternal service catalogue disclosures to business units, external only for group services
MonitoringProvider-native posture tool and audit log exportPosture tool and SIEM across cloud and colocationCentral posture management and security operations centre across all tenants
Additional controlsAll four adopted, CLX-004 provider side plannedAll four adopted, partner control used for the managed service providerAll four adopted; separation of virtual environments extends to OT data platforms
Typical effort (Example)6 to 8 person-days to build, 1 day per quarter to maintain15 to 20 person-days to build, 2 days per month to maintain40 or more person-days to build, part of a full-time role to maintain

12. Records and evidence

RecordProvesOwnerLocationRetention (Example)
Role determination and service list (sections 1 and 3)Scope and roles are decided per serviceISMS manager[Document repository]Current plus previous version
Shared responsibility matrices with provider statement versionsThe split is known and agreedCloud platform lead[Architecture repository]Life of service plus 3 years
Implementation evidence per CLC and CLX rowControls operate on both sidesControl owners[GRC tool or evidence folders]3 years
Provider assurance report reviewsReliance on providers is justifiedISMS manager[Supplier folder]3 years
Published provider disclosures with version historyCustomers receive current informationISMS manager, product owner[Trust centre source repository]6 years
Monitoring outputs and ticketsMonitoring in section 8 runsSecurity team[SIEM, ticketing tool]1 to 2 years per logging standard
Customer incident notificationsNotification commitments were metSecurity lead[Incident register DOC-ISMS-021]6 years
SoA extension tableAdditional controls are decided and justifiedISMS managerDOC-ISMS-011Life of the ISMS

Link each record to its controls in isms/control-evidence-matrix.

13. References

ReferenceEditionUse
ISO/IEC 27001:2022 + Amd 1:2024, https://www.iso.org/standard/82875.html and https://www.iso.org/standard/88435.htmlCurrentRequirements, 6.1.3 and Annex A
ISO/IEC 27002:2022, https://www.iso.org/standard/75652.htmlCurrentControl structure and guidance
ISO/IEC 27017:2026, https://www.iso.org/standard/82878.htmlSecond edition, July 2026; replaces 2015Cloud-specific guidance and additional controls
ISO/IEC 27018:2025, https://www.iso.org/standard/88150.htmlCurrentPII protection by public cloud processors
ISO/IEC 27036-4:2016, https://www.iso.org/standard/59689.htmlCurrentSecurity of cloud services in supplier relationships
CSA Cloud Controls Matrix v4.1 and CAIQ v4.1Names onlyQuestionnaire mapping
Related templatesisms/cloud-services-security-policy, isms/cloud-pii-27018-processor, isms/cloud-exit-plan, isms/supplier-register, isms/supplier-security-agreement-27036, compliance/supplier-security-assessment, compliance/statement-of-applicability, security/cloud-security-posture-review, isms/secure-configuration-baseline, isms/security-monitoring-procedure, isms/control-framework-crosswalk, isms/control-evidence-matrix

Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (6.1.3 and Annex A controls A.5.19 to A.5.23), ISO/IEC 27002:2022 and ISO/IEC 27017:2026. Control numbers are cited with original short labels; the matrices, tables, examples and guidance are original text, and no text from ISO/IEC standards is reproduced. Details of the 2026 edition of ISO/IEC 27017 (additional control numbers and annexes) are taken from the ISO catalogue entry and published summaries and must be checked against the official text. Obtain the official standards from ISO, IEC or your national standards body to implement them. The CSA Cloud Controls Matrix and CAIQ are cited by name only. Check the current edition of each standard before use.

Template licence: MIT.

Plantillas relacionadas