A security platform usually holds personal data about your own staff: names and work emails from login, commit authors attached to findings, and records of who fixed or dismissed what. It is smaller in volume than customer data but still counts. Inventory it, minimise it, and tell your engineers.
Why developers' data counts
The GDPR defines personal data as any information relating to an identified or identifiable person, including a name, an identification number or an online identifier. An engineer's work email in a login record qualifies. So does a commit author name attached to a vulnerable line, or an audit entry showing who accepted a risk. Employees are data subjects like anyone else, and local employment rules may add duties. Check with your privacy lead.
Where it appears in a security platform
| Place | What it contains |
|---|---|
| Accounts and SSO | Name, email, role, group membership, login times |
| Findings | Author or committer of the affected code, assignee |
| Triage and exceptions | Who accepted risk, who suppressed, with timestamps |
| Audit logs | Actions per user, source address |
| Pull request integration | Author and reviewer identities |
| Support tickets | Names and emails of people who contacted the vendor |
| Metrics dashboards | Fix rates per person or team, if enabled |
The last row deserves caution. Per person dashboards can feel like surveillance and may collide with works council or employment rules in some places. Prefer team level metrics unless there is a reason and a policy.
Minimise what you send
The GDPR's data minimisation idea, personal data should be limited to what is necessary for the purposes, translates into concrete steps.
- Use SSO, with only the attributes needed. Name, email and groups. Skip phone numbers and anything else.
- Prefer team ownership. Assign findings to a team, not a person, where your workflow allows.
- Turn off per person scoring unless you have a clear need and a policy.
- Check support channels. Share the fewest personal details when raising tickets.
- Set retention for audit logs to a defined period.
Tell your engineers
Add a short note to your internal documentation: what the platform records about them, why, who sees it, and for how long. Engineers tend to accept logging that is explained, and distrust logging that is discovered. Do not use the tool's data for performance management unless you have said so and checked your rules.
Ask the vendor
- Which personal data fields do you store, and can we turn any off?
- Is commit author data stored in findings, or read from source control when displayed?
- Can we delete or anonymise a leaver's data on request?
- Is any of it used for the vendor's analytics or marketing?
- How do you support access and deletion requests from our staff?
For related guidance, see build a personal data map from schemas and code and is your security vendor a processor or a controller.
How Safeguard fits
Safeguard's free scan lets you see what a result contains. For the strictest cases, you can deploy it on-prem or air-gapped so staff data stays in your network.
Quick check
Is a commit author name really personal data?
Yes, if it identifies a person. Even a pseudonym can identify someone when combined with other information.
Can I use fix rates per developer?
You can, but think first. Team metrics usually answer the real question and carry less risk. Check employment rules and be open about it.
Sources
Last reviewed: 19 October 2026.
