email-svg
Get in touch
info@canadiancyber.ca

ISO 27017 Contracts

ISO 27017 is about cloud security clarity. This guide explains the shared-responsibility contract addendum SaaS providers should require plus a buyer-friendly table template.

Main Hero Image
Contracts • Shared Responsibility • Cloud Controls • Audit Readiness

ISO 27017 Contracts

The Shared-Responsibility Addendum Your SaaS Should Require

ISO 27017 is about cloud security clarity. And in contracts, clarity means one thing: shared responsibility written down.
If your SaaS relies on cloud services (it does) and serves customers who expect cloud controls (they do), you need a shared-responsibility addendum that defines who does what before an incident or audit forces the conversation.

Problem
Cloud security is assumed, not agreed.
Fix
Shared responsibility written down (provider vs customer).
Outcome
Faster approvals, fewer disputes, cleaner audit evidence.

The real problem: cloud security is assumed, not agreed

Most SaaS contracts still rely on vague language: “we take security seriously,” “we follow best practices,” “we comply with standards.”

Then something happens
  • a customer fails an audit and blames your platform
  • a questionnaire asks “who is responsible for X?”
  • an incident occurs and responsibilities are argued in real time
ISO 27017 exists to stop this ambiguity.

What ISO 27017 adds (in plain English)

ISO/IEC 27017 provides cloud-specific guidance on controls shared between the cloud service provider (CSP), the cloud service customer (CSC), and sometimes a cloud service partner.

For SaaS, you are often:

  • a cloud customer of AWS/Azure/GCP, and
  • a cloud service provider to your customers.
That means you live inside two shared-responsibility models: you ↔ your cloud provider and you ↔ your customers.
Your contract needs to reflect the second one.

Why this matters in audits and sales (ISO 27001, SOC 2, procurement)

A shared-responsibility addendum speeds up customer approvals, audit evidence requests, vendor due diligence, and incident coordination.

Because buyers aren’t only asking “Are you secure?”
They’re asking: “What do you do, and what do we do?”

When you don’t define it, customers assume you do everything. That’s how SaaS gets blamed for customer-side issues like weak passwords, misconfigured SSO, and unmanaged customer admin roles.

The shared-responsibility addendum: what your SaaS should require

A strong ISO 27017-style addendum covers these areas clearly and factually.

1) Scope: what services and environments are covered
  • service name(s)
  • environments (production, sandbox)
  • what you operate vs what customers configure
Plain example:
“This addendum applies to the production instance of [Service Name] and the administrative controls provided to the customer.”
2) Roles: provider vs customer vs shared responsibilities
Make the relationship explicit:
  • provider responsibilities (you control and operate)
  • customer responsibilities (they configure/manage)
  • shared responsibilities (both sides must act)
This is the core of ISO 27017 contract clarity.

3) Access and identity responsibilities (where most incidents start)
Provider responsibilities (typical)
  • support secure authentication features (MFA capability, SSO support)
  • control privileged access for internal admins
  • log administrative actions (where applicable)
  • monitor access and sessions
Customer responsibilities (typical)
  • enforce MFA/SSO for their users where available
  • manage joiner/mover/leaver
  • restrict and review customer admin roles
  • manage integration credentials (API keys)
Add a short “customer must” list
so responsibilities are obvious.

4–10) The remaining addendum sections (what to include)
  1. Data handling and classification: data types, protection, regions, retention, deletion, what customers can upload.
  2. Logging, monitoring, and incident coordination: what’s logged, customer log access (if any), notification timelines, cooperation required.
  3. Vulnerability and change management expectations: program summary, change notices, emergency changes, customer integration testing responsibilities.
  4. Subprocessors and third parties: critical categories, due diligence approach, how customers are informed of material changes.
  5. Customer security requirements: what features exist (SSO/MFA/IP restrictions) and what needs an enterprise plan.
  6. Audit and assurance: SOC 2 under NDA, ISO certificates, pen test summaries, sharing limits.
  7. Offboarding: export options, deletion timelines, confirmation approach, customer responsibilities to export.
Keep it factual.
Avoid marketing language and avoid commitments you cannot evidence.

The “Shared Responsibility” table buyers actually read

If you want the addendum to be useful, include a one-page table. This reduces security questionnaires instantly.

Category SaaS Provider (You) Customer
Identity & Access Secure admin access, platform auth controls, admin logging Manage users, enforce MFA/SSO, admin role reviews
Data Protection Encrypt in transit, access controls, backups (as defined) Upload permitted data only, control sharing and permissions
Monitoring Platform monitoring and detection on the service Monitor account misuse and admin actions on customer side
Incident Response Contain platform incidents, notify per timeline Notify provider of compromised accounts, cooperate
Configuration Secure defaults and configuration options Configure settings (SSO, roles, integrations)
Change Mgmt Controlled releases and emergency changes Test integrations and follow change notices
Vendor Management Due diligence for critical vendors Review provider assurance materials
Offboarding Provide export and deletion process Export data and confirm closure steps

Turn ISO 27017 guidance into a contract buyers approve faster
If your contracts don’t define shared responsibility clearly, you’re losing time in procurement reviews and questionnaires. We can make this practical and defensible.
Canadian Cyber helps SaaS teams with:
  • shared-responsibility contract addendums
  • cloud service governance aligned to ISO 27001/27017
  • evidence packs for customer due diligence
  • SharePoint ISMS workflows to maintain contract security terms over time

Common mistakes SaaS companies make with ISO 27017 addendums

  • making it marketing language instead of responsibilities
  • overpromising customer-specific controls without evidence
  • leaving identity responsibilities vague
  • not defining incident notification and cooperation
  • not defining offboarding and deletion clearly
  • not aligning the addendum with how the platform actually works
The best addendum is not the longest. It’s the clearest.

Download the Shared-Responsibility Addendum Template
Want a ready-to-edit template? Use this to align contract language with ISO 27017 shared responsibility.
Includes:
  • one-page responsibility table
  • customer responsibility language (SSO/MFA/admin roles)
  • incident notification and cooperation clauses
  • subprocessor and vendor assurance section
  • offboarding and deletion section

Follow Canadian Cyber
Practical cybersecurity + compliance guidance for Canadian teams:

 

Related Post

blog thum
2026
Aug

Internal Audit Questions for Cloud Security

What should an internal auditor ask about cloud security? This practical ISO 27001 and ISO 27017 guide covers shared responsibility, cloud access, privileged admin roles, backups, restore testing, logging, monitoring, vendor risk, cloud configuration, incident response, and audit-ready evidence.
blog thum
2026
Aug

Common Cloud Evidence Gaps

Cloud security controls may be working, but can you prove it during an ISO 27001 internal audit? Discover 14 common cloud evidence gaps involving access reviews, privileged admins, MFA exceptions, offboarding, backups, restore testing, logs, vendor access, cloud risks, the Statement of Applicability, and corrective actions.
blog thum
2026
Aug

Audit Cloud Access, Backups, Logs, and Admin Roles

Cloud controls need more than screenshots to pass a strong internal audit. Learn how to audit cloud access, privileged admin roles, MFA, offboarding, backups, restore testing, logs, monitoring, vendor access, and configuration under ISO 27001, with practical questions, evidence examples, red flags, and corrective actions.
blog thum
2026
Aug

AI Use Template for Canadian Organizations

AI tools such as ChatGPT, Microsoft Copilot, Gemini, Claude, and AI meeting assistants are already entering Canadian workplaces. Use this practical AI governance template to audit approved tools, data restrictions, privacy risks, vendor reviews, human oversight, employee training, incidents, and evidence as part of your ISO 27001 internal audit.
blog thum
2026
Aug

MSP Prepared for Certification Through Monthly Internal Audits

See how an MSP replaced last-minute ISO 27001 certification preparation with a monthly internal audit program. This case study covers multi-client access, privileged accounts, offboarding, backup and restore testing, vendor risk, incident response, corrective actions, and SharePoint evidence management.
blog thum
2026
Aug

Internal Audit Questions for Managed Service Providers

MSPs handle sensitive client data across ticketing systems, remote access tools, backup platforms, documentation portals, cloud environments, and vendor systems. This guide explains the internal audit questions MSPs should ask to prove client access is controlled, client data is protected, and evidence is ready for ISO 27001 certification or customer review.
blog thum
2026
Aug

ISO 27001 Internal Audit for MSPs

MSPs face unique ISO 27001 risks because one weak control can affect multiple clients. This guide explains how to audit multi-client access, privileged accounts, technician offboarding, backup and restore evidence, vendor dependencies, subcontractors, incident response, and client data separation.
blog thum
2026
Aug

How a FinTech SaaS Reduced Audit Fatigue

Audit fatigue often comes from collecting the same evidence repeatedly. This FinTech SaaS case study shows how shared evidence libraries, framework mapping, evidence owners, refresh schedules, SharePoint views, and corrective action tracking helped reduce duplicate work across SOC 2, ISO 27001 internal audit, enterprise security reviews, and customer due diligence.
blog thum
2026
Aug

SOC 2 vs ISO 27001 Audit Evidence

SOC 2 and ISO 27001 share a significant amount of audit evidence, but they are not interchangeable. Learn which policies, access reviews, vendor records, incident evidence, change controls, backups, training records, and corrective actions can support both frameworks—and which ISO 27001 and SOC 2 records must remain framework-specific.