Secure Contracting Policy
1. Objective​
This policy defines the security requirements applicable to the contractual lifecycle with suppliers, partners and contractors that access the organisation's systems, data or infrastructure.
Outsourcing technical competences and using third-party services are common operational practices. However, each supplier or contractor with technical access represents an additional risk vector: they may introduce vulnerabilities, have access to sensitive data without an adequate framework, or retain residual access after the end of the contract. Managing this risk cannot be relegated to a generic confidentiality clause - it requires a structured process that begins before the contract is signed and ends only with verified offboarding.
The objective of this policy is to ensure that:
- The security assessment of suppliers is carried out before any contract that involves access to systems or data
- Contracts include security clauses proportional to the risk level of the relationship
- The technical onboarding of contractors is conditional on completion of minimum mandatory training
- The compliance of active suppliers is monitored and reassessed periodically
- Offboarding is executed immediately, completely and in an auditable manner
2. Scope and applicability​
This policy applies to all suppliers, partners and contractors that:
- Access the organisation's systems, platforms or infrastructure
- Develop, maintain or operate software components on behalf of the organisation
- Process, store or transmit data of the organisation or of its users
- Have access to regulated environments (production, health data, financial data, PII)
| Level | Applicability |
|---|---|
| L1 | Mandatory; proportionate security clauses (confidentiality and good practice); supplier validation before onboarding, with a questionnaire or checklist; security contact defined |
| L2 | Mandatory; pre-contractual due diligence; SbD-ToE clauses; documented onboarding; annual reassessment |
| L3 | Mandatory; formal due diligence; technical audit; complete clauses; SBOM and test reports mandatory; half-yearly reassessment; formal right to audit |
3. Pre-contractual due diligence​
Before establishing any contractual relationship with technical access, a security assessment proportional to the risk level must be carried out:
3.1 Assessment criteria​
| Criterion | L2 | L3 |
|---|---|---|
| Documented information security policy | Verification | Mandatory + evidence |
| Vulnerability management process | Verification | Mandatory + defined SLA |
| Security incidents in the last 12 months | Declaration | Declaration + analysis |
| Certifications or compliance with standards (ISO 27001, SOC 2, etc.) | Recommended | Mandatory for access to regulated data |
| Capability to deliver SBOM | Not applicable | Mandatory for developed software |
| Recent security test reports | Recommended | Mandatory |
| Documented offboarding process | Recommended | Mandatory |
3.2 Due diligence outcome​
The outcome of the due diligence must be documented and approved before the contract is signed:
- Approved without conditions: contractual relationship established
- Approved with conditions: contract established with a remediation plan for the gaps identified and a defined deadline
- Rejected: supplier not eligible for a relationship with technical access until the non-conformities are resolved
4. Minimum contractual security clauses​
All contracts that involve technical access must include security clauses proportional to the risk level:
4.1 Universal clauses (all levels)​
| Clause | Description |
|---|---|
| Confidentiality | Obligation of confidentiality regarding data, credentials and architecture |
| Incident notification | Time limit for notifying the organisation of security incidents (without undue delay and ≤ 24 hours after becoming aware) |
| Acceptable use | Prohibition of access beyond what is strictly necessary for the contractual scope |
| Subcontracting | Prohibition or conditioning of subcontracting with access to data or systems |
| Termination for breach | Clause for immediate termination in the event of a serious security breach |
4.2 Additional clauses by risk level​
| Level | Additional clauses |
|---|---|
| L1 | Generic commitment to good practices; incident notification policy |
| L2 | Application of the SbD-ToE Catalogue; provision of technical evidence on request; SLA for resolution of critical vulnerabilities |
| L3 | Mandatory periodic security testing (with report delivered); SBOM delivered per release; SLA for critical fixes (≤ 72 hours); formal right of technical audit by the organisation; security training requirements for personnel with access |
4.3 Reference contract template​
The organisation must maintain a standard contract template with legally validated security clauses, updated annually or after relevant regulatory changes. The template must be made available to Procurement and Legal as a negotiation reference - security clauses are minimum requirements, not negotiation points in L2/L3 contracts.
4.4 Processors of personal data (GDPR, Article 28)​
When the supplier processes personal data on behalf of the organisation, it is a processor within the meaning of the GDPR, and the processing is governed by a contract, at any level. The contract sets out the subject matter, duration, nature and purpose of the processing, the type of personal data and the categories of data subjects, and obliges the processor to:
- process the data only on documented instructions from the organisation, including with regard to transfers, and inform it if it considers that an instruction infringes data protection law;
- ensure that authorised persons are bound by confidentiality;
- adopt the security measures of Article 32 of the GDPR (the clauses in sections 4.1 and 4.2 are the minimum);
- engage another processor only with the organisation's prior authorisation and under the same conditions;
- assist the organisation in responding to data subjects' requests (see
PRI-003) and in meeting its obligations on security, breach notification and impact assessment; - at the end of the service, delete or return the data and delete any copies, unless there is a legal obligation to retain them (see
PRI-002); - make available the information needed to demonstrate compliance and allow for audits.
For AI service vendors, section 10 adds the specific clauses.
5. Technical onboarding of contractors​
Contractors who access the organisation's systems or repositories must complete a technical onboarding process before receiving permissions:
5.1 Onboarding process​
| Step | Description | Applicability |
|---|---|---|
| Minimum training track | Training on security policies, credential management, data access, incident reporting | L2/L3 mandatory; L1 recommended |
| Validation of understanding | Quiz or test with a minimum pass mark of 80% | L2/L3 mandatory |
| Signing of specific terms | Individual statement of responsibility and confidentiality | All levels |
| Sandbox environment | Initial access to an isolated development environment before production | L3 mandatory |
| Assignment of minimum permissions | Access under the principle of least privilege; no production access without explicit approval | L2/L3 mandatory |
5.2 Access blocking​
Access to the organisation's systems is blocked until all mandatory onboarding steps have been completed. Completion must be recorded (LMS, HR system or equivalent tool) and associated with the contractor's identity.
6. Compliance monitoring of active suppliers​
The contractual relationship does not end with the signature - active suppliers with technical access must be monitored continuously:
6.1 Compliance indicators to monitor​
| Indicator | Description |
|---|---|
| Compliance with the vulnerability remediation SLA | Time between notification and confirmed remediation |
| Delivery of contractual artefacts | SBOM, test reports, audit reports (where applicable) |
| Incident notification within the deadline | Compliance with the contractual notification deadline |
| Absence of security incidents attributed to the supplier | Record of occurrences |
6.2 Periodic reassessment​
| Level | Cadence | Scope |
|---|---|---|
| L1 | Annual | Review of clauses and basic compliance |
| L2 | Annual | Updated due diligence; verification of SLAs; analysis of incidents |
| L3 | Half-yearly | Complete technical due diligence; review of artefacts; verification of certifications; residual risk analysis |
The outcome of the reassessment must give rise to a documented decision:
- Continuation without changes: compliance maintained
- Continuation with an improvement plan: gaps identified with a resolution deadline
- Contractual penalty: SLA breach with financial impact (if provided for)
- Replacement: serious non-conformity or unacceptable risk
7. Secure offboarding​
The offboarding of a contractor or the termination of a contract with a supplier must be executed immediately and verifiably:
7.1 Offboarding checklist​
- Revocation of all access (systems, repositories, tools, VPN, service credentials)
- Removal of SSH keys, tokens, API keys and certificates issued in the name of the contractor/supplier
- Recovery of equipment or organisational assets provided to the contractor
- Confirmation of deletion or return of the organisation's data held by the supplier (where applicable)
- Deactivation of accounts in identity systems (IdP, Active Directory, etc.)
- Documented record of offboarding completion (timestamp, person responsible, status of each item)
7.2 Offboarding deadlines​
| Type of exit | Maximum deadline for access revocation |
|---|---|
| Planned exit (end of contract) | On the day of termination itself |
| Unplanned exit (immediate termination) | ≤ 2 hours after the decision |
| Termination for security reasons | Immediate - priority revocation before any other procedure |
warning
Keeping access active after the end of the contract is one of the most common causes of unauthorised residual access. The offboarding process must be automated as far as possible to avoid dependence on manual action under pressure or with information gaps.
8. Record and traceability​
For each supplier and contractor, the organisation must maintain an up-to-date record that includes:
| Artefact | Content | Retention |
|---|---|---|
| Due diligence outcome | Pre-contractual assessment, decision, conditions | Contract duration + 3 years |
| Contract with security clauses | Signed version with applicable clauses | Contract duration + 5 years |
| Onboarding record | Training track, quiz, initial permissions | Contract duration + 1 year |
| Reassessment records | Results of each periodic assessment cycle | Contract duration + 3 years |
| Offboarding record | Completed checklist, timestamp, person responsible | 5 years |
9. Responsibilities​
| Role | Responsibility |
|---|---|
| Procurement / Legal | Ensure that contracts include minimum security clauses; conduct negotiation with the reference template |
| GRC / Compliance | Keep the contract template up to date; conduct due diligence; audit compliance; periodic reassessments |
| AppSec Engineer | Define the technical security requirements to be included in contracts; assess technical artefacts (SBOM, reports); support technical due diligence |
| Security Champion | Carry out the technical onboarding of contractors; verify completion of training before access is assigned |
| DevOps / SRE | Carry out the technical revocation of access at offboarding; manage identities and permissions |
| HR | Coordinate the onboarding/offboarding process with the Security Champion; record completion in HR systems |
10. Annex — Specific clauses for AI service vendors​
When the supplier is an AI service vendor (Anthropic, OpenAI, Google, Mistral, Cohere, HuggingFace or an equivalent self-hosted option), the set of contractual clauses provided for in section 4 is extended with six specific clauses. They do not replace any of the preceding ones — they add discipline to the AI slice.
10.1 Data retention and training opt-out​
- The AI service vendor's retention policy made explicit: for how long submitted data is retained; in which systems; with what access controls.
- Training opt-out contractually agreed where applicable — preference for zero retention for sensitive data (PII, proprietary code, secrets potentially exposed in prompts).
- When the AI service vendor has training "opt-out by default", that guarantee is declared in the approval record (cross-link
DEP-014).
10.2 Processing location​
- Document where data is processed (region, data centre, jurisdiction).
- Compliance with GDPR Art. 44–49 when personal data is involved — Standard Contractual Clauses (SCCs), Adequacy Decision, or another valid mechanism.
- Specific clauses for international transfers when data leaves the EEA.
10.3 Audit rights​
- Contractual right to access inference logs or equivalent where required (typical at L3 and in regulated systems — DORA Art. 30(3)(e), AI Act, Article 26(6)).
- Alternatively, periodic audit reports (SOC 2 Type II, ISO/IEC 42001 certification, EU declaration of conformity under Art. 47 when the system supplied is high-risk, or Art. 53/Annex XII documentation when GPAI).
10.4 Prior notification SLA​
- Notification before changes that alter behaviour: major model version, data policy, discontinuation, change of location.
- Minimum expected SLA: ≥ 30 days for non-emergency changes; whatever is technically possible for emergencies.
- No adequate notification → triggers a proactive review and potential activation of the architectural fallback (Ch. 04 §AI/ML).
10.5 Availability SLA and fallback​
- Declared availability SLA; communication mechanism in the event of an outage.
- The system architecture provides for a fallback for when the AI service vendor is unavailable or returns degraded outputs (cross-link
ARC-014/ARC-015).
10.6 Declared regulatory compliance​
- AI Act Art. 53 (obligations for providers of general-purpose AI models): technical documentation of the model (paragraph 1, point (a)), information and documentation for downstream providers (point (b)), a policy to comply with Union law on copyright (point (c)) and a public summary of the content used for training (point (d)).
- AI Act Art. 55 (obligations of providers of general-purpose AI models with systemic risk): model evaluation with documented «adversarial testing» (paragraph 1, point (a)), assessment and mitigation of systemic risks (point (b)), tracking and reporting of serious incidents to the AI Office (point (c)) and cybersecurity protection of the model and its physical infrastructure (point (d)).
- GDPR, Art. 28 (processors): contract with the processor (paragraph 3) and prior information on the engagement or replacement of other processors (paragraph 2).
- NIS2 Art. 21 and DORA Art. 28–30: applicable to any ICT third-party service provider to a covered entity; reinforced contractual requirements when the service supports critical or important functions (DORA Article 30(3)).
10.7 Operationalisation​
- The AI service vendor enters the approved list
DEP-014only after validation of clauses 10.1 to 10.6 (proportional to the risk level). - Critical clauses recorded in the AI service vendor record; scheduled review of the AI service vendor clauses — an object distinct from the general supplier reassessment (section 6) — according to the risk level (L1 annual; L2 half-yearly; L3 quarterly).
- Complete operational detail in Policy 39 — AI BOM and Supply Chain and in Ch. 14 US "AI provider contracting".
| Clause | L1 | L2 | L3 |
|---|---|---|---|
| 10.1 Retention + opt-out | Recommended | Mandatory | Mandatory (zero retention for PII) |
| 10.2 Location | Recommended | Mandatory | Mandatory + SCCs/Adequacy |
| 10.3 Audit rights | — | Recommended | Mandatory |
| 10.4 Notification SLA | Recommended | Mandatory | Mandatory (≥30d) |
| 10.5 Availability SLA + fallback | Recommended | Mandatory | Mandatory |
| 10.6 Declared regulatory compliance | — | Applicable when relevant | Mandatory when GPAI or personal data |
11. Review and audit of this policy​
This policy must be reviewed annually or after any of the following events:
- A security incident involving a supplier or contractor
- A regulatory change that modifies due diligence or notification obligations (e.g. DORA, NIS2, GDPR)
- An audit result that identifies gaps in the contracting or offboarding process
12. Normative and technical references​
| Reference | Relevance |
|---|---|
| SbD-ToE Ch. 14 - Governance and Contracting | US-02: clauses; US-14: reassessment; US-15: contractor onboarding; US-17: offboarding; US-21 — AI provider contracting |
Organisational Traceability Policy (34_policy-rastreabilidade-organizacional.md) | Record and evidence of compliance |
Secrets Management Policy (18_policy-gestao-segredos.md) | Contractor credentials and revocation |
AI BOM Policy (39_policy-ai-bom-supply-chain.md) | Operationalisation of the AI service vendor lifecycle |
AI Agent Mandates Policy (38_policy-mandates-agentes.md) | When the AI service vendor supplies agents / runtimes |
| ISO/IEC 27001 - A.15 | Supplier relationships |
| ISO/IEC 27036 | Information security for supplier relationships |
| ISO/IEC 42001:2023 | AI Management System — relationships with AI suppliers |
| NIST SP 800-161 | Cybersecurity Supply Chain Risk Management |
| NIST AI RMF 1.0 — MAP-4.x | Third-party AI risk |
| GDPR - Art. 28, 44–49 | Processors; international transfers |
| DORA - Art. 28-30 | ICT third-party risk management |
| NIS2 - Art. 21 | Supply chain security measures |
| EU AI Act (Reg. (EU) 2024/1689) - Art. 25, 26, 47, 53, 55 | Responsibilities along the AI value chain (Article 25); obligations of deployers (Article 26); EU declaration of conformity (Article 47); obligations of providers of general-purpose AI models (Articles 53 and 55) |