ISO 27001 A.5.20: Addressing Information Security Within Supplier Agreements

Quick Reference (60 Seconds)

ISO 27001:2022 Annex A 5.20 requires that relevant information security requirements be established and agreed with each supplier, based on the type of supplier relationship, turning your security expectations into binding, documented contract terms.

The Bottom Line: A.5.19 sets up how you manage suppliers; A.5.20 is where that management becomes enforceable, the specific security obligations written into the contract. Without binding clauses, you have expectations; with them, you have rights: to require controls, to be notified of breaches, to audit, and to get your data back.

What the Control Asks For

The ISO 27001:2022 Text

In short:

ISO 27001:2022 Annex A 5.20 asks organizations to establish and agree the relevant information security requirements with each supplier, based on the type of supplier relationship.

Do you need this control?

A.5.20 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. Include it wherever suppliers access, process or host your information. The usual adaptation is a standard set of contract clauses by supplier tier, rather than negotiating every contract from scratch.

The key phrase is "based on the type of supplier relationship", clauses are proportionate, not one-size-fits-all. A cloud provider hosting your customer data warrants very different terms from a stationery vendor.

What ISO 27002:2022 Adds

ISO/IEC 27002 lists 26 terms, (a) to (z), to consider for each agreement (paraphrased):

• (a) the information provided or accessed, and how; (b) its classification; (c) mapping between your and the supplier's classification schemes
• (d) legal, regulatory and contractual requirements (data protection, PII, intellectual property, copyright) and how they will be met
• (e) each party's obligation to implement an agreed set of controls (access control, performance review, monitoring, reporting, auditing)
• (f) acceptable-use rules for your information and assets
• (g) how supplier personnel are authorised and de-authorised to use your information, for example an explicit list of authorised people
• (h) minimum security requirements for the supplier's ICT infrastructure, by information type and access type
• (i) indemnities and remediation if the supplier fails to meet requirements
• (j) incident management: notification and collaboration during remediation
• (k) training and awareness for specific procedures (incident response, authorisation)
• (l) sub-contracting: same obligations flowed down, a list of sub-suppliers, notice before changes
• (m) relevant contacts, including a named contact for information security
• (n) screening of supplier personnel where legally permissible, and what happens if screening is incomplete or raises concerns
• (o) third-party attestations and independent reports on control effectiveness
• (p) the right to audit the supplier's processes and controls
• (q) periodic reports on control effectiveness, and timely correction of issues found
• (r) defect and conflict resolution
• (s) backups that meet your needs (frequency, type, storage location)
• (t) an alternate facility not exposed to the same threats, and fallback controls
• (u) change management with advance notice and the option for you to reject changes
• (v) physical security matching the information's classification
• (w) protection of information in physical transfer and transmission
• (x) termination: records management, return of assets, secure disposal, continuing confidentiality
• (y) a method for securely destroying your information once it is no longer needed
• (z) handover support to another supplier or back to you at the end of the contract

27002 also recommends a register of agreements with external parties and regular review that they are still needed and fit for purpose.

The "shall vs should" Analysis

What Auditors Actually Check

1. Security clauses in actual contracts: sampled, not just a policy that says you'll include them.
2. Proportionality: critical suppliers carry stronger terms than low-risk ones.
3. Data Protection Agreement (DPA) for suppliers processing personal data.
4. Incident notification, audit rights, and data-return/deletion clauses present.
5. Sub-contracting controls: requirements flow down to sub-processors.

Why Supplier Agreements Matter

The Business Risk Narrative

Your security is only as strong as the suppliers you hand data and access to, and once a contract is signed, your use collapses. The agreement is the one moment you can compel a supplier to notify you of breaches, maintain controls, allow audits, and return your data. Skip it, and when the supplier is breached (and some will be), you have no contractual right to information, remediation, or recourse, only the headline that your customers' data was exposed through your vendor.

Supply-Chain Risk Statistics

Indian Regulatory Context

• DPDP Act 2023: Where a supplier processes personal data on your behalf (a Data Processor), you (the Data Fiduciary) must engage them under a valid contract (Section 8(2)). The agreement must bind the processor to protect personal data and act only on your instructions, making A.5.20 a direct DPDP compliance mechanism, with penalty exposure of up to ₹250 crore for safeguard failures.
• RBI Master Direction on Outsourcing of Information Technology Services (2023): For IT suppliers, regulated entities must include clauses on security, confidentiality, data storage and access, audit and inspection rights for the entity and RBI, sub-contracting, business continuity, incident reporting and exit, and remain responsible for outsourced activity. (Non-IT financial-services outsourcing falls under RBI's separate outsourcing guidelines.)
• SEBI Outsourcing Guidelines: Mandate security, confidentiality, and the regulator's right of access in agreements with service providers.
• IRDAI Outsourcing Regulations: Require security and audit clauses for insurer outsourcing.
• CERT-In Directions (2022): Vendor agreements should support the 6-hour incident-reporting chain.
• MeitY/empanelled cloud: Government bodies using empanelled cloud services require specific security terms, including data location in India under the empanelment conditions.

Industry-Specific Consequences

impact of Non-Compliance

When a vendor breach hits, the cost lands on you: regulatory penalties, customer notification, and reputational damage, often for a control gap that a one-page security addendum would have closed. Strong agreements are cheap insurance against catastrophic, externally-caused incidents.

Scope and Applicability

What the Control Covers

• All supplier agreements where the supplier accesses, processes, stores, or transmits the organisation's information or provides components/services that affect security.
• The security and data-protection terms within those agreements, proportionate to the relationship type and risk.

Who It Applies To

Every organisation that uses suppliers, which is every organisation. The depth scales: an SME may rely on a standard addendum; an enterprise negotiates bespoke security schedules and SLAs.

Size-Based Applicability

Key Definitions and Terminology

Relationship to Other Controls

The Supplier-Control Family (5.19–5.23)

ISO 27002 organises supplier security into a coherent family: 5.19 establishes the process for managing supplier risk; 5.20 puts the requirements into agreements; 5.21 addresses the deeper ICT supply chain (components, sub-suppliers, provenance); 5.22 monitors, reviews and manages change in supplier services over the relationship's life; and 5.23 handles the special case of cloud. A.5.20 is the hinge, it converts the intent of 5.19 into the enforceable terms that 5.22 then monitors against.

Security Clauses to Include in Supplier Agreements

The heart of the control. Build a clause library and select from it by supplier tier:

Tiering Suppliers and Right-Sizing Clauses

"Based on the type of supplier relationship" means proportionality. Classify suppliers, then apply a clause set:

Tiering is what keeps the control practical: you negotiate hard where it matters and use a light standard addendum elsewhere, instead of trying (and failing) to impose enterprise terms on every vendor.

Detailed Implementation Guidance

Build a Clause Library and Standard Addendum

Create an approved security & data-protection addendum (with Legal) plus a library of optional clauses for critical suppliers. Attach the addendum to your contract template so security terms are the default, not an afterthought.

Integrate Into Procurement

Embed A.5.20 into the procurement and onboarding workflow: no contract for a data-touching supplier is signed without the security addendum and (for processors) a DPA. Vendor risk assessment (under A.5.19) feeds the tier, which selects the clause set.

Negotiate the Critical Few

For Tier 1 suppliers, negotiate: defined incident-notification windows, audit rights (or acceptance of independent certification), sub-processor approval, data residency (important under sector rules such as RBI and SEBI, and for government data), SLAs with security metrics, and exit/data-return terms.

Accept Evidence in Lieu of Audit

You rarely audit every supplier directly. Accept SOC 2 Type II, ISO 27001 certificates, or completed security questionnaires as evidence, but make the right to request them, and to audit if needed, contractual.

Govern Sub-Processors and Flow-Down

Require suppliers to (i) disclose sub-processors, (ii) obtain approval for new ones, and (iii) flow your security terms down to them, the bridge to A.5.21 (ICT supply chain).

Plan the Exit at the Start

The hardest terms to get after signing are exit terms. At contract time, agree return or secure deletion of data, transition assistance, and data portability, so the end of the relationship doesn't become a data-stranding or data-leakage event.

Keep Agreements Current

Agreements are reviewed on renewal and on significant change (new data types, new sub-processors, regulatory change), connecting to A.5.22 (monitoring and change management of supplier services).

Data Protection and the DPDP Act in Agreements

Under the DPDP Act 2023, if a supplier processes personal data on your behalf, you must have a valid contract (Section 8(2)) binding them as a Data Processor. Practical DPA terms:

• Process personal data only on your documented instructions and for the agreed purpose.
• Implement reasonable security safeguards (mirror your Section 8(5) obligations downstream).
• Notify you of a personal-data breach promptly so you can meet your own notification duties.
• Assist you with data-principal rights requests (access, correction, erasure).
• Sub-processor disclosure and approval; flow-down of obligations.
• Return or delete personal data on termination.
• Support data residency / cross-border requirements as applicable.

The same DPA structure can be extended to meet GDPR Article 28 for organisations serving EU data subjects, provided it includes the specific terms Art. 28(3) requires, so one well-drafted DPA can cover both regimes. This makes A.5.20 a key plank of DPDP and GDPR readiness, not just ISO 27001.

Supplier Agreement Clause Library (Template)

Illustrative extract (full version in the toolkit; have Legal adapt):

Information Security & Data Protection Addendum (extract)

1. Definitions: "Customer Data", "Personal Data", "Security Incident", "Sub-processor".

2. Security Controls. Supplier shall implement and maintain administrative, technical and
   physical safeguards no less protective than ISO/IEC 27001:2022 Annex A controls
   appropriate to the services, including access control, encryption of Customer Data in
   transit and at rest, logging, and vulnerability management.

3. Personnel. Supplier shall screen personnel with access to Customer Data and ensure they
   receive security awareness training and are bound by confidentiality obligations.

4. Incident Notification. Supplier shall notify Customer of any Security Incident affecting
   Customer Data without undue delay and no later than [6/12/24] hours after becoming aware
   (choose a window that lets Customer meet its CERT-In 6-hour and regulator deadlines),
   and shall cooperate in investigation and remediation.

5. Sub-processors. Supplier shall not engage a Sub-processor without Customer's prior written
   approval, shall maintain a list of Sub-processors, and shall impose data-protection and
   security obligations no less protective than this Addendum (flow-down).

6. Audit & Evidence. Supplier shall, on request, provide its current SOC 2 Type II report or
   ISO/IEC 27001 certificate, and permit Customer (or its representative) to audit compliance
   no more than [once annually] on reasonable notice (or following a Security Incident).

7. Data Protection (DPDP/GDPR). Supplier processes Personal Data only on Customer's documented
   instructions, assists with data-principal/data-subject requests, and complies with the
   Digital Personal Data Protection Act, 2023 and (where applicable) GDPR Article 28.

8. Return/Deletion. On termination, Supplier shall return or securely delete all Customer Data
   and certify deletion within [30] days.

9. Business Continuity. Supplier shall maintain business continuity and disaster recovery
   capabilities meeting [RTO/RPO] for the services.

Risk Assessment and Treatment

Audit and Compliance Checklist

(The toolkit 04-audit-evidence-checklist.md lists the evidence to prepare.)

Metrics and KPIs

Common Pitfalls and Audit Failures

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1, Indian NBFC (Mumbai, 1,200 staff): RBI-Compliant Outsourcing Agreements

Challenge. An RBI inspection found the NBFC's outsourcing contracts, including a loan-origination SaaS and a collections agency handling borrower PII, lacked the RBI-mandated security, audit-rights, confidentiality and RBI-inspection clauses, and there was no DPA for the borrower-data processors. Both an RBI Outsourcing Guidelines breach and an ISO 27001 nonconformity.

Solution (9 weeks).

1. Built a clause library and a security + data-protection addendum with Legal, including RBI-required terms (right to audit, RBI's right of access, confidentiality, BC, sub-contracting controls).
2. Tiered the supplier base; applied the full clause set to critical processors and a standard addendum elsewhere.
3. Executed DPAs with all borrower-data processors aligned to DPDP Section 8(2).
4. Embedded the addendum in the contract template and gated procurement so no new data-touching contract proceeds without it.

Results. 100% of critical outsourcing contracts brought up to RBI standard; DPAs in place for all processors; the RBI observation and the ISO nonconformity were both closed, and the procurement gate prevents recurrence.

Illustrative Scenario 2, Indian SaaS Company (Pune, 600 staff): Sub-Processor Flow-Down for Enterprise Deals

Challenge. A B2B SaaS vendor kept losing enterprise deals at the security-review stage because its own supplier agreements (with cloud, email, analytics and support sub-processors) had no incident-notification windows and no flow-down of customer security requirements, so it couldn't credibly promise enterprise customers that their data was protected down the chain.

Solution (6 weeks).

1. Inventoried all sub-processors handling customer data; tiered them.
2. Renegotiated/added incident-notification windows short enough to meet the 6-hour CERT-In deadline and flow-down clauses requiring sub-processors to meet customer-grade terms.
3. Collected and filed SOC 2/ISO evidence for each critical sub-processor; published a sub-processor list with approval workflow.
4. Built a customer-facing DPA mirroring the upstream terms.

Results. The vendor could now contractually guarantee notification and protection down the chain; enterprise security reviews started passing, and two stalled deals closed. The sub-processor governance pack became a standard part of its sales security collateral.

Advanced Implementation Guidance

Figure · Tiers

Maturity levels for addressing information security within supplier agreements

Tier Playbooks (what "proportionate" looks like in practice)

ISO 27002's phrase "based on the type of supplier relationship" is operationalised through tier-specific playbooks. The tiering should be driven by three factors, data sensitivity (does the supplier touch personal/regulated data?), access (to your systems/networks?), and criticality (would their failure disrupt your operations?).

Tier 1, Critical (full clause set + active governance). Cloud/hosting providers, processors of customer PII, payment processors, core managed-IT services. Playbook: full security schedule; a signed DPA; defined incident-notification window (24–72h); right to audit or acceptance of current SOC 2 Type II / ISO 27001; sub-processor disclosure + approval + flow-down; data residency commitments where sector rules or contracts require them; SLAs with security metrics; business-continuity/RTO commitments; documented exit/transition with data return/deletion; named relationship owner; and at least annual review (link A.5.22). Evidence (certifications, pen-test summaries, SOC 2) is collected and diarised for renewal.

Tier 2, Important (standard addendum + evidence). SaaS tools with limited data, marketing platforms, non-core managed services. Playbook: the standard security + data-protection addendum; a DPA if any personal data is processed; incident notification; right to request SOC 2/ISO evidence; confidentiality; return/deletion on exit. Audit rights are typically "request evidence" rather than "on-site audit."

Tier 3, Low risk (baseline). Suppliers with no access to your information or systems (facilities, stationery, catering). Playbook: confidentiality clause and baseline terms; no DPA needed; minimal ongoing governance.

A worked example of tier assignment:

The Critical-Supplier Negotiation Checklist

For Tier 1, the moment of use is before signing. Negotiate, in priority order: (1) incident notification window: the single most important clause for meeting your own DPDP/CERT-In duties; (2) audit/evidence rights: acceptance of SOC 2/ISO plus the right to audit after an incident; (3) sub-processor control: disclosure, approval and flow-down; (4) data residency: where sector rules or contracts require it; (5) exit/return-deletion: the hardest term to add later; (6) liability: appropriate allocation for a data breach. If a supplier refuses notification or evidence rights entirely, that is itself a risk signal worth escalating.

The DPA in Depth (DPDP + GDPR dual compliance)

Where a supplier is a Data Processor, the DPA is the controlling instrument. A strong DPA addresses: processing only on documented instructions; the nature, purpose and duration of processing and the categories of data/data principals; security safeguards mirroring your Section 8(5) obligations; sub-processor terms; assistance with data-principal/data-subject rights and with breach notification; breach notification to you within a defined window; return or deletion at end of processing; and audit/evidence rights. A single, well-drafted DPA aligned to both DPDP Act 2023 Section 8(2) and GDPR Article 28 lets one document serve Indian and EU obligations, valuable for Indian SaaS firms with global customers. Have Legal confirm the dual-compliance language; the two regimes overlap heavily but are not identical (e.g. data-principal vs data-subject rights, cross-border transfer mechanisms).

Cross-Border Transfers and Data Residency

If a supplier stores or processes your data outside India, address it contractually: specify permitted locations, require notification before changing them, and reflect any sectoral data-localisation rules (RBI payment-data localisation, MeitY/government requirements, sector-specific mandates). For EU data, address the GDPR transfer mechanism. Residency is a clause that is cheap to include up front and expensive to retrofit.

Sub-Processor and Nth-Party Governance

The chain rarely stops at your direct supplier. Require Tier 1/2 suppliers to (1) disclose their sub-processors, (2) obtain approval (or give you a right to object) for new ones, and (3) flow down your security and data-protection terms. Maintain visibility of the nth-party chain for your most critical data flows, this is the bridge from A.5.20 (the agreement) to A.5.21 (the deeper ICT supply chain). A supplier that cannot tell you who its sub-processors are cannot credibly protect your data.

Designing the Exit at the Start

Exit terms are impossible to negotiate once the relationship sours, so agree them at contract time: return or secure deletion of your data with a deletion certificate; transition assistance and reasonable cooperation; data portability in a usable format; and continuity of service during the handover. A missing exit clause is how the end of a supplier relationship becomes a data-stranding or data-leakage incident.

Supplier-Agreement Maturity Model (L1–L5)

Target L3 for certification; regulated entities (BFSI under RBI outsourcing rules) are typically expected at L4.

Anatomy of a Supplier-Agreement Failure

A SaaS analytics vendor processing your customers' personal data is breached. Because your agreement (1) had no incident-notification window, you learn of it weeks later from a news report; (2) had no DPA, you cannot demonstrate to the Data Protection Board that the processor was bound to protect the data; (3) had no audit/evidence rights, you cannot compel information about the breach; and (4) had no sub-processor disclosure, you discover the data was actually held by an unknown fourth party. The breach was the supplier's; the regulatory and reputational liability is yours, and every gap was a clause that a one-page addendum would have closed. A.5.20 is the control that converts that scenario from "crisis" into "we invoked our contractual rights and managed it."

Key Takeaways

• A.5.20 makes your security expectations enforceable: it turns intent (A.5.19) into binding contract terms.
• Proportionality is the rule: tier suppliers by data/access/criticality and apply a matching clause set.
• A processing contract is required for any personal-data processor (DPDP s.8(2)); add the Art. 28(3) terms if GDPR also applies.
• Incident notification, audit/evidence rights, sub-processor flow-down, and exit/return terms are the high-value clauses auditors and regulators look for.
• Embed the security addendum in your contract template and gate procurement: so security terms are the default, not an afterthought.
• In India, a good A.5.20 clause library covers most of the RBI/SEBI/IRDAI outsourcing clauses and DPDP processor-contract duties, but sector-specific clauses such as the regulator's right of inspection must be added explicitly.

Multi-Framework Mapping

Implementation Roadmap

Phase 1, Foundation (Weeks 1–3)

• With Legal, draft the standard security + data-protection addendum and clause library.
• Define supplier tiering criteria (criticality, data sensitivity, access).

Phase 2, Integrate (Weeks 4–6)

• Embed the addendum into the contract template; gate procurement on its inclusion.
• Execute DPAs for all personal-data processors.

Phase 3, Remediate Existing (Weeks 7–9)

• Tier the existing supplier base; remediate critical-supplier contracts at renewal or by amendment.
• Collect SOC 2/ISO evidence for critical suppliers; establish sub-processor governance.

Phase 4, Assure (Weeks 10+)

• Build the supplier-clause register and KPI dashboard.
• Connect to A.5.22 for ongoing monitoring and change management; internal audit dry-run.

FAQ

Q1: Is A.5.20 mandatory for certification? Not automatically: Annex A controls are selected through risk treatment (clause 6.1.3) and recorded in your Statement of Applicability. Where you use suppliers (essentially always), you will normally include it, and auditors then sample actual contracts for security terms. A policy alone is not enough.

Q2: How is A.5.20 different from A.5.19 and A.5.21? 5.19 is the overall supplier-risk process; 5.20 is the contractual terms; 5.21 is the deeper ICT supply chain (components, sub-suppliers, SBOM). 5.20 is where 5.19's intent becomes enforceable.

Q3: Do we need clauses in every supplier contract? Proportionate to risk. A supplier with no access to your information/systems needs only baseline confidentiality; a processor of customer PII needs the full set plus a DPA.

Q4: We can't audit our big cloud providers, does that fail the control? No. Accept their SOC 2 Type II / ISO 27001 evidence in lieu of direct audit, but make the right to request that evidence (and to audit if warranted) contractual.

Q5: What's the single most important clause? For most organisations, incident notification with a defined window, because it determines whether you can meet your own DPDP/CERT-In obligations when a vendor is breached. A DPA is equally essential for any personal-data processor.

Q6: Does a DPA satisfy both DPDP and GDPR? A well-drafted DPA can satisfy DPDP Section 8(2) and GDPR Article 28 together; align it to both and have Legal confirm.

References and Further Reading

Primary standards

• ISO/IEC 27001:2022: Annex A control 5.20.
• ISO/IEC 27002:2022: Clause 5.20 (agreement terms (a)–(r)); related §5.19, §5.21, §5.22, §5.23.

Supporting frameworks

• NIST SP 800-53 Rev 5: SR-3, SA-4, SA-9; NIST SP 800-161 (supply chain).
• NIST CSF 2.0: GV.SC (Cybersecurity Supply Chain Risk Management).
• CIS Controls v8: Control 15 (Service Provider Management).
• PCI DSS v4.0.1: Requirement 12.8.
• SOC 2 (TSC 2017): CC9.2.
• COBIT 2019: APO10 (Managed Vendors).

Indian & global regulations

• Digital Personal Data Protection Act, 2023: Section 8(2) (processor contract), 8(5) (safeguards).
• RBI: Master Direction on Outsourcing of Information Technology Services (2023); Guidelines on Managing Risks and Code of Conduct in Outsourcing of Financial Services (non-IT outsourcing).
• SEBI: Guidelines on Outsourcing of Activities by Intermediaries.
• IRDAI: Outsourcing Regulations.
• CERT-In: Directions under Section 70B of the IT Act, 2000 (2022).
• GDPR: Article 28 (processor agreements).

Singahi resources: the A.5.20 toolkit and related guides for A.5.19 Supplier relationships, A.5.21 ICT supply chain, A.5.22 Monitoring supplier services, and A.5.23 Cloud services.