Addressing security within supplier agreements

To meet ISO/IEC 27017:2015 Clause 15.1.2, you must ensure every supplier that can access, process, store, or transmit your cloud service data (or provide cloud infrastructure components) has explicit, written security requirements in the agreement. Operationally, this means standard contract security clauses, risk-tiered addenda, and a repeatable review-and-approval workflow with documented evidence. ¹

Key takeaways:

• Put security requirements in the contract or an incorporated addendum for every relevant third party.
• Scale requirements by third-party risk (data sensitivity, access, criticality), but document the rationale.
• Retain artifacts that prove requirements were defined, negotiated, approved, and are monitored over time.

“Addressing security within supplier agreements” is a contract control with operational teeth: it forces you to move security expectations from informal questionnaires and sales promises into enforceable terms. ISO/IEC 27017:2015 Clause 15.1.2 targets suppliers that can touch your cloud service in real ways, including third parties that access cloud customer data, run supporting systems, host infrastructure, process logs, or provide components that affect confidentiality, integrity, or availability. ¹

For a CCO, GRC lead, or compliance officer, the fastest path to operationalizing this requirement is to standardize what “security requirements” means in your environment, embed those requirements into contract templates, and enforce a routing process that blocks signature until the right clauses are agreed (or formally excepted). This page gives requirement-level implementation guidance: who is in scope, what contract terms to include, how to run a practical review workflow, what evidence auditors ask for, and how to avoid common failure modes like “security language in a questionnaire but not in the agreement.”

Regulatory text

ISO/IEC 27017:2015 Clause 15.1.2 states: “All relevant information security requirements shall be established and agreed with each supplier that may access, process, store, communicate, or provide IT infrastructure components for cloud services.” ¹

Operator translation:
You must (1) identify the suppliers that can affect your cloud service security, (2) define the specific security requirements that apply to each supplier relationship, and (3) make those requirements contractually binding (in the master agreement, a security addendum, a data processing addendum, an order form, or incorporated policies), with documented agreement by both parties. ¹

Plain-English interpretation (what the requirement really demands)

This clause is about closing the “expectations gap” between what your security program needs and what your third parties are contractually obligated to do. A supplier questionnaire or a slide deck is not “agreed requirements.” Auditors typically look for enforceable contract terms that cover, at minimum:

• Data handling obligations (how data is accessed, used, stored, and disposed of)
• Access controls (who can access what; least privilege; authentication expectations)
• Incident reporting (notification duties and timelines as defined in your agreement)
• Audit rights / assurance (your right to evaluate compliance through evidence, reports, or audits)

These examples align to the clause’s intent that agreements “explicitly address information security requirements.” ¹

Who it applies to (entity + operational context)

Entities in scope:

• Cloud Service Providers (CSPs): You rely on multiple suppliers to deliver your cloud service. You must bind them to requirements consistent with your security posture and customer commitments. ¹
• Cloud Service Customers: You consume cloud services and often add suppliers (MSPs, integrators, support vendors) that access or process cloud data. You must bind those suppliers to requirements that protect your environment and meet your obligations upstream. ¹

Supplier relationships typically in scope (examples):

• Managed service providers, SOC providers, IT admins with privileged access
• SaaS tools connected to production or containing customer data
• Cloud hosting/IaaS component suppliers, data center providers, CDN/DNS providers
• Customer support outsourcers handling tickets with sensitive data
• Contractors with access to repositories, production, telemetry, or backups

Out of scope (usually):

• Suppliers with no access to your data and no ability to impact service security (for example, office supplies). Even then, document your scoping logic.

What you actually need to do (step-by-step)

Step 1: Build your “supplier security requirements” baseline

Create a Security Requirements for Third Parties clause library with modular components you can mix based on risk. Minimum modules to draft and approve internally:

1. Scope and definitions: what data, systems, and services the supplier touches.
2. Security controls obligations: baseline technical and organizational measures the supplier must maintain (written at a level procurement can negotiate and security can test).
3. Data handling: permitted use, confidentiality, segregation, retention, deletion/return.
4. Subcontractor controls: flow-down obligations and approval/notice requirements.
5. Incident management: notification requirements and cooperation duties.
6. Assurance and audit rights: evidence you can request (reports, attestations, logs, audit support).
7. Access governance: least privilege, joiner/mover/leaver expectations, MFA where applicable.
8. Breach remediation and liability hooks: practical remedies, termination for cause, cure periods as your counsel allows.

Keep the language consistent with what you can verify. If you can’t reasonably audit “continuous” compliance, require periodic evidence or attestations you can review.

Step 2: Classify third parties so you can scale requirements

Operationalize “all relevant requirements” with a risk-tiering method. You want predictable outcomes:

• Tier drivers: data sensitivity, volume, privileged access, connectivity to production, ability to affect availability, regulatory exposure, and substitutability.
• Result: which contract modules apply by tier.

Document the mapping in a simple matrix (example structure):

Risk factor	Low	Medium	High
Data access	None or public	Internal	Sensitive/customer data
Privileged access	No	Limited	Admin/production
Contract addendum	Baseline	Baseline + incident/audit	Full security + audit + subcontractor flow-down

Auditors care less about your exact tiers and more about consistency and documented rationale.

Step 3: Embed requirements into contracting workflows (so it’s not optional)

Put controls into the way work gets done:

• Contract templates: standard MSA + Security Addendum + optional DPA (if applicable to your business).
• Procurement intake: require the requester to answer a short set of scoping questions (systems, data types, access level, hosting).
• Gating: prevent signature until security review is complete or an exception is approved by an authorized risk owner.
• Fallback language: pre-approved alternative clauses for common negotiation points (audit rights, incident notification, subcontractor approvals).

This is where many programs fail: they have good clause language, but no mechanism that forces it into every relevant agreement.

Step 4: Negotiate and document exceptions (without losing control)

Some suppliers will resist specific clauses (especially audit rights and incident terms). Your job is to make exceptions controlled:

• Require a written exception request stating which clause is changed and why.
• Record compensating controls (for example, independent assurance reports instead of on-site audit).
• Get approval from a documented authority (risk owner, security, legal, procurement).
• Track exceptions to expiry and re-review at renewal.

Step 5: Monitor compliance post-signature

Clause 15.1.2 is not “sign and forget.” Build a lightweight but provable monitoring loop:

• Track critical suppliers and renewal dates.
• Collect agreed assurance evidence on a schedule that matches risk tier (for example, security documentation, attestations, or other evidence the contract allows).
• Confirm subcontractor disclosures where required.
• Test operational clauses during incidents (notification paths, contacts, cooperation).

If you use a system like Daydream to centralize third-party records, clause sets, approvals, and evidence requests, you reduce the risk of missing renewals or losing proof during an audit. Keep it boring and searchable.

Required evidence and artifacts to retain

Auditors typically ask for objective proof that requirements were established and agreed. Maintain:

• Signed agreements (MSA, Security Addendum, DPA, order forms) and version history
• Clause library and approved contract templates (with owner and approval record)
• Third-party inventory with tiering/risk classification and scoping fields
• Contract review tickets showing security and legal review, approvals, and dates
• Exception register with rationale, approvals, compensating controls, and expirations
• Assurance evidence collected under audit rights (reports, attestations, questionnaires if referenced by contract)
• Incident communications log for any supplier security incident (notification timestamps, actions, closure)

Retention matters: store artifacts in a system that is access-controlled and searchable by supplier name and contract effective date.

Common exam/audit questions and hangups

Expect variants of these:

1. “Show me the contract language that covers security for Supplier X.”
   Hangup: security obligations exist only in a questionnaire, not in the agreement.

2. “How do you decide which suppliers need which security terms?”
   Hangup: no documented tiering method; decisions vary by negotiator.

3. “Where are your audit rights, and have you exercised them?”
   Hangup: contract says “upon request,” but nobody can show requests or evidence intake.

4. “How do you ensure subcontractors are controlled?”
   Hangup: no flow-down terms; no tracking of subcontractors.

5. “What happens if the supplier has an incident?”
   Hangup: notification clauses exist, but your internal incident runbook does not include supplier contacts and escalation.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating “supplier agreements” as only MSAs.
  Fix: include SOWs, order forms, click-through terms, and incorporated addenda in your control design. If the supplier is onboarded via a portal, capture the acceptance record.

• Mistake: Vague security clauses you can’t verify.
  Fix: require evidence-backed commitments (named artifacts you can request) and tie obligations to measurable practices where possible.

• Mistake: Exceptions handled in email threads.
  Fix: implement a formal exception workflow with an owner, rationale, and expiry.

• Mistake: Forgetting upstream/downstream alignment.
  Fix: if you have customer commitments (incident notice, audit support), ensure your supplier terms allow you to meet those commitments.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement actions.

Practically, weak supplier security terms increase the chance that you cannot:

• compel timely incident notice or cooperation,
• validate controls through audits or evidence,
• enforce subcontractor flow-down obligations,
• meet customer commitments if a supplier is involved.

Treat this as both a security risk and a contractual performance risk.

Practical execution plan (30/60/90-day)

Use a phased plan with clear deliverables and governance checkpoints.

First 30 days (foundation)

• Identify in-scope supplier categories: who can access/process/store/communicate data or provide cloud infrastructure components. ¹
• Publish a baseline Security Addendum (legal-approved) plus a fallback clause set for negotiations.
• Implement an intake form and a “no security review, no signature” gate for new suppliers.

By 60 days (operational control)

• Roll out a tiering matrix and integrate it with procurement intake so the correct addendum is selected automatically.
• Stand up an exception register and approval workflow with defined risk owners.
• Train procurement, legal, and security reviewers on clause intent and negotiation boundaries.

By 90 days (coverage and monitoring)

• Triage existing suppliers: prioritize high-risk suppliers for contract updates at renewal or via amendment.
• Start assurance collection per contract rights for highest-risk suppliers and record outcomes.
• Centralize contract + evidence storage and link artifacts to each supplier record (Daydream or your existing GRC/CLM stack).

Frequently Asked Questions

Do security requirements have to be in the master agreement, or can they be in an addendum?

They can be in the master agreement or a separate security addendum, as long as the requirements are clearly incorporated and agreed by both parties. The audit focus is “established and agreed,” not where the text lives. ¹

What counts as a “supplier” under this clause?

Any third party that may access, process, store, or communicate information for your cloud services, or provide IT infrastructure components that support those services. If a third party can affect your cloud security posture, treat them as in scope. ¹

If a supplier refuses audit rights, can we still comply?

Potentially, if you document an approved exception and replace direct audit rights with other contractually enforceable assurance mechanisms you can rely on. Keep the decision record and ensure the alternative still supports your risk and customer obligations. ¹

Are supplier questionnaires enough to meet the requirement?

Not by themselves. A questionnaire can inform your risk decision, but the clause requires security requirements to be “agreed” with the supplier, which typically means contract terms or incorporated addenda. ¹

How do we handle click-through SaaS terms that we can’t negotiate?

Document the supplier’s scope and risk, then decide whether compensating controls or alternative suppliers are needed if the terms do not cover your minimum security requirements. Where possible, attach your security addendum through an enterprise plan or procurement channel and record the outcome.

What evidence do auditors usually want first?

They usually start with the third-party inventory, a sample of signed agreements showing security clauses, and proof of a consistent review/approval workflow. Keep your exception register and assurance evidence ready for the same sample set.

Footnotes

1. ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services