ISO 27001 Shared Responsibility: 6 Audit Ready Annex A Mappings

Under ISO/IEC 27001, the organization always retains ISMS accountability, even when a cloud provider performs the underlying control. Responsibility can be delegated in practice, but never in writing. If you use cloud services in your ISMS scope, your immediate task is to map every in-scope control to a named owner and list the evidence type you need from that provider, starting today, not at audit time.

TL;DR:

• Responsibility for ISO 27001 controls remains with the organization, even when cloud providers perform underlying security tasks or controls.
• Cloud responsibility categories—provider-owned, customer-owned, or shared—do not reduce your overall accountability for risk management.
• The more cloud services you use at higher levels of the stack, the more control shifts to the provider, requiring detailed mapping and evidence collection for each control.
• Evidence like control documentation, logs, and test reports must be collected from providers and linked to your Statement of Applicability, not assumed from certificates alone.
• Effective responsibility matrices require detailed, version-controlled records that link every control, owner, evidence, and contract clause to withstand audit scrutiny.

Table of Contents

• What Does “ISO 27001 Shared Responsibility” Actually Mean?
• How Does Responsibility Shift Across IaaS, PaaS, and SaaS?
• Mapping Annex A Controls to Providers, Customers, and Shared Owners
• Building a Responsibility Matrix That Survives an Audit
• What Evidence Should You Collect From Cloud Providers?
• Where Are the Highest-Risk Gaps in Cloud Interfaces?
• Can Planning Tools Help Estimate ISO 27001 Effort?
• Auditors Reward Traceability, Not Paperwork Volume
• Get a Faster Start on Your ISO 27001 Cloud Planning
• Where to Verify These Standards Yourself
• Sources
• FAQ

What Does “ISO 27001 Shared Responsibility” Actually Mean?

The phrase itself never appears in the standard. ISO/IEC 27001:2022 doesn’t hand you a universal cloud split telling you which party owns encryption or which owns patching. Instead, it requires something more demanding: you manage the risks to the information you own or handle, full stop, regardless of who operates the servers underneath it. That’s the standard piece most compliance officers already know. The gap shows up in how people apply it to cloud services, where “shared” gets misread as “someone else’s problem, partly.”

Here’s the standard vocabulary you should be using instead of the informal shorthand. ISO 27001 compliance roles break down into three categories for any given control: provider-owned, customer-owned, or shared. None of those categories reduce your accountability for the outcome. You can hand off performance of a control. You cannot hand off ownership of the risk.

ISO/IEC 27017 exists precisely to close that gap. It’s the cloud-specific companion to ISO/IEC 27002’s control catalog, written for both cloud service providers and cloud service customers, and it gives you the vocabulary to translate a generic Annex A control (say, “access rights shall be reviewed”) into a concrete cloud responsibility (“the provider manages the console; you review and revoke tenant-level access quarterly”). If you’re running vendor risk ISO 27001 work today without referencing ISO/IEC 27017, you’re doing it with one hand tied behind your back.

The point that trips up newer compliance teams: a provider’s SOC 2 report or ISO 27001 certificate does not transfer your accountability. It tells you the provider runs a functioning ISMS for their own scope. It says nothing about whether their control configuration matches what your risk treatment plan requires, or whether you’ve verified it operates the way their marketing page claims. AWS’s own compliance guidance makes this explicit: customers still have to define their own ISMS scope, implement their own customer-side controls, and demonstrate conformity independently during their certification audit.

Three things every compliance officer should internalize about ISO 27001 risk management in a cloud context:

• A certificate proves the provider’s control environment exists. It doesn’t prove it fits your scope.
• Every externally performed control still needs a line in your Statement of Applicability, with evidence attached.
• “Shared” is a spectrum, not a binary. Most controls split into sub-tasks, and each sub-task needs its own owner.

That last point is where most responsibility matrices fall apart before they’re even built.

How Does Responsibility Shift Across IaaS, PaaS, and SaaS?

Responsibility boundaries move dramatically depending on which layer of the stack you’re buying. AWS’s shared responsibility framework is the most widely cited public model for this, and while it’s built around one provider’s terminology, the underlying pattern holds across the industry: the more of the stack you buy pre-built, the more control shifts upward to the provider, and the more your job shrinks to configuration, governance, and verification.

1. Infrastructure as a Service (IaaS)

You’re renting compute, storage, and networking. The provider secures the physical data center, the hypervisor, and the underlying network fabric. You own almost everything above that line:

• Guest operating system patching and hardening
• Application-level security and code
• Security group and firewall rule configuration
• Identity and access management for anything you provision
• Encryption choices, including whether you manage your own keys or use the provider’s default

Evidence to collect: the provider’s data center certifications and physical security attestations, plus your own patch management logs, IAM configuration exports, and encryption key policy documentation. None of this comes from the provider. It comes from your own change management system.

2. Platform as a Service (PaaS)

The provider now manages the runtime, the operating system, and often the middleware. Patching the underlying platform is no longer your job. What stays with you is everything about how you use the platform: application logic, data governance, and access provisioning for the people who touch that data.

Evidence to collect: the platform’s service-specific security documentation (not the parent company’s blanket certificate, the actual page describing that specific PaaS offering), plus your own records of who has deployment access and how application secrets are stored.

3. Software as a Service (SaaS)

The provider operates essentially the entire stack. Your responsibilities narrow to data classification, user provisioning, tenant configuration settings, and deciding what data goes into the tool in the first place. This is also where organizations get sloppiest, because it feels like there’s nothing left to own. There’s plenty left to own. If your ISO 27001 for SaaS scope includes a tool where you never reviewed the tenant’s security settings, that’s a gap an auditor will find in minutes.

Evidence to collect: subprocessor lists, tenant configuration exports, user access review logs, and the SaaS provider’s own documentation of what security settings are configurable versus fixed.

Pro Tip: Don’t summarize a provider’s responsibility as a single phrase like “provider handles encryption.” Break it into who supplies the mechanism, who configures it, who owns the keys, who reviews the evidence, and who restores service if it fails. Five sub-questions, five potential different owners.

Mapping Annex A Controls to Providers, Customers, and Shared Owners

The mechanical part of this work is more repeatable than most people expect. For every control in your applicable Annex A (or ISO/IEC 27002:2022 control set) that touches a cloud service, run it through the same conversion: what’s the actual activity behind this control language, who performs that activity, and what would prove it happened. The Annex A control set reads as abstract policy language until you force it through this filter.

Here are six mappings compliance teams run into constantly, with the owner, the evidence type, and how an auditor typically verifies each one.

Access control (A.5.15, A.8.2, A.8.3). In a SaaS or PaaS context, the provider builds and maintains the authentication mechanism. You own who gets access and when it’s revoked. Owner: shared, leaning customer. Evidence: user access review logs, offboarding tickets, single sign-on configuration screenshots. Verification: auditors sample terminated employees and check revocation timestamps against HR records.

Patch management (A.8.8). In IaaS, this is entirely yours for the guest OS and applications. In PaaS and SaaS, it shifts to the provider for the underlying platform. Owner: depends entirely on service model, so state it per-service in your matrix rather than as a blanket statement. Evidence: your patch cadence policy and change logs, or the provider’s published patching SLA. Verification: auditors check patch timestamps against known vulnerability disclosure dates.

Encryption and key management (A.8.24). The provider almost always supplies the mechanism. Key ownership is the real question. If you use provider-managed keys, the provider is a much bigger part of this control than if you bring your own keys. Owner: shared, and the exact split needs to be written down, not assumed. Evidence: your key management policy, key rotation records, and the provider’s encryption-at-rest documentation for that specific service. Verification: auditors ask who can access the key material and under what conditions.

Backup and restoration (A.8.13). Providers frequently back up infrastructure automatically. Almost none of them test your recovery process for you. Owner: shared, with restoration testing almost always landing on the customer. Evidence: backup configuration settings plus your own restore test reports, dated and repeated on a schedule. Verification: auditors ask for the last successful restore test, not just the backup schedule.

Logging and retention (A.8.15). The provider generates logs; you decide what gets retained, for how long, and who reviews them. Owner: shared. Evidence: log retention policy, sample log exports, and a documented review cadence. Verification: auditors check whether anyone actually looked at the logs, not just whether logs exist.

Supplier relationships (A.5.19, A.5.20, A.5.23). This is the control that governs the whole exercise. It requires you to identify security requirements for cloud services, agree on them contractually, and monitor supplier performance against them. Owner: customer, always, even though the underlying services are provider-run. Evidence: your supplier management program, contract clauses referencing security obligations, and periodic supplier review records. Verification: auditors want to see that you reviewed the provider’s own security posture at onboarding and at intervals afterward, not just once at signing.

Notice the pattern: almost nothing is a clean 100% split. Owner: shared is the honest answer for most controls once you dig past the surface. The exception, worth naming explicitly, is A.5.19 through A.5.23. That family is customer-owned by design, because no provider can manage your supplier oversight obligation for you.

Building a Responsibility Matrix That Survives an Audit

A spreadsheet with two columns labeled “us” and “them” will not survive contact with an experienced auditor. What holds up is a matrix built with enough granularity to trace every claim back to a document, and enough version control to show it’s a living artifact rather than something assembled the week before certification.

Work through it in this order:

1. Define scope. Confirm which cloud services actually fall inside your ISMS boundary. A tool that touches no in-scope data doesn’t need a row.
2. Catalog services and controls. List every in-scope cloud service against every Annex A or ISO/IEC 27002 control that could plausibly apply to it.
3. Assign owners. For each control-service pair, mark provider, customer, or shared, using the granular sub-task method described above rather than a single label.
4. Record evidence and verification method. Every row needs a stated evidence type and how you’d verify it, not just that it exists somewhere.
5. Reconcile against contracts and the SoA. Cross-check that what your matrix claims matches what your Statement of Applicability states and what your provider contract actually obligates them to do.
6. Version and review on a schedule. Cloud services change configuration constantly. A matrix that’s a year stale is a liability, not an asset.

ISO committee guidance on control ownership is direct on this point: an external organization performing a control does not remove the control from your SoA. It still needs a row, an owner, and evidence, even when your organization never touches the mechanism directly.

Multi-cloud and managed service provider (MSP) relationships add a layer most matrices ignore. If your organization is both a cloud customer and a SaaS provider to your own customers, you need two linked matrices: one for what you receive upstream from your providers, and one for what you commit downstream to your own customers. Connect them at the evidence points where an upstream provider’s control becomes the evidence backing your own downstream assurance. Treating these as one flat document instead of two cross-referenced ones is a common source of audit confusion, especially when a downstream customer asks a question your upstream provider was supposed to answer.

What Evidence Should You Collect From Cloud Providers?

A certificate is a starting point, not a finish line. Auditors increasingly expect service-specific documentation, not a parent-company logo on a compliance page. The distinction matters because a cloud provider’s ISO 27001 certificate might cover their data center operations while saying nothing about how a specific managed database service configures encryption by default.

Materials worth requesting from any material cloud provider:

• The provider’s own audit reports (SOC 2 Type II, ISO certificates, and any bridge letters covering gaps between audit periods)
• Service-specific control descriptions, not just organization-wide marketing pages
• A current subprocessor list, including hosting locations
• Incident notification terms, specifically the timeline they commit to for informing you
• Logging and telemetry access terms, meaning whether you can actually pull the logs relevant to your risk assessment
• Data deletion and portability terms for when you leave or need to purge data

Evaluating suitability means mapping each provider control back to the specific SoA entry it’s meant to satisfy, then asking whether you can independently verify it operates as claimed. Where you can pull logs or telemetry yourself, do that instead of relying solely on the provider’s word. Where you can’t, note that limitation explicitly rather than pretending the gap doesn’t exist. That’s a real and common accountability point: even when a provider performs a control well, keep a record showing you assessed its suitability and verified operation where you could, rather than accepting the control on faith because the provider is well known.

Contract negotiation is where a lot of this either gets locked in or quietly disappears. Push for explicit evidence access rights, a defined incident notification SLA (not “promptly,” but a number of hours), and monitoring rights that let you audit or request audit results on a schedule. A vendor security questionnaire template gives you a structured way to extract this information consistently across multiple providers instead of improvising each time.

Where Are the Highest-Risk Gaps in Cloud Interfaces?

NIST’s cloud computing guidance makes a point worth repeating to every audit committee: the riskiest areas in any cloud arrangement sit at the interfaces, the seams where provider responsibility ends and customer responsibility begins. Five interfaces account for most of the findings compliance teams run into:

• Identity lifecycle. Signs of a gap: stale accounts for departed employees, shared service accounts nobody owns. Minimal evidence to close it: quarterly access review records tied to HR offboarding tickets.
• Key ownership. Signs of a gap: no documented policy on who can request key access. Minimal evidence: a written key custody policy plus rotation logs.
• Backup and restoration. Signs of a gap: backups exist but nobody has tested a restore in over a year. Minimal evidence: dated restore test reports, not just backup job success screenshots.
• Logging and retention. Signs of a gap: logs are generated but retention periods conflict with your own policy, or nobody reviews them. Minimal evidence: a review cadence with sign-off records.
• Incident response. Signs of a gap: your plan and the provider’s plan were never tested together. Minimal evidence: a joint interface test covering detection, notification timelines, and evidence preservation.

Pro Tip: Don’t treat “we have an incident response plan” and “the provider has an incident response plan” as sufficient on their own. Run an actual interface test: who detects first, how fast they notify you, what forensic access you get, and how evidence gets preserved across both sides.

Short-term mitigation for any of these gaps usually means scheduling the missing review or test this quarter. The long-term fix is building the cadence into your matrix’s review column so it never lapses again.

Can Planning Tools Help Estimate ISO 27001 Effort?

Mapping every control across every cloud service takes real hours, and most compliance teams underestimate that time until they’re mid-project. A benchmarking tool can give you a starting estimate: tailored cost and effort projections based on company size, industry, and your current security maturity, plus a maturity assessment spanning multiple ISO domains and a customizable Gantt timeline for sequencing the work.

Used well, that estimate helps you size the responsibility-mapping effort specifically, rather than guessing at how many weeks the matrix and evidence collection will actually take. A free readiness check can offer an initial view of where your maturity sits before committing budget to a fuller assessment. What it won’t do is negotiate your provider contracts or pull your access logs for you. Treat the benchmark as the planning layer that sits above the manual matrix and supplier documentation work, not a replacement for either.

Auditors Reward Traceability, Not Paperwork Volume

The mistake I see most often isn’t a missing control. It’s a matrix built to look complete rather than to hold up under questioning. An auditor doesn’t care how many rows you have. They care whether you can trace a claim from the SoA to a contract clause to an actual log file in under two minutes.

Version your responsibility matrix like you’d version code. Cross-link it to contracts and to your change management log, so when a provider updates a service configuration, that change shows up somewhere in your evidence trail instead of silently invalidating a row you wrote eighteen months ago. And treat provider cooperation itself as something you measure: how fast they answer a security questionnaire, whether they grant telemetry access without a fight, how quickly they’ve historically met notification SLAs after an incident. Those are controls too, even though they don’t have an Annex A number attached to them.

The organizations that struggle at certification aren’t usually missing evidence entirely. They have evidence scattered across email threads, old contract PDFs, and someone’s memory of a call with the provider three months ago. Traceability is the entire game.

— Martin

Get a Faster Start on Your ISO 27001 Cloud Planning

Ismscalculator is the alternative to guessing at project scope before you’ve even opened a responsibility matrix. Instead of starting your ISO 27001 implementation with a blank spreadsheet and a rough sense of how long supplier evidence collection might take, you get a real-time, organization-specific estimate built from your company size, industry, and current security maturity, with the assumptions fully visible and editable rather than buried in a black box.

Run the free 2-minute readiness check to see where your maturity stands before you commit to a full mapping effort, or go straight to the ISO 27001 cost calculator for an instant estimate you can compare against model reference comparisons. Save multiple scenarios if you’re weighing different cloud architectures against each other, and use the resulting Gantt timeline to sequence your responsibility matrix work alongside the rest of your certification project. No signup required to get your first number.

Where to Verify These Standards Yourself

Every claim in this guide traces back to a primary source you can check directly. Start with ISO/IEC 27001:2022 for the core ISMS requirements, and ISO/IEC 27017 for cloud-specific control guidance. For a practical illustration of how responsibility splits across service models, AWS’s shared responsibility documentation remains the most widely referenced public example. NIST’s cloud computing guidance covers the practitioner side of interface risk, and ISO committee guidance addresses how control ownership should be evidenced within your SoA.

Sources

• ISO/IEC 27001:2022 - Information security management systems
• New compliance guide available: ISO/IEC 27001:2022 on AWS Compliance Guide
• ISO committee guidance on control ownership and evidence

FAQ

Who Is Responsible for ISO 27001 Compliance?

The certified organization is always responsible for its own ISO 27001 compliance, even when cloud providers perform specific controls. A provider can operate infrastructure or software on your behalf, but your organization must still define ISMS scope, document the responsibility split in your SoA, and produce evidence during your own certification audit, per ISO/IEC 27001:2022.

What Is an Example of Shared Responsibility in ISO 27001?

Encryption and key management is a common example. A cloud provider typically supplies the encryption mechanism, but the customer often decides whether to use provider-managed keys or bring their own, and that choice determines who reviews and rotates key access. AWS’s shared responsibility model illustrates this same split pattern across other controls like patching and network configuration.

What Is the Shared Security Responsibility Model?

It’s a framework, popularized by major cloud providers, that divides security duties between the provider and the customer based on which layer of the stack each party controls. Under AWS’s version, the provider secures the infrastructure while the customer secures what they configure and put on top of it. ISO 27001 doesn’t mandate a specific version of this model, but it requires you to document your own split and evidence it.

Does a Provider’s ISO 27001 Certificate Cover My Organization?

No. A provider’s certificate confirms their own ISMS meets the standard for their scope, but it does not extend to your organization’s certification. As AWS’s compliance guidance states, you still need to define your own scope and demonstrate your own conformity, including for controls the provider performs on your behalf.

How Do I Start Mapping ISO 27001 Responsibilities for Cloud Services?

Begin by cataloging every cloud service inside your ISMS scope, then work through applicable Annex A controls one by one, assigning an owner, evidence type, and verification method for each. A tool like Ismscalculator’s ISO 27001 cost calculator can help size how much effort that mapping will take before you begin, based on your organization’s size and current maturity level.

Recommended

• ISO 27001 Annex A Controls Explained
• ISO 27001 Risk Matrix: 5×5 Template for Audit-Ready InfoSec
• ISO 27001 Internal Audit: The Certification-Ready Playbook
• ISO 27001 Statement of Applicability: A Complete Guide