Security assurance plan: securing your service providers by contract

A security assurance plan is the contractual document in which a provider describes the security measures it commits to apply to meet its customer's requirements. Written by the provider in response to the tender, then annexed to the contract, it sets out the security organisation, technical measures, incident management, audits and reversibility. The concept comes from ANSSI's guide on outsourcing; it remains the most structured tool for writing security clauses into a service contract, and a central part of third-party risk management.

The security assurance plan is the security counterpart of the quality assurance plan well known to procurement teams and project managers. Where the quality plan describes how the provider guarantees the quality of its deliverables, the security plan describes how it guarantees the security of the service: who is responsible, which measures apply, how incidents are handled, how the customer can check, how the contract ends.

Three features set it apart from a sales brochure:

• it is contractual: annexed to the contract, it binds the provider, and breaches can lead to penalties;
• it answers the customer's requirements, one by one, rather than describing the provider's security in general;
• it is specific to one service: the same provider will have a different plan for each customer and scope.

When should you require one?

A security assurance plan is justified as soon as the provider accesses your information system, hosts or processes sensitive data, or delivers a service whose interruption would hurt you: managed services, hosting, application maintenance, SaaS software, service desk, security services. For a standard supplier, a few security clauses in the contract are enough. The right level follows from ranking your third parties by criticality: a critical provider justifies a full plan, an important one a lighter plan focused on access, incidents and reversibility.

The reference for the plan is the guide “Outsourcing and information system security: a guide to managing the risks”, published by ANSSI, the French national cybersecurity agency, on 3 December 2010. The guide starts from one observation: outsourcing the operation of an information system creates specific risks, which it groups into three families, loss of control over the system, remote interventions and shared hosting. It then proposes a three-step approach:

1. Assess the risks and set security objectives for the outsourced service.
2. Write the specifications with security requirements and clauses, and ask for a plan in response.
3. Select the provider by checking that each plan is admissible, then finalise the winner's plan before the contract is awarded.

The guide states that the plan is written by the bidder, under its security lead's responsibility, reviewed by the customer's security lead and then annexed to the contract, where it replaces, where relevant, the provider's generic security clauses. It recommends attaching a template to the tender to make offers easier to compare, and placing the plan in the contract documents right after the quality plan, with the same priority. Finally, the guide provides a plan template, standard security requirements and sample clauses.

The plan is also recognised in French public procurement: the simplified cybersecurity clauses, approved by an order of 18 September 2018, provide that contracts whose main purpose is digital, such as outsourcing an information system, may add a security assurance plan produced by bidders and contracted with the winner.

ANSSI's model has eleven headings. We have reorganised it into twelve sections and added the requirements that have appeared since 2010 with DORA and the GDPR. Each section shows the reference it derives from.

1. Purpose and scope
2. Reference documents and definitions
3. Description of the service (architecture, sites, countries)
4. Customer security requirements
5. Security organisation (leads, steering committee)
6. Responsibilities and commitments
7. Security measures (access, data, operations, continuity)
8. Incident management
9. Subcontracting
10. Oversight, audit and indicators
11. Reversibility and end of contract
12. Life of the plan (changes, non-conformities, penalties, coverage matrix)

Expand each section to see what it should contain.

The most useful section day to day is often the requirements coverage matrix: a table that lists each customer requirement and shows, alongside, the provider's corresponding measure, its status (compliant, partial, waiver) and the related evidence. It is what makes the plan verifiable, and what you will come back to in audits. It naturally builds on the answers to your supplier security questionnaire.

In practice, all three coexist: the security annex (or specifications) sets the requirements, the plan answers them, and the processing agreement governs personal data. The European Commission has published standard contractual clauses between controller and processor; our GDPR module helps keep this side up to date.

ANSSI's guide lists the clauses to include: transfer of the system, liability, provider obligations, steering committee, confidentiality, data location, service level agreement, audits, secure development, change management, reversibility and termination. Five of them account for most disputes.

Audit rights

Specify who may audit (the customer, an appointed third party, the supervisory authority), on what scope (documents, sites, technical tests), how often, with what notice, and who pays. Without this clause, a provider can legitimately refuse an audit.

Incident notification

Set a time limit in hours, the minimum content of the notification, the contact and the channel. The time limit must leave you enough time to meet your own obligations, such as the GDPR's 72 hours to notify a data breach to the authority.

Reversibility

Describe how data is returned (format, time, assistance), the length of the transition period during which the service continues, and certified deletion of data. Unprepared reversibility is one of the most frequent causes of unwanted dependency.

Data location

List the countries where data is hosted, backed up and accessible, support included, and require advance notice of any change. This is also where exposure to non-European laws is addressed.

Subcontracting

Require the list of subcontractors, your prior authorisation, flow-down of security requirements and a right to object. Supply chain attacks often go through this tier.

For financial entities, Article 30 of DORA lists the mandatory clauses of ICT services contracts, strengthened for critical or important functions, and Delegated Regulation (EU) 2024/1773 specifies the expected contractual policy. The plan is a natural vehicle to meet them. The mapping is direct:

Note: DORA requires these clauses to be in the contract itself. A plan annexed to the contract is part of it, but check with your legal team that the order of precedence of contract documents allows this. Outside the financial sector, NIS 2 requires addressing security in the relationship with each direct supplier (Article 21): we compare these texts in our article on third-party risk, NIS 2 and DORA.

A plan signed and filed away protects nothing. It must follow the service: a steering committee at a set frequency, security indicators reported to the customer, regular audits, updates after every significant change, and preparation for reversibility from signature. The diagram below shows this cycle.

Gaps found in audits feed a dated action plan. If they persist, the plan provides either for penalties or for a formal waiver accepted by the risk owner. On the customer side, keep a record of each version of the plan, each committee and each audit: that is what an inspector, or a judge, will ask you for.