Third-Party Security Policy

Purpose

This policy sets out how [[Organisation Name]] manages the information security risk that comes from its suppliers, so that the services, systems and data it entrusts to others are protected to the same standard as its own, and so that it can show customers, auditors and regulators that it knows which suppliers it depends on and how well they are protected. It applies the effort in proportion to each supplier's criticality: most assessment effort goes to the few suppliers the organisation could not do without.

Scope

This policy applies to:

• Suppliers: every third party that provides [[Organisation Name]] with a product or service, including cloud and software-as-a-service providers, managed IT and security service providers, processors of personal data, outsourced business services, logistics and other operational partners, and their subcontractors where they deliver part of the service to us.
• Stages: selection, contracting, renewal, changes to the service, monitoring during the contract, and exit.
• People: everyone who selects, buys, contracts with, manages or relies on a supplier, and the roles named in this policy.

Excluded: [[anything deliberately left out, and where it is covered instead, e.g. intra-group services covered by the group's own policy — or "None"]]. A supplier with no service dependency, no access and no data is still screened at intake (TP-01); the screening places it in the lowest tier, where no further assessment is needed.

Policy statements

The Supplier Criticality & Tiering Model sets the criteria, overrides, questionnaire sets, evidence and reassessment intervals the statements refer to; the Supplier Security Assessment Procedure sets the steps.

Selection and tiering

TP-01 No supplier may be engaged, and no contract renewed, until intake screening is done and a tier is recorded.

Evidence: an intake record and a tier for every supplier in the Supplier Security Risk Register, dated before its contract or renewal was signed.

TP-02 The tier must be the highest any criterion reaches, and never below an override's minimum.

Evidence: the criteria scores and any override recorded with each tier, as the Supplier Criticality & Tiering Model sets them.

Assessment and decision

TP-03 Each supplier must be sent the questionnaire set and evidence request for its tier, and never a set above it.

Evidence: the questionnaire set issued, from the Tiered Supplier Security Questionnaire, matching the supplier's tier.

TP-04 Evidence must be validated, not just received: its scope, dates and legal entity must match the service we buy.

Evidence: the Supplier Due Diligence Evidence Checklist, completed for each assessment, showing scope, dates and supplier name checked.

TP-05 Every assessment must end in a documented decision (Approve, Approve with conditions, Escalate, Reject), signed by the business owner.

Evidence: a signed decision in each Supplier Security Review Report Template.

TP-06 Residual supplier risk must be scored on the P05 scale; a supplier outside appetite must be entered in the risk register.

Evidence: the residual score and band on every assessment; for a supplier outside appetite, its entry in the Information Security Risk Register.

Contracting

TP-07 Contracts must carry the security clauses for the supplier's tier and data type before they are signed.

Evidence: the clauses selected from the Supplier Contract Security Clause Library for the tier and data type, in the signed contract.

Monitoring

TP-08 Every finding must have an owner and a deadline set by its severity; a High finding past its deadline must be escalated to the business owner.

Evidence: an owner and a deadline on every open finding; for each High finding past its deadline, the record that the business owner was told.

TP-09 Suppliers must be reassessed within their tier's interval, and on any material change, incident or breach at the supplier.

Evidence: the last assessment date and the next due date in the register, and a reassessment record after each material change, incident or breach.

Incidents and continuity

TP-10 Critical suppliers must be part of incident response and continuity plans, with named contacts and notification duties.

Evidence: named supplier contacts and notification duties in the incident response and continuity plans for every Tier 1 (Critical) supplier.

Exit

TP-11 Every Tier 1 and Tier 2 contract must have an exit plan: data return or deletion, access removal, and a transition period.

Evidence: an exit plan for every Tier 1 and Tier 2 contract; at exit, a record of data returned or deleted and access removed.

Reporting

TP-12 Coverage, overdue reviews, open findings and concentration must be reported to executive management every quarter.

Evidence: the quarterly report to executive management, with TPM-01, TPM-02, TPM-03, TPM-04.

Roles and responsibilities

Compliance and consequences

How compliance is checked. The Head of Information Security checks compliance with this policy every quarter: by comparing the contracts signed or renewed in the quarter with the intake and tier records in the Supplier Security Risk Register (TP-01, TP-07); by checking assessments and reassessments against their due dates (TP-09); and by checking findings against their deadlines (TP-08). [[Internal audit]] tests a sample of [[5]] supplier files [[every year]]. The results are reported to executive management every quarter (TP-12) with these measures:

Consequences of not complying. A supplier engaged without intake and a tier, or a contract signed without the clauses for its tier, is reported to [[executive management]] and assessed at once; [[no further orders are placed until the assessment is complete]]. Staff who do not follow this policy may face action under the [[disciplinary procedure]]. For a supplier, not meeting the security clauses of its contract is a breach of that contract, handled under its terms.

Exceptions

Any deviation from this policy must be requested, assessed and approved under the Security Exception & Waiver Standard [[document ID]], using the Security Exception Request & Approval Form, before the deviation begins. An exception is time-limited and recorded in the Security Exception Register. Agreement by email, in a meeting or by a manager is not an exception.

An exception is for a rule that cannot be met — for example, a Tier 1 supplier that will not accept a clause its tier requires. A supplier whose residual risk is outside appetite is not an exception: it is escalated and entered in the Information Security Risk Register (TP-06). Where an exception leaves a supplier risk outside appetite, or scored Critical, the approver the Information Security Risk Management pack requires for that position also signs the exception: the stricter of the two always applies.

Related documents

Definitions

Document control

Approval record

Review. This policy is reviewed at least every 12 months, and sooner after: a major incident, or an incident the document should have prevented; a material change to the organisation's activities, systems or suppliers; a change in law, regulation or a contract the document supports; an audit or assessment finding against the document; a significant change in the threats the document addresses. The revision history is at the front of this document.

Publication. The current approved version is published at [[location everyone in scope can reach]], and suppliers are given the parts that apply to them [[with the contract]].

Adapting this template

Framework references

These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2); Regulation (EU) 2022/2554 (DORA); Regulation (EU) 2016/679 (GDPR).