Security Clauses for Supplier Agreements: An ISO 27001 Approach

A supplier agreement should turn a security decision into an obligation that people can operate and verify. Generic promises to follow “industry best practice” rarely define who must act, by when, for which service, or what evidence will be available.

ISO/IEC 27001 expects organisations to manage information-security risks in supplier relationships and address security within relevant agreements. It does not prescribe identical wording for every supplier. Clause selection should follow the service, information, access, dependency and risk.

ISO/IEC 27036-2:2022 adds requirements for defining, implementing, operating, monitoring, reviewing, maintaining and improving supplier-relationship processes. The contract is one control point within that lifecycle, not the whole system.

Begin with the relationship

Before drafting clauses, document what the supplier will actually do:

• service and deliverables;
• information received, generated or accessed;
• systems, facilities and interfaces involved;
• provider personnel and privileged access;
• approved locations;
• downstream providers;
• availability and recovery dependencies;
• customer responsibilities; and
• exit conditions.

This prevents a familiar failure: a legal schedule that sounds strong but applies to the wrong data, entity or service. Align product names, legal parties and scope across the agreement, risk record, architecture and supplier register.

The supplier security lifecycle guide explains how selection, onboarding, monitoring, change and termination fit around the contract.

Translate risk into a contractual outcome

For each material risk, write a short chain:

Scenario → required outcome → party → timing → evidence → remedy.

Suppose a payroll provider experiences an incident. “Supplier will maintain appropriate security” does not answer the customer’s operational need. The contract should define which events require notice, the notification channel and clock, the information supplied, update frequency, cooperation, evidence preservation and escalation if facts change.

Not every detail belongs in the main agreement. Stable obligations may sit in the agreement, technical requirements in a security schedule, service levels in an operational schedule, and contact details in a controlled register. Documents should have a clear precedence rule and change process.

Legal counsel should draft or approve enforceable wording for the governing law, relationship and jurisdiction. The ISMS team supplies the security outcome, risk rationale and operating measures.

Core clause families

Scope, information and permitted use

Define the covered service, information categories, environments and permitted processing. State restrictions on use, disclosure, combination and retention. Ambiguity here weakens every later obligation.

Evidence may include the signed schedule, data-flow record, service description and approved processing instructions.

Security responsibilities

Allocate customer, supplier and shared duties. Cover identity, configuration, logging, encryption, vulnerability handling, backup, recovery and physical controls where relevant. Avoid a catch-all requirement to follow the customer’s entire policy library when only selected requirements apply.

For cloud and managed services, record the handoffs. If the supplier generates logs but the customer must enable export, both actions belong in the responsibility model.

Personnel and access

Address authorisation, confidentiality, competence, screening where lawful and justified, privileged access, segregation, review and removal. Define how emergency access is controlled and recorded.

The agreement need not prescribe a specific technology unless that is a genuine requirement. It should state the outcome and any non-negotiable conditions.

Incident coordination

Define the events that trigger notification, time measurement, recipients, minimum initial facts, updates, investigation support, evidence preservation and post-incident reporting. Align this with the customer’s legal and contractual deadlines; do not simply copy a statutory deadline that applies to a different party.

The incident-management evidence guide helps connect contractual notification to internal assessment and response records.

Vulnerability and change management

Specify expectations for vulnerability intake, risk-based remediation, urgent mitigation and disclosure of material exposure. Require notice of changes that could affect agreed security: architecture, location, ownership, subprocessors, control design or support model.

Set times only where they are measurable and risk-appropriate. A universal remediation period can be weaker than severity-based targets with an exception process.

Resilience and recovery

State service levels, recovery objectives where needed, backup responsibilities, testing, communication during disruption and evidence access. Confirm that commitments cover the dependency the customer actually relies on.

Subcontracting

Define approval or notice rights, information required, flow-down of applicable obligations, supplier accountability and consequences of unacceptable change. “Supplier remains responsible” is useful but does not tell the customer how it will learn about a critical downstream change.

Assurance and audit information

Specify what evidence the supplier will provide, how often, under what confidentiality conditions and after which events. Options may include independent reports, certificates, test summaries, control attestations, meetings and targeted audit rights.

Audit rights should be usable. Define notice, scope, cost, frequency, coordination, access constraints and alternatives where direct inspection would create risk for other customers.

Data return, deletion and exit

Define export format, assistance, timing, deletion method, backup treatment, confirmation, access revocation and transition support. Test whether the exit approach is realistic before dependency becomes critical.

Tailor by supplier tier

Clauses should be proportionate. A facilities provider with no sensitive access does not need the same schedule as a cloud platform processing regulated records. Tier suppliers using criteria such as:

• information sensitivity and volume;
• privileged or remote access;
• business criticality;
• concentration and substitutability;
• legal and regulatory exposure;
• location and downstream dependency; and
• recovery impact.

Use the risk score calculator to structure likelihood and impact discussions, then apply the organisation’s approved method and risk criteria. A numerical score should support judgement, not replace it.

Prove that clauses operate

A signed agreement is implementation evidence. Auditors also need evidence that recurring obligations work.

Build a clause-to-operation map with:

Contract outcome	Owner	Operating record
Annual assurance delivery	Supplier manager	Current report, review decision and actions
Incident notification	Security operations	Notification case, timeline and escalation
Access removal	Service owner	Termination ticket and account evidence
Recovery testing	Continuity owner	Test result, exception and retest
Subsupplier change	Procurement	Notice, impact review and approval
Exit deletion	Data owner	Return record and deletion confirmation

Evidence should show the relevant period. If a contract requires quarterly service reviews, one recent meeting record does not prove four reviews occurred.

Audit sampling

Start with the population of active suppliers. Select by risk tier, information access, criticality, geography, new onboarding, material change, incident history and approaching renewal.

For each sample:

1. trace the supplier risk to selected clauses;
2. confirm the correct entity and service are covered;
3. inspect approval and legal review;
4. map obligations to internal owners;
5. test recurring records across the period;
6. review exceptions and supplier changes;
7. verify issues were followed to closure; and
8. inspect exit readiness where dependency is material.

Include a supplier that received an exception or failed an obligation. Such samples reveal whether the organisation can govern reality, not only normal operation.

The second-party supplier audit guide gives more detail on planning direct assurance when documents alone are insufficient.

Pass, partial and fail examples

Pass: High-risk services have tailored agreements linked to documented risk. Obligations have owners, evidence is reviewed on schedule, changes trigger reassessment and breaches produce tracked action.

Partial: Strong clauses exist, but several responsibilities have no internal owner. Annual assurance was collected yet not evaluated, and a new subprovider was noted without impact review.

Fail: Procurement accepted standard online terms without security review for a critical service. The organisation cannot establish incident timing, data location, evidence rights or exit conditions.

These examples illustrate assurance strength rather than mandatory audit classifications.

Common weaknesses

Avoid:

• giving every supplier the same requirements;
• relying on undefined security language;
• copying controls without linking them to risk;
• imposing deadlines the organisation cannot monitor;
• securing audit rights that are operationally unusable;
• omitting customer responsibilities;
• ignoring downstream providers;
• filing assurance evidence without review;
• allowing product or location changes outside governance; and
• waiting until termination to design exit.

The Annex A control lookup can help teams identify related control themes while preserving a risk-based decision.

Practical conclusion

Good supplier clauses are not a long list of demands. They are a precise allocation of security outcomes across a real service relationship. Start with scope and risk, make responsibilities measurable, decide what proof will be available, and connect every recurring obligation to an internal owner.

The strongest audit result is not merely a signed agreement. It is a traceable line from risk, through enforceable commitment, to evidence that both parties performed as intended.