Do you need a DPA for a code scanner or SCA tool?

Often yes, if you are subject to GDPR, even though a code scanner is not a customer data tool. Source code, commit history, test data and scan logs routinely contain names and email addresses. If the vendor processes that on your behalf, Article 28 expects a binding contract. Ask for the DPA rather than argue the point.

What personal data a scanner can see

Personal data under GDPR is any information relating to an identified or identifiable person. In a scanning workflow that can include:

• Author names and email addresses in commit metadata.
• Comments with names, tickets with customer details, or contact addresses in documentation.
• Test fixtures and sample databases copied from production.
• Secrets scanners can surface values that sit next to personal data, such as a database dump committed by mistake.
• User account data for your own staff who sign in to the tool: names, emails, sign in logs.

None of this is unusual. It is the normal content of a repository.

The decision in three questions

1. Does the tool receive or store anything that could identify a person? Commit metadata alone is enough to say yes in many setups.
2. Does the vendor process it on your instructions, for your purposes? If so, you are the controller and they are a processor. If the vendor decides its own purposes for the data, the roles are different and you need legal advice.
3. Are you in scope of GDPR or a similar law? If you have EU or UK people's data, or staff there, assume yes and confirm with counsel.

If the answers are yes, yes, yes, sign a DPA before the pilot touches real data.

Reducing what the tool sees

You can lower the exposure without avoiding the tool:

• Scan a pilot repository that holds no production data.
• Choose a mode where analysis runs in your environment if the vendor offers it, and check what metadata still leaves.
• Exclude fixture directories and data folders.
• Limit scope to named repositories using a read only app or token.

None of these replaces a DPA if personal data still reaches the vendor, but they make the contract conversation simpler.

What to look for in the DPA

Check subprocessor notice and objection rights, breach notice timing, deletion or return at the end, audit and information rights, and where data is stored. The processor must notify the controller without undue delay after becoming aware of a personal data breach under Article 33(2), and a good DPA gives that a number of hours or days so you can meet your own clock. Our DPA clause guide explains where each piece lives.

If you are not sure

Ask counsel. This post is general information, not legal advice. Free tools you try on public repositories, such as the scan at gold.safeguard.sh/scan, do not involve your private data in the same way, but you should still check the terms before pointing any tool at private code.

Sources

• GDPR Article 4, Definitions
• GDPR Article 28, Processor
• GDPR Article 33, Notification of a personal data breach

Try it yourself

Open the dependency inventory and look at which fields come from your repository, because those are what the vendor would hold.

Click through it at your own pace, or open it full screen.

Quick check

Last reviewed: 19 October 2026.