Security Contractual Clauses
🌟 Objective
To provide a set of reusable contractual clauses proportional to risk, adaptable to the type of contracting, to ensure that security requirements are formally demanded, traceable and auditable.
These clauses must:
- Reflect the minimum requirements by risk (Chapter 1 and 2);
- Be applicable to different types of contract: SaaS, outsourcing, licensing or mixed teams;
- Be valid throughout the whole contractual lifecycle, and not only in the initial phase;
- Provide for mechanisms of validation, penalty and objective accountability.
📘 What security contractual clauses are
They are formal provisions incorporated into contracts with suppliers, partners or contractors, which aim to guarantee compliance with technical, legal and organisational security requirements, including:
- Application of minimum controls;
- Incident notification;
- Delivery of evidence (e.g. SBOM, tests, reports);
- Vulnerability and update management;
- Accountability for failures or breaches.
📎 These clauses are essential to transfer security obligations and to align the supplier with the principles of the SbD-ToE.
The use of automated technical processes or mechanisms to support compliance with these clauses neither alters nor reduces the supplier's contractual responsibilities. The supplier remains fully responsible for the compliance, evidence and results obtained, regardless of the degree of automation used.
🛠️ How to apply
🧩 By type of contract
🏷️ SaaS / Managed services
| Theme | Suggested clause |
|---|---|
| Minimum security | The supplier guarantees compliance with the controls defined according to the risk level of the application. |
| Vulnerabilities | Commitment to remediate critical CVEs in <72h after public disclosure. |
| SBOM / transparency | Provision of an up-to-date SBOM with critical dependencies, upon request. |
| Incidents | Notification of security incidents without undue delay and, at the latest, 24h after becoming aware. |
| Audit / evidence | Right of the organisation to request evidence of controls or to carry out formal audits. |
🛠️ Development outsourcing
| Theme | Suggested clause |
|---|---|
| Requirements by risk | Application of the requirements of the SbD-ToE Catalogue according to the risk level of the application. |
| Integration into CI/CD | Delivered artefacts must integrate pipelines with automated security tests. |
| Security reviews | Acceptance of code and architecture reviews by the organisation's security team. |
| Intellectual property | Source code and security documentation are the property of the contracting organisation. |
👥 Internal development (contractors or mixed teams)
| Theme | Suggested clause |
|---|---|
| Restricted access | Access only to development environments, with temporary and traceable credentials. |
| Training in SbD | Mandatory training in Security by Design practices before technical contribution. |
| Responsibilities | Application of the assigned security requirements via documented tickets. |
| Traceability | Complete record of the work linked to security tasks and validations. |
💽 Licensing contracts (external software)
| Theme | Suggested clause |
|---|---|
| Compliance | Compliance with recognised standards (e.g. ISO 27001, OWASP ASVS). |
| CVEs and updates | Obligation to communicate and mitigate critical vulnerabilities promptly. |
| Security updates | Right of the organisation to corrective updates during the contract. |
| Data and telemetry | Transparency and explicit consent for the collection of data or metrics. |
📊 Additional clauses per risk level
| Risk Level | Recommended additional clauses |
|---|---|
| L1 (low) | Generic commitment to good practices; incident notification policy |
| L2 (medium) | Application of the SbD-ToE Catalogue; provision of technical evidence on request |
| L3 (high) | Mandatory security tests; SBOM delivered; SLA for critical fixes; formal right to audit |
📘 Use the requirements application matrix (Ch. 1 - Annex 06) as the basis for deciding the contractual level required.
📋 Recommended fields per clause
Each clause must include:
- Reference to the applicable requirement (e.g. LOG-002, ARC-005);
- Indication of the risk level (L1–L3);
- Expected form of validation (technical evidence, audit, tests);
- Penalties or contractual impact in the event of breach;
- Review periodicity (e.g. at renewals, new versions or releases).
- Identification of the technical processes or mechanisms used to support compliance with the clause, where applicable.
📂 Integration with procurement and legal
- Make clauses available in a modular format (blocks by type and by risk);
- Maintain a repository of validated versions (e.g. Git, Confluence, SharePoint);
- Integrate into the supplier onboarding model (see
03-modelo-validacao-fornecedores.md); - Ensure basic training of stakeholders in the link between risk and contractual requirement.
✅ Good practices
- Prefer objective, auditable and risk-proportional clauses;
- Avoid vague or generic language without validation criteria;
- Align clauses with real security requirements (Ch. 2 and 7);
- Reassess clauses periodically, especially at renewals or technical changes;
- Record the clauses actually applied to each contract.
🔗 Cross-references
| Document / Chapter | Relationship with contractual clauses |
|---|---|
| Chapter 01 - Risk Management | Defines proportionality per level L1–L3 |
| Chapter 02 - Security Requirements | Catalogue and applicable requirements by risk |
| addon/03-modelo-validacao-fornecedores.md | Contractual onboarding requirements |
| addon/00-catalogo-requisitos.md | GOV-006/GOV-007: contractual acceptance criteria |