A data processing addendum for a security tool should state what is processed and why, bind the vendor to your instructions, set security and confidentiality duties, control sub-processors, cover deletion at exit, and allow audits. GDPR Article 28 lists the minimum terms. This is general information, not legal advice. Have counsel review the final text.
What Article 28 requires in the contract
The article says processing by a processor is governed by a contract that sets out the subject matter and duration, nature and purpose, type of personal data, categories of data subjects, and the controller's obligations and rights. It then lists what the processor must do. In plain words:
- Process personal data only on documented instructions, including for transfers outside the EU, unless the law requires otherwise.
- Make sure staff handling the data are bound by confidentiality.
- Take the security measures required by Article 32.
- Respect the conditions for engaging sub-processors.
- Help the controller respond to requests from individuals.
- Help the controller with security, breach and impact assessment duties.
- At the controller's choice, delete or return all personal data at the end of services, and delete copies unless law requires storage.
- Provide information needed to show compliance and allow audits.
Checklist for a security tool
| Section | Security tool specifics to include |
|---|---|
| Subject and purpose | Scanning, findings, account management. Nothing more. |
| Data and people | Developer names, work emails, commit authors, admin users |
| Instructions | Your settings control processing. No use for the vendor's own products unless agreed |
| Security | Encryption, access control, logging described, and kept at least as strong over time |
| Sub-processors | List, purpose, region, notice period, right to object |
| Transfers | Where data is stored and accessed, and what transfer mechanism applies |
| Incidents | Fixed hours for notice, content and cooperation, see breach notification terms |
| Individual requests | How the vendor passes on and supports requests |
| Exit | Export window, deletion timeline, written confirmation |
| Audit | Reports, questionnaires, remote review, for cause inspection |
Items specific to this category
Add terms that go beyond personal data, since findings and code are confidential even when no person is named.
- Confidentiality of findings. Treat vulnerability data and code excerpts as your confidential information.
- Data use limits. No training of models, benchmarking or product analytics on your data without a written opt in. See data use clauses.
- Credential handling. How access tokens are stored, rotated and revoked.
- Retention schedule. Periods per data class, see how long should a platform keep your scan results.
Read it against the main agreement
A frequent trap is a main agreement or terms page that grants the vendor wider rights than the addendum. Check which document wins in a conflict, and read both for data use. Also check that the addendum is signed and attached, not just referenced by a link that can change.
How Safeguard fits
For teams that want fewer parties handling data, Safeguard supports private VPC, on-prem and air-gapped deployment. The free scan is available for a first look.
Quick check
Do I need an addendum if I send no personal data?
A security platform almost always holds some, such as user emails. Even if not, confidentiality and data use terms still matter for findings and code.
Is the vendor's template addendum acceptable?
Often it is a fair start. Review it against the checklist and ask for changes on exit, notice and sub-processors.
Sources
Last reviewed: 19 October 2026.
