Supplier Security Policy Template: Govern Suppliers From Selection to Exit

Supplier compromises keep succeeding because security is applied at one moment in the relationship, usually the questionnaire before signing, while the data, integrations and dependency grow for years afterwards. This template sets security requirements across the whole supplier lifecycle: inventory, risk tiering, due diligence, contract terms, onboarding, ongoing monitoring, supplier incidents, changes and subcontractors, software and product suppliers, and exit. It is written for CISOs, third-party risk managers, procurement and legal teams, and complements the Third-Party Access Policy Template, which governs how supplier people and systems log in to yours. Have legal and procurement review it before adoption, particularly where DORA, NIS2 or sector rules apply.

How to use this template

• Replace text in square brackets, such as [Organisation], [TPRM team] and [24 hours], with your own terms and values. Bracketed values are suggested defaults, not external requirements.
• "Must" indicates a mandatory requirement. "Should" indicates a recommended practice where a documented exception may be justified.
• Tiers used throughout (Tier 1 Critical to Tier 4 Low) come from the Vendor Tiering and Inherent Risk Questionnaire Template. Rename them to match your scheme.
• Keep contract clauses in a separate schedule so legal can maintain them; see the Third-Party Security Contract Clauses Template.
• If you are a financial entity in the EU, map section 4 to your DORA ICT third-party risk obligations; see the DORA ICT Third-Party Risk and Register of Information Guide.

1. Purpose

This policy sets the security requirements [Organisation] applies to suppliers, from selection through to exit, so that the risk each supplier brings to [Organisation]'s information, systems, services and customers is known, proportionate to its tier, written into the contract, monitored for the life of the relationship, and closed down cleanly at the end. It supports NIST CSF 2.0 outcome GV.SC-01: a cybersecurity supply chain risk management programme, strategy, policies and processes established and agreed by organisational stakeholders.

2. Scope

This policy applies to every external party that provides goods or services to [Organisation] and that touches its information, systems, premises or the delivery of its services, including:

• SaaS, cloud, hosting and managed service providers, including managed security and IT service providers.
• Software, hardware, firmware and AI model or AI service suppliers, including open source components procured with support.
• Professional services, contractors, outsourcers, data processors and business process providers.
• Integrations and connected applications that hold credentials or tokens to [Organisation] systems, whether purchased or free.
• Facilities, logistics and other suppliers with physical access to [Organisation] premises or equipment.

It applies to all staff who request, buy, own or manage supplier relationships. Intra-group service providers are in scope.

3. Roles and responsibilities

4. Policy statements

4.1 Inventory

1. [Organisation] must maintain a single supplier inventory recording, for each relationship: legal entity, service, business owner, tier, data classification handled, access and integrations, critical services supported, contract dates, key subcontractors, and assessment status.
2. The inventory must be reconciled at least [quarterly] against accounts payable, contract management, corporate card spend, single sign-on application lists and OAuth consent grants, to find suppliers that bypassed procurement.

4.2 Tiering

1. Every new supplier relationship, and every material change in scope, must be tiered before contract using [the inherent risk questionnaire].
2. The tier sets due diligence, contract terms and reassessment frequency (sections 4.3, 4.4 and 4.6). Contract value must not be used to lower a tier.

4.3 Due diligence before contract

1. Findings must be rated, and high findings must be remediated before go-live or accepted in writing by the risk owner with compensating controls and a date.
2. Assurance reports must be checked for scope: the service purchased must be in scope of the report, and carve-outs and complementary user entity controls must be recorded. See How to Read a SOC 2 Report Guide.

4.4 Contract requirements

Contracts for Tier 1 and Tier 2 suppliers must include, at minimum:

1. Security requirements proportionate to the data and access, referencing [Organisation]'s security schedule.
2. Notification of security incidents affecting [Organisation] within [24 hours] for Tier 1 and [48 hours] for Tier 2 of the supplier becoming aware, with named contacts and ongoing updates. See the Third-Party Incident Notification Clauses Guide.
3. Right to assess, including audit or the provision of current independent assurance reports.
4. Approval or notice of new subcontractors that process [Organisation] data, and flow-down of equivalent obligations.
5. Data location, return and certified deletion at exit, and assistance with transition to another provider.
6. Obligations to rotate or revoke credentials and tokens issued to or by the supplier on request and at exit.

4.5 Onboarding

1. Supplier access and integrations must be provisioned only after the contract is signed and the tier recorded, through [approved access routes] under the third-party access policy.
2. Every account, API key, OAuth grant, service account and certificate issued to a supplier must be recorded against the supplier record, with an internal owner, least-privilege scope and an expiry.
3. Incident contacts must be exchanged and tested before go-live for Tier 1 suppliers.

4.6 Ongoing monitoring and reassessment

1. Supplier access and integration credentials must be reviewed at least [quarterly] for Tier 1 and [semi-annually] for Tier 2, and unused credentials revoked.
2. Open findings must be tracked to closure; overdue high findings must be escalated to [the CISO].

4.7 Supplier incidents

1. A suspected or confirmed security incident at a supplier that may affect [Organisation] must be handled under the incident response plan, starting with an assessment of which data, accounts, tokens and integrations the supplier held.
2. Where a supplier's credentials or tokens may be compromised, [Organisation] must revoke and reissue them without waiting for the supplier's root cause. In the Salesloft Drift breach, OAuth tokens held by a chat integration were used to export customers' Salesforce data.
3. See the Third-Party Incident Response Playbook.

4.8 Changes, subcontractors and concentration

1. Material changes by the supplier (ownership, hosting location, major subcontractors, a significant incident) must trigger re-tiering.
2. For Tier 1 suppliers, [Organisation] must know the key subcontractors (fourth parties) that support the service. See the Fourth-Party and Nth-Party Risk Guide.
3. Where several critical services depend on one supplier, the dependency must be recorded in the risk register with an exit or substitution option.

4.9 Software, hardware and AI suppliers

1. Suppliers of software that runs in [Organisation]'s environment should provide a software bill of materials on request, a vulnerability disclosure route, and a commitment to security updates for the supported life of the product. See the SBOM Guide.
2. Tier 1 and Tier 2 software suppliers should attest to secure development practices, for example against the NIST Secure Software Development Framework. See the CISA Secure Software Attestation Form Guide.
3. AI suppliers must state whether [Organisation] data is used for training and must allow it to be excluded. See the Third-Party AI Risk Guide.

4.10 Exit

1. At termination, [Organisation] must revoke all supplier accounts, credentials, tokens, keys and network paths within [5 working days], and confirm return or certified deletion of data.
2. Tier 1 suppliers must have a documented and, where feasible, tested exit plan. See the Vendor Offboarding and Termination Guide.

5. Exceptions

1. Exceptions (for example a supplier that refuses audit rights or will not meet notification timings) must be recorded with the residual risk, compensating controls and a review date no later than [12 months].
2. Exceptions for Tier 1 suppliers are approved by [CISO]; others by [TPRM lead]. The business owner may not approve their own exception.

6. Compliance and monitoring

1. The [TPRM team] must report [quarterly] on:
   • Percentage of active suppliers with a current tier.
   • Tier 1 and Tier 2 suppliers with an overdue reassessment.
   • Contracts signed without required diligence (target zero).
   • Supplier credentials and integrations linked to a supplier record and an internal owner.
   • Open high findings by age.
   • Suppliers found outside procurement by the inventory reconciliation.
2. Compliance with this policy is subject to internal audit at least [annually].

7. Review and approval

Implementation guidance

Rollout

1. Build the inventory: merge procurement, finance, SSO and OAuth data. Expect it to find more suppliers than the contract system holds.
2. Tier the top of the list: tier suppliers with privileged access, Restricted data or critical service dependency first, and assess them against section 4.3.
3. Gate procurement: require a tier before a purchase order; start with SaaS purchases, then extend to all categories.
4. Fix contracts at renewal: add the section 4.4 terms at each renewal rather than renegotiating everything at once.
5. Roll back safely: if the gate creates a backlog, allow Tier 3 and 4 to proceed with diligence completed within [30 days] of contract, never Tier 1 or 2.

Regulatory context

• NIS2: Directive (EU) 2022/2555, in force since 16 January 2023, lists supply chain security among the cybersecurity risk-management measures in Article 21, including the security of relationships with direct suppliers and service providers. National transposition varies; see the NIS2 Directive Guide.
• DORA: EU financial entities have specific ICT third-party risk and register requirements; see the DORA Guide.

Framework mapping

Sources

• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NCSC: Supply chain security principles
• EUR-Lex: Directive (EU) 2022/2555 (NIS2)

Related NHI Mgmt Group resources: Third-Party Risk Management Guide · Third-Party Access Policy Template · Vendor Tiering and Inherent Risk Questionnaire Template · ISO/IEC 27036 Supplier Relationships Guide · Vendor Security Assessment Template