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)
- Data handling and classification: data types, protection, regions, retention, deletion, what customers can upload.
- Logging, monitoring, and incident coordination: what’s logged, customer log access (if any), notification timelines, cooperation required.
- Vulnerability and change management expectations: program summary, change notices, emergency changes, customer integration testing responsibilities.
- Subprocessors and third parties: critical categories, due diligence approach, how customers are informed of material changes.
- Customer security requirements: what features exist (SSO/MFA/IP restrictions) and what needs an enterprise plan.
- Audit and assurance: SOC 2 under NDA, ISO certificates, pen test summaries, sharing limits.
- 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:
