Supplier Security Risk: ISO 27001 A.5.19–A.5.22, SOC 2 CC9.2, and NIS2 Supply Chain Controls (2026)

Why supply chain security is a top compliance priority in 2026

The SolarWinds attack (2020), Log4Shell (2021), the MOVEit breach (2023), and a stream of CI/CD supply chain attacks have pushed supplier security from "nice to have" to mandatory compliance requirement. ISO 27001:2022, SOC 2, NIS2, and DORA all have explicit supply chain security requirements — and auditors are testing them more aggressively than ever.

For SaaS companies, this matters in two directions: as customers of suppliers (AWS, OpenAI, Stripe, GitHub, Sentry — all are suppliers), and as suppliers to their own customers. If you're in the supply chain of a financial institution, healthcare provider, or government entity, your customers' auditors may scrutinise your supplier security programme directly.

What the frameworks actually require

Framework	Reference	Requirement
ISO 27001:2022	A.5.19	Information security in supplier relationships — policy for managing information security risks associated with suppliers
ISO 27001:2022	A.5.20	Addressing information security within supplier agreements — contractual requirements, data protection clauses, security obligations
ISO 27001:2022	A.5.21	Managing information security in the ICT supply chain — specific controls for ICT products and services; software supply chain integrity
ISO 27001:2022	A.5.22	Monitoring, review and change management of supplier services — ongoing assessment of supplier security performance; managing service changes
SOC 2	CC9.2	The entity assesses and manages risks associated with vendors and business partners — vendor security assessments, monitoring, contractual obligations
NIS2	Art. 21(2)(d)	Supply chain security, including security-related aspects concerning relationships between each entity and its direct suppliers or service providers
DORA	Art. 28–30	ICT third-party risk management — financial entities must maintain register of ICT providers, conduct pre-contract due diligence, include Art. 30 contractual requirements
PCI DSS	Req 12.8	Manage service providers with whom account data is shared — maintain list, written agreements, monitoring programme

Building a supplier security programme: the four components

1. Supplier inventory and tiering

You cannot manage what you haven't inventoried. Start with a complete supplier / ICT provider register. For each supplier, capture: name, service description, data categories processed, personal data involved, criticality to business operations, and contractual status (DPA in place, NDA, SLA).

Risk tier the inventory:

Tier	Criteria	Examples	Due Diligence Required	Review Frequency
Critical (Tier 1)	Access to production data, customer PII, or ePHI; single point of failure for operations; direct integration with production systems	AWS/GCP/Azure, payment processor (Stripe), authentication (Auth0/Okta), primary database	Full security questionnaire, SOC 2 or ISO 27001 report review, DPA/BAA, pen test scope inclusion	Annual
High (Tier 2)	Access to non-production sensitive data; significant operational dependency; access to employee personal data	SIEM / log management (Datadog), error tracking (Sentry), CRM (HubSpot), email (SendGrid)	Abbreviated questionnaire, DPA, certification check	Annual
Medium (Tier 3)	No direct data access; vendor failure would cause inconvenience but not security incident	Project management (Jira/Linear), design tools (Figma), video conferencing (Zoom)	Certification check, DPA where applicable	Every 2 years
Low (Tier 4)	No data access; commodity service; easily replaced	DNS registrar, domain monitoring, website analytics (anonymised)	Policy review only	On contract renewal

ISO 27001 A.5.19 requires a policy for this tiering — not just the act of doing it. Document the criteria and the register in your ISMS.

2. Pre-contract due diligence

Before onboarding a new Tier 1 or Tier 2 supplier, conduct security due diligence. What this looks like in practice:

Security certifications: Request SOC 2 Type II, ISO 27001 certificate, or PCI DSS AOC — whichever is relevant. SOC 2 Type II from a reputable auditor provides strong assurance for US-based SaaS providers.
Security questionnaire: For Tier 1 suppliers without a SOC 2 report, send a security questionnaire. Use the CAIQ (Cloud Security Alliance) or a custom 30–50 question questionnaire covering access control, encryption, incident response, backup, and vulnerability management.
Penetration testing: Ask when their last pen test was conducted, by whom, and whether a summary report is available. Annual external pen test is the minimum expected.
DPA / BAA / contractual terms: Personal data processors require a GDPR Art. 28 DPA. Healthcare data processors require a HIPAA BAA. All Tier 1 suppliers require security obligations in the contract.
Sub-processor disclosure: For data processors, understand their sub-processor chain and whether they have Art. 28(4) back-to-back obligations with their sub-processors.

3. Contractual security requirements (ISO 27001 A.5.20)

ISO 27001 A.5.20 requires security obligations to be formalised in supplier agreements. For Tier 1 and Tier 2 suppliers, contracts should include:

Description of information assets in scope and permitted processing purposes
Data classification and handling requirements (encryption at rest and in transit)
Access control requirements (MFA, principle of least privilege, personnel screening)
Incident notification SLA (typically 24–48 hours for security incidents affecting your data)
Right to audit clause (or acceptance of SOC 2 / ISO 27001 report as audit substitute)
Compliance with applicable law (GDPR, HIPAA, PCI DSS as relevant)
Change notification obligations (significant changes to security architecture, sub-processors)
Data return and deletion on contract termination

NIS2 Art. 21(2)(d) specifically calls for supply chain security in the relationships between entities and their direct suppliers. For NIS2-in-scope entities, supplier contracts must reflect these requirements.

DORA Art. 30 (for SaaS vendors to financial entities): financial entities' ICT contracts with you must contain specific provisions including: description of services, data locations, security measures, access rights, incident management procedures, testing cooperation, and termination rights. If you're selling to banks or insurers, be prepared to accept DORA Art. 30 contractual terms.

4. Ongoing monitoring (ISO 27001 A.5.22)

Due diligence at onboarding is not sufficient — A.5.22 requires ongoing monitoring. Practical approaches:

Annual SOC 2 report review: Request updated SOC 2 Type II reports annually. Check for qualified opinions or significant exceptions.
Security incident notifications: Track security incidents disclosed by suppliers (breach notifications, CVE advisories). Major suppliers should be on your vendor security notification mailing list.
Security rating services: Tools like SecurityScorecard, BitSight, or Panorays provide continuous external assessment of supplier security posture based on public signals. Useful for large supplier portfolios.
Contract renewal reviews: At each contract renewal, refresh the due diligence and update the risk assessment.
Significant change notifications: Contracts should require suppliers to notify you of significant changes to their security architecture, ownership, or sub-processor chain.

ICT supply chain integrity: the 2026 concern (ISO 27001 A.5.21)

A.5.21 is the most forward-looking of the supplier controls — it addresses ICT supply chain integrity, including:

Software bill of materials (SBOM): Understanding what open-source components are in your dependencies and your suppliers' software. Post-Log4Shell, this is now a standard enterprise procurement question.
CI/CD pipeline integrity: GitHub Actions supply chain attacks target build pipelines directly. Control: pin action versions to commit SHA rather than tags (actions/checkout@v4 should be actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683). Audit third-party GitHub Actions regularly.
Package registry security: Typosquatting attacks target npm, PyPI, and RubyGems. Use private registries or lockfiles with integrity hashes; scan dependencies before install.
Signed commits and releases: GPG-signed commits provide traceability; signed container images prevent tampering.

SOC 2 CC9.2: what auditors test

SOC 2 CC9.2 assesses and manages risks associated with vendors and business partners. Auditors will typically review:

Vendor inventory / register — does one exist, is it current?
Risk tiering — is there a documented criteria for how vendors are assessed?
Due diligence evidence — sample 3–5 vendors and verify due diligence was conducted (SOC 2 report requested, questionnaire returned, or equivalent)
DPA / data processing agreements — for any vendors processing personal data on your behalf
Vendor review cycle — evidence that vendor security is reviewed periodically, not just at onboarding
Monitoring — how you track vendor security incidents and service changes

Common gap: the vendor register exists but is not kept current. New vendors added throughout the year, with no security assessment conducted. Solution: vendor onboarding approval gate — no new vendor with data access goes live without completing the due diligence process.

Minimum viable supplier security programme

☐ Supplier register created and maintained (minimum quarterly update)
☐ Risk tiering applied to all suppliers (Critical / High / Medium / Low)
☐ Pre-contract due diligence conducted for all Tier 1–2 suppliers
☐ DPA in place with all data processors
☐ Supplier contracts include security obligations and incident notification SLA
☐ Annual review of Tier 1 supplier SOC 2 reports or equivalent certifications
☐ Sub-processor list maintained and published
☐ New vendor onboarding gate (approval required before data access)

Generate your supplier security documentation

⚠️ This guide is for informational purposes only and does not constitute legal or compliance advice. Supplier security requirements vary by framework, industry, and jurisdiction. Always have supplier contracts reviewed by qualified legal counsel.