Annex A 5.20: Addressing Information Security Within Supplier Agreements

Annex a 5.20: addressing information security within supplier agreements requirement means you must build information security obligations into your third-party contracts and ensure those obligations match the risk and the services provided. Operationalize it by standardizing security contract clauses, routing third-party engagements through security/legal review, and retaining evidence that requirements were set, agreed, and monitored ¹.

Key takeaways:

• Put explicit, risk-based security requirements into supplier agreements before access/data sharing starts ¹
• Standardize clauses and decisioning so procurement does not bypass security review ¹
• Keep recurring evidence that contracts include required controls and that exceptions are approved and tracked ¹

Annex A 5.20 sits at the seam between your ISMS and your procurement process. Most security failures with third parties are operational failures first: a service goes live, access is granted, data starts flowing, and only then does someone ask what the contract requires the supplier to do. This control exists to prevent that pattern by forcing clarity and enforceability up front.

For a Compliance Officer, CCO, or GRC lead, the fastest path to implementation is to treat 5.20 as a contract-integration control with three outputs: (1) a baseline security addendum (or clause library) that covers the minimum you require from any third party, (2) a risk-based mechanism to add stronger obligations for higher-risk engagements, and (3) an evidence trail that shows each applicable agreement contains the right language, or has an approved exception.

This page gives requirement-level steps you can hand to procurement, legal, IT/security, and business owners. It focuses on what auditors look for: proof that supplier security requirements are defined, included in agreements, and managed as part of ongoing third-party governance ¹.

Regulatory text

Provided excerpt: “ISO/IEC 27001:2022 Annex A control 5.20 implementation expectation (Addressing Information Security Within Supplier Agreements).” ¹

Operator interpretation (what you must do):

• Define information security requirements for third parties.
• Embed those requirements in supplier agreements (contracts, MSAs, SOWs, DPAs, order forms, platform terms where applicable).
• Make the requirements appropriate to the service risk, the data involved, and the access granted.
• Maintain evidence that the requirement is consistently implemented, not just drafted as a template ¹.

Plain-English interpretation of the requirement

If a third party will process your data, access your systems, host your workloads, or deliver a service that can affect confidentiality, integrity, or availability, your contract must say what security controls they have to maintain and what they must do when things go wrong. “Addressing information security within supplier agreements” is less about writing perfect legal prose and more about making security expectations enforceable and repeatable across all relevant third-party relationships ¹.

Who it applies to

Entity scope

• Organizations operating an ISO/IEC 27001 ISMS (including service organizations) that rely on third parties to support business processes, IT, or security operations ².

Operational scope (where this shows up)

Applies whenever a third party:

• Handles organizational information (including customer data, employee data, or business confidential data).
• Has logical access (accounts, APIs, SSO, admin consoles).
• Has physical access (offices, data centers, device handling).
• Provides a service that can materially affect uptime, recovery, or security monitoring.
• Subcontracts any part of the service that touches your information or systems.

If procurement can buy it, and it can touch data/systems, it belongs in your 5.20 process.

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

Step 1: Define the minimum security contract baseline (your “must-have” clauses)

Create a baseline set of supplier security obligations that procurement/legal can drop into agreements with minimal friction. Keep it short enough to be used, but complete enough to be defensible.

Baseline clause topics to cover (practical list):

• Scope of services and data handling boundaries (what data, where processed, who can access).
• Access control expectations (least privilege, MFA for privileged access where applicable).
• Security incident notification and cooperation (define notification trigger and communication path).
• Vulnerability and patch expectations (at least “maintain a vulnerability management program”).
• Logging/monitoring obligations relevant to the service.
• Encryption expectations appropriate to the service.
• Subprocessor/ subcontractor controls (flow-down obligations; approval/notice model).
• Right to assess (questionnaire, evidence request, audit report review) and remediation commitments.
• Termination and data return/deletion obligations.

Your baseline should map to your ISMS requirements and your data classification model, if you have one ¹.

Step 2: Add risk-based “tiering” so higher risk means stronger terms

Annex A 5.20 expects appropriateness. Build a simple decision matrix that determines which add-on terms are required.

Example tiering logic (qualitative, adjust to your program):

• Low risk: no sensitive data, no system access, commodity service.
• Medium risk: business confidential data or limited access to internal tools.
• High risk: regulated/sensitive data, production access, critical availability dependency, or security operation dependency.

Common high-risk add-ons:

• Tighter incident notification commitments and defined escalation contacts.
• Security testing evidence expectations (independent assessments, pen test summaries where relevant).
• Stronger access constraints (named admin accounts, session logging, approval gates).
• Resilience obligations (backup, recovery, and service continuity expectations aligned to your needs).

Document the tier rules and who approves exceptions ¹.

Step 3: Put the control into the intake workflow (so contracts cannot bypass it)

Operationalize 5.20 by embedding it into purchasing and onboarding.

Minimum workflow requirements:

1. Third-party intake: business owner submits purpose, data types, access level, and criticality.
2. Risk classification: assign tier and required contract package (baseline + add-ons).
3. Contracting: legal/procurement inserts the required clauses or security addendum.
4. Security review checkpoint: security/GRC confirms the correct package was used or approves deviations.
5. Pre-go-live gate: no access credentials, integrations, or data transfers until the agreement is executed or an emergency exception is approved.

This is where most programs fail: they have good templates but no gating control that stops “click-through” or last-minute purchases ¹.

Step 4: Manage deviations with a formal exception process

Suppliers will push back. You need a consistent way to say “yes,” “no,” or “yes with compensating controls.”

Your exception record should capture:

• Clause(s) requested to change or remove.
• Business justification and service dependency.
• Security impact and compensating controls.
• Risk acceptance owner (named role) and approval date.
• Expiration/review trigger (for renegotiation at renewal or earlier).

Step 5: Monitor that contract commitments remain true over time

Annex A 5.20 is not satisfied if the contract is signed and forgotten. Build light recurring checks tied to risk.

Examples of ongoing activities:

• Re-assess high-risk third parties on a defined cadence aligned to your third-party risk process.
• Review contract renewals and SOW changes for scope creep (new data types, new access).
• Validate incident notification contacts remain current.
• Track remediation commitments if assessments identify gaps.

Where Daydream fits naturally: Daydream can help you map Annex A 5.20 to a documented control operation with recurring evidence capture, so you can show auditors not only the template, but the proof of consistent use across your supplier population ¹.

Required evidence and artifacts to retain

Auditors want to see both design and operation. Keep a tight evidence set:

Design evidence (what “good” looks like)

• Supplier security addendum or clause library (current approved version).
• Risk-tiering criteria and contract requirement matrix.
• Procurement/third-party intake workflow documentation showing security/legal checkpoints.
• Exception process and approval authority definition.

Operating evidence (proof it runs)

• Executed agreements (or excerpts) showing the security clauses were included for sampled suppliers.
• Completed third-party intake records with assigned risk tier.
• Security review approvals or ticket/record of clause package selection.
• Exception approvals for any deviations, with compensating controls.
• Renewal/SOW change reviews showing re-application of required terms.

Common exam/audit questions and hangups

Auditors and ISO assessors tend to press on consistency and scope. Expect questions like:

• “Show me how you ensure every relevant third party gets security terms, not just ‘big’ vendors.”
• “How do you decide which security requirements apply to which suppliers?”
• “What happens when procurement signs a contract on a business deadline?”
• “Show examples of exceptions and who accepted the risk.”
• “How do you ensure subcontractors are covered?”

Hangup to preempt: If your process relies on people “remembering” to involve security, you will struggle to demonstrate effective operation ¹.

Frequent implementation mistakes and how to avoid them

1. Templates exist but are optional.
   Fix: make the clause package part of the intake gate and contracting checklist.

2. One-size-fits-all language.
   Fix: add tiered add-ons for higher-risk services so “appropriateness” is clear.

3. No control over order forms and click-through terms.
   Fix: require review for any third party that will receive data/access, even if purchased by credit card. Route to an approved purchasing channel.

4. Exceptions are informal.
   Fix: require a tracked exception record with named risk acceptance and a review trigger.

5. Evidence is scattered.
   Fix: centralize contracts, intake records, and approvals in a system of record; Daydream-style recurring evidence capture reduces audit scramble ¹.

Enforcement context and risk implications

ISO 27001 is a certifiable standard, not a regulator. The practical “enforcement” mechanism is assessment findings: gaps in third-party contracting controls commonly surface as nonconformities, especially when a high-risk supplier lacks incident reporting, access constraints, or flow-down requirements. The business risk is direct: without enforceable contract terms, you may have weaker audit rights, slower incident response coordination, and limited remedies when a third party fails to meet security expectations ².

A practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Inventory third parties with data/system access and identify which lack executed security terms.
• Publish a baseline security addendum/clause set approved by security + legal.
• Add a procurement checklist item: “Security addendum required?” tied to an intake form.
• Stand up an exception log with required fields and approvals.

By 60 days (Make it hard to bypass)

• Implement risk tiering and a contract requirement matrix.
• Add a contracting gate: security review required for medium/high-risk third parties.
• Train procurement and business owners on the intake and “no-go-live without contract” rule.
• Start evidence capture for a sample of newly executed agreements.

By 90 days (Operationalize and prove it)

• Run a retrospective sample check: confirm recent third-party contracts include required clauses or have approved exceptions.
• Add renewal/SOW change triggers so scope changes re-run tiering and clause selection.
• Formalize ongoing monitoring expectations by risk (what you review and what evidence you retain).
• Centralize artifacts (contracts, approvals, exceptions) so audits become a retrieval exercise, not a hunt.

Frequently Asked Questions

Do we need a separate security addendum for every supplier?

No. You need enforceable security requirements in the agreement, which can be a standalone addendum, embedded clauses, or incorporated terms. Standardize the approach so you can prove consistent use across third parties ¹.

What counts as a “supplier agreement” for Annex A 5.20?

Any binding terms that govern the third party’s service and your data/access exposure count, including MSAs, SOWs, DPAs, and order forms. If the third party touches data/systems, treat the governing document as in scope ¹.

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

Route those purchases through an exception path with compensating controls (access restrictions, data minimization, monitoring, alternative vendors). Keep the exception record and the risk acceptance decision as your evidence trail ¹.

Who should own the control: Legal, Procurement, or Security?

Security/GRC should own the requirement and the risk tiering logic; legal should own contract language quality; procurement should own process adherence. Write that division into your workflow so auditors can see accountability ¹.

What evidence is most persuasive to an ISO auditor?

A small set of executed contracts showing the required clauses, plus the intake/tiering record and approval trail that demonstrates the clause package was chosen intentionally. Exceptions with named risk acceptance also matter because they prove controlled deviation ¹.

How do we prove “ongoing” compliance after contract signature?

Tie renewals, SOW changes, and periodic third-party reviews to a requirement to re-check contract terms and update contacts and subprocessors as needed. Keep records of those checks and outcomes ¹.

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview