Supplier Security Policy: Defining Requirements for Third Parties

Why suppliers are a security risk

Most organizations invest significantly in their own IT security: firewalls, endpoint protection, training, policies. At the same time, they grant dozens of suppliers and service providers access to internal systems, data, and networks — often without verifying what level of security these third parties actually provide.

The IT service provider has remote access to the servers. The cloud provider stores customer data. The recruitment agency processes applicant data. The facilities management company has physical access to rooms containing IT infrastructure. The marketing agency has login credentials for the CMS and social media accounts.

Each of these access points is a potential attack vector. The attacks on SolarWinds, Kaseya, and MOVEit have demonstrated that supply chain attacks are a preferred attack model. An attacker who breaches your service provider can enter your network through the existing trust relationship, often without your own security systems raising an alarm.

The supplier security policy is the document that addresses these risks. It defines the security requirements you impose on third parties, how you assess suppliers, which contractual provisions apply, and how you monitor compliance.

Regulatory requirements

NIS2

NIS2 Article 21 Paragraph 2 No. 4 requires affected organizations to implement measures for "supply chain security, including security-related aspects of the relationships between each entity and its direct suppliers or service providers." This is not a vague recommendation but a concrete obligation.

The NIS2 transposition into national law (NIS2UmsuCG) specifies this requirement and makes clear that organizations must systematically assess and manage the risks of their supply chain.

ISO 27001

ISO 27001 dedicates five controls in Annex A to the topic:

• A.5.19 Information security in supplier relationships: Fundamental policy for managing supplier risks
• A.5.20 Addressing information security within supplier agreements: Security requirements in contracts
• A.5.21 Managing information security in the ICT supply chain: Specific requirements for IT suppliers
• A.5.22 Monitoring, review and change management of supplier services: Ongoing monitoring
• A.5.23 Information security for use of cloud services: Special requirements for cloud services

A single supplier security policy can address all five controls, provided it fully covers each aspect.

Scope and supplier classification

The policy begins by defining which suppliers fall within the scope. The answer is: all third parties that have access to information, systems, premises, or networks of the organization, or that process personal data on behalf of the organization.

Not every supplier represents the same risk. The office supplies vendor has no system access; the managed service provider does. The policy must therefore include a classification that reflects the supplier's risk profile.

Risk classes

Class A (High risk): Suppliers with direct access to critical systems or confidential data. Cloud providers, managed service providers, IT service providers with administrator access, development partners, data centers. Requirements: comprehensive security requirements, contractual agreements, regular review, audit rights where applicable.

Class B (Medium risk): Suppliers with limited access to internal data or systems. HR service providers, tax advisors, attorneys, marketing agencies with system access, external consultants. Requirements: defined security requirements, contractual provisions, periodic review.

Class C (Low risk): Suppliers without direct access to systems or confidential data. Office supplies vendor, cleaning service (without access to IT rooms), catering. Requirements: basic security requirements (e.g., confidentiality), access regulations where applicable.

Classification is performed during the initial assessment of the supplier and is reviewed when there are significant changes to the business relationship or scope of services.

Security requirements for suppliers

The policy defines security requirements imposed on suppliers. These requirements are tiered by risk class.

Baseline requirements (all suppliers)

• Compliance with applicable laws and regulations, especially data protection (DSGVO/GDPR)
• Confidentiality agreement (NDA) for all personnel with access to company information
• Immediate notification of security incidents that could affect the client's data or systems
• Return or verified destruction of all company data at contract end

Extended requirements (Class A and B)

• Documented information security management (ISMS according to ISO 27001, TISAX, SOC 2, or equivalent)
• Access control based on the least-privilege principle
• Encryption of data in transit and at rest
• Regular security training for their own employees
• Patch management with defined timelines
• Backup and disaster recovery for systems operated on behalf of the client
• Incident response capability with a documented process
• Willingness to answer security questionnaires
• Notification obligation for significant changes in security posture (e.g., own security incident, change of subcontractors)

Additional requirements for Class A suppliers

• Proof of a current certification (ISO 27001, SOC 2 Type II, TISAX, or comparable)
• Right of the client to conduct security audits or review current audit reports
• Regular penetration tests by independent third parties with reporting to the client
• No subcontracting without prior approval
• Designation of a security point of contact

The policy must not turn into a wish list that no supplier can fulfill. It must be realistic and reflect the risk profile of the supplier relationship. Demanding ISO 27001 certification from a local repair shop is neither proportionate nor enforceable.

Contractual anchoring

Security requirements that are not contractually agreed upon are worthless in case of dispute. The policy must therefore require that security requirements become part of all relevant contracts.

Instruments of contractual protection

Confidentiality agreement (NDA): Baseline for every business relationship involving access to non-public information.

Data processing agreement (DPA): Mandatory under GDPR Art. 28 when the supplier processes personal data on behalf of the organization. The DPA already contains many security-relevant provisions but must be supplemented with ISMS-specific requirements.

Security annex to the contract: A dedicated annex summarizing the technical and organizational security requirements. This annex becomes part of the main contract and is legally binding.

Service Level Agreements (SLA): For IT service providers operating systems, SLAs must operationalize security requirements: response times for security incidents, availability guarantees, patching windows, backup obligations.

What must be contractually regulated

The policy specifies which points must at minimum be addressed contractually — specific template wording is covered in the article on IT security clauses in contracts:

• Type and scope of access to information and systems
• Security requirements according to the supplier's risk class
• Reporting obligations for security incidents and deadlines
• Right to audit and review security evidence
• Provisions for the use of subcontractors
• Obligations at contract termination (data return, deletion, access revocation)
• Liability provisions for security breaches
• Jurisdiction and applicable law

Supplier assessment

The policy must define how suppliers are assessed: during initial selection and on an ongoing basis.

Initial assessment

Before a new Class A or B supplier is engaged, they undergo a security assessment. The policy defines the process:

1. Risk classification: Categorization of the supplier based on planned access to data and systems.
2. Security questionnaire: The supplier answers a standardized questionnaire about their security measures. For Class A suppliers, the questionnaire is more extensive than for Class B.
3. Evidence review: Submission of certificates (ISO 27001, SOC 2), penetration test reports, audit reports.
4. Risk assessment: Based on the collected information, the ISO (in coordination with IT where applicable) assesses the risk and provides a recommendation.
5. Approval: Approval of a Class A supplier is given by executive management. Class B suppliers are approved by the ISO.

Ongoing monitoring

The initial assessment is not sufficient. A supplier's security posture can change: through personnel changes, technical changes, their own security incidents, or changed business conditions.

The policy specifies:

• Annual review of all Class A suppliers (security questionnaire, certificate verification)
• Biennial review of all Class B suppliers
• Event-driven review when security incidents become known, when there are significant changes to services, or in response to negative media reports
• Review upon contract renewal as a fixed part of the renewal process

Review results are documented. When deficiencies are identified, remediation measures are agreed upon and their implementation is tracked. If a supplier fails to meet minimum requirements and shows no willingness to improve, the policy must provide an escalation process up to and including contract termination.

Handling subcontractors

Many suppliers in turn engage subcontractors. Your IT service provider commissions a specialist for network monitoring; your cloud provider uses the infrastructure of a data center operator. The policy must address this topic.

Approval requirement: For Class A suppliers, the policy requires that the use of subcontractors who have access to your data or systems must be approved in advance.

Flow-down of requirements: The supplier must ensure that their subcontractors meet at least the same security requirements as they do.

Transparency: The supplier must disclose which subcontractors are used and what services they provide.

Incident management with suppliers

If a supplier suffers a security incident that affects your data or systems, every hour counts. The policy must define what reporting obligations the supplier has and how your organization handles such reports.

Supplier reporting obligation: Immediate notification, no later than 24 hours after becoming aware. The notification must include an initial assessment of the incident, the affected data, and the countermeasures taken.

Communication channel: The policy defines to whom at the client the notification is made (ISO or designated contact point) and through which channel.

Cooperation obligation: The supplier is obligated to cooperate in the analysis and remediation and to provide all relevant information.

Impact on assessment: A security incident at a supplier triggers an unscheduled reassessment and may lead to tightened requirements or contract termination.

Contract termination and offboarding

The policy must govern what happens when a supplier relationship ends:

• Access revocation: All access to systems, networks, and premises is immediately disabled.
• Data return and deletion: The supplier returns all company data and confirms complete deletion of their copies in writing.
• Knowledge transfer: Relevant knowledge about operated systems is transferred to the successor or internal IT.
• Documentation: The offboarding is documented, including confirmation that all obligations have been fulfilled.

Example outline for a supplier security policy

1. Purpose and scope
2. Terms and definitions — Supplier, subcontractor, risk class
3. Normative references — ISO 27001 A.5.19–A.5.23, NIS2 Art. 21 No. 4, GDPR
4. Supplier classification — Risk classes A, B, C with criteria
5. Security requirements — Baseline, extended, and Class A–specific
6. Contractual provisions — NDA, DPA, security annex, SLA
7. Initial assessment of new suppliers — Process, questionnaire, approval
8. Ongoing monitoring — Frequency, methods, escalation
9. Subcontractors — Approval, requirements, transparency
10. Incident management — Reporting obligations, cooperation
11. Contract termination and offboarding — Access, data, knowledge transfer
12. Responsibilities — ISO, procurement, IT, business departments
13. Exceptions and risk acceptance
14. Review and update
15. Effective date and approval

Common mistakes and how to avoid them

Treating all suppliers equally

If you demand the same security level from every supplier, you overwhelm small service providers and underchallenge critical IT partners. Risk classification is not an optional luxury but a prerequisite for proportionate and enforceable requirements.

One-time assessment without follow-up

Many organizations assess suppliers at onboarding and then forget about them. A supplier's security posture can change at any time. Without regular reviews, you are operating under a false sense of security. At least annual reviews for Class A suppliers are essential. A security questionnaire significantly simplifies recurring assessments.

Security requirements only in the NDA

An NDA governs confidentiality but not technical security measures. Security requirements belong in a separate security annex or the main contract, not only in the confidentiality agreement.

Failing to involve procurement

If the procurement department does not know the policy or perceives it as an obstacle, suppliers will be engaged without a security assessment taking place. Procurement must be involved from the start and view the security assessment as an integral part of the procurement process, not as an additional hurdle.

No response to supplier incidents

If a supplier reports a security incident and your organization does not respond, you are not only missing damage mitigation but also the evidence that you take your duty of care seriously. The policy must define a clear process for handling supplier incidents, including an assessment of the impact on your own organization.

From policy to living practice

A supplier security policy is only effective when it is consistently applied. Procurement must consider it for every new engagement, IT must only set up access after approval, and the ISO must actually perform the regular reviews.

The most common reason for failure is a lack of procurement involvement. In ISMS Lite, the entire supplier lifecycle — from initial assessment through ongoing monitoring to offboarding — can be mapped and linked with the associated contracts and security questionnaires. If procurement does not know the policy or perceives it as an obstacle, it will be circumvented. That is why it is important to involve procurement from the start and to design processes that complement rather than block the procurement workflow.

ISMS Lite supports the entire policy lifecycle: from creation with AI support through versioning and approval workflow to digital acknowledgment by all participants. Management approves the policy with a signature, and you can demonstrate at any time who acknowledged the policy and when. This makes the supplier security policy a living part of your ISMS.

Further reading

• Supplier assessment and security questionnaire: Practical guide
• Supply chain attacks: How to secure your supply chain
• Reviewing DPAs and assessing service providers
• NIS2 for mid-market companies: What you need to know
• Policy lifecycle: From creation to retirement