Skip to content
Gelhaus Solutions

GAdvisory data processing annex

The Art. 28(3) specifics for hosted GAdvisory: what it processes, about whom, who else touches it, and the two things publication makes permanent.

Version 2026-10-20, in force since 20 October 2026Auf Deutsch lesen →
This applies alongside the general terms of service and privacy policy. Where they differ on a point about GAdvisory specifically, this page wins.

What this annex is

The Art. 28(3) specifics for hosted GAdvisory. It is part of the data processing agreement, which carries the obligations; this page carries only what is particular to this service.

It applies where we run the instance. For an instance you run yourself you are the controller alone and there is nothing here to agree.

Nature and purpose of the processing

Operating a coordinated vulnerability disclosure service on your behalf: receiving disclosure reports addressed to you, storing them and their correspondence, letting your people work on them, reserving and publishing identifiers, and publishing the advisories you decide to publish.

Categories of data subjects

  • Your own people: the users you create in your organisation and its projects.
  • Security researchers and other reporters, whether or not they hold an account. A report can arrive by email or web form from somebody who never registers.
  • People named inside a report, which is free text and may name anyone: an affected customer, a colleague, a third party.
  • People credited in an advisory.
  • Subscribers to advisory notifications.

Categories of personal data

Account data. Email address, handle, display name, locale, timezone, country code, optional avatar and biography, optional Git username and email for record signing, email verification time, last sign-in.

Disclosure requests. Subject and body, form answers, file attachments, and either a linked account or a submitter name and email. Where a report arrives by email, the message headers travel with it: sender, recipients, addresses in copy, and the identifiers that thread a conversation. The raw inbound payload is retained beside the parsed version until 12 months after the report was triaged.

Participants on a thread. Email address and display name, for account holders and non-account holders alike.

Credits. The name and contact a researcher asked to be credited with. Published.

Subscriptions. An email address, confirmed by double opt-in, carrying an unsubscribe token.

Browser push. Where enabled: the push endpoint, its two keys, and the user agent string.

Audit log. Who did what, when, values before and after, IP address and user agent.

Share-link use. A hashed IP address, not the address. The question a share link answers is whether it was used from more than one place, not where somebody is.

AI runs, where enabled. Prompts and responses, retained so a proposal can be audited, pruned on a schedule.

Sign-in data. Held by our own identity service (Hexclave) and not by GAdvisory: password hash, second factors, passkeys, linked accounts and sessions. GAdvisory holds the user identifier Hexclave issues and, for accounts migrated from before, an older password hash.

Other personal data. A linked GitHub account (login, name, avatar address), the GitHub login and invitation state of external collaborators on a private fix, GitHub logins of commenters synced in, guest sessions with a hashed IP address and user agent, request-form drafts (contact email, IP address), the mail log (sender and recipient addresses, 24 months), notification channel targets, and the committer name and email of a Git sync.

AI assistant connections. The assistant's registered name and redirect addresses, the consent and scopes, hashed access and refresh tokens, and audit entries for grants, refreshes and revocations.

Private fixes (Advisory Patch). The repository with the upstream history and the fix, pull requests, reviews, comments and viewed-file marks, collaborators and the state of their invitations, and the credentials for landing a fix (encrypted; only who set the secret and when is displayed).

Special categories

None is asked for and none is intended. A disclosure report is free text and an attachment can be any file, so material falling under Art. 9 can arrive without either of us intending it. You decide what to do with a report once it has; we do not read your queue.

Processing operations

Collection, storage, organisation, retrieval, use, disclosure to the participants on a thread, publication where you publish, restriction, erasure within the limits below, and backup.

Sub-processors

Those named in the general agreement (IONOS SE and our own hardware, both in Germany, and Cloudflare for DNS only) and, for this service only:

  • Sentry (Functional Software, Inc.), on its EU data region: error and performance reporting. It receives exceptions and stack traces, the request that failed, and the identifier and handle of a signed-in user where there is one. A replay of a browser session, unmasked and showing the page as it was, including what was typed into it, goes to Sentry only where that person has said yes, and never from the pages of a private fix repository. No IP addresses or request bodies. Stored in the EU. Functional Software, Inc. is in the United States and certified under the EU-U.S. Data Privacy Framework.

Mail runs on our own servers at IONOS and file storage is our own MinIO, so neither is a third party.

  • OpenRouter, Inc. (United States), routing to Google Gemini: the AI features, which are enabled on the hosted service. Google LLC, to which it routes, is certified under the EU-U.S. Data Privacy Framework.

They are restricted to the Gelhaus Solutions team as the people who may run them, not restricted in what they may read: within the scopes Gelhaus Solutions and Postiz own that reaches disclosure reports, queues and disputes, and for an administrator it is effectively the instance.

This does not extend to your scope. We do not run AI tasks over a customer's scope, and the AI configuration for your scope is yours. Where you enable it, the key is yours and the provider is whichever your key belongs to.

Because OpenRouter is in the United States, this is a transfer to a third country and rests on the European Commission's standard contractual clauses in OpenRouter's data processing agreement, which is part of its terms of service.

  • GitHub, Inc. (United States, certified under the EU-U.S. Data Privacy Framework): only where private fixes are used in GitHub mode. It stores the private copy of the repository and the invitations to it, in the GitHub organisation we keep for private fixes. Where you have a private fix made in a GitHub organisation of your own instead, GitHub holds that copy under your own terms with GitHub and is not our sub-processor for it.

Sign-in is handled by Hexclave, run by us on our own servers, so it is not a third party.

No analytics service, no advertising network, no third-party fonts or scripts.

Three transfers that are not sub-processing

Browser push, where a user enables it, is delivered by the push service that user's own browser nominates (Google, Mozilla or Apple), which are outside the EU. The endpoint and the timing reach that service; the payload is encrypted to the browser's keys, so the content does not. There is no way to deliver a web push otherwise.

AI assistants. Where a person connects an AI assistant, what it reads goes to the provider that runs it, under that person's own agreement with the provider. The person decides, within their own permissions; it is not processing on your behalf. Embargoed material is for them to keep out of reach of an assistant unless the embargo allows it.

Publication. Where you publish an advisory to GitHub Security Advisories or through the CVE Program, or sync records into a Git repository you configured, the advisory and any credit in it goes to those parties: GitHub, Inc. and the CVE Program, both in the United States. They are recipients acting for their own purposes, on your instruction to publish, and not processors acting on ours. Publication is a disclosure you decide on, per advisory, and it cannot be undone once it has been mirrored onward. GitHub is certified under the EU-U.S. Data Privacy Framework.

Security measures particular to this service

Beyond the measures in the general agreement:

  • API tokens, OAuth client secrets and application secrets are stored only as hashes.
  • Integration secrets are envelope-encrypted, and an instance can be configured to hold them in HashiCorp Vault.
  • Share-link use records a hashed IP rather than an address.
  • The audit log is hash-chained: each row carries a hash of the one before it, so the log can be shown not to have been edited after the fact.
  • Embargo participation is explicit and recorded, with an acceptance per participant.
  • An AI assistant acts only with the permissions of the person who connected it, and its tokens are short-lived (an hour) with a refresh token that lapses after 90 days unused.
  • A lockdown can restrict sign-in and API access in stages, for everyone, as a precaution; decoy accounts and keys that no real person uses refuse and report any attempt.

Retention, and two real limits on erasure

Account data is kept until the account is deleted. Disclosure requests and their correspondence are kept while coordination is open and afterwards as the record of how it was handled. Subscription addresses go on unsubscribe. AI assistant connections end when revoked or 90 days after last use. Private fix repositories go 30 days after the advisory is published unless set otherwise. The mail log and audit entries go after 24 months.

Two things cannot be undone by deleting them, and both follow from the design rather than from unwillingness:

The audit log is tamper-evident. Its rows are chained, which is what makes the log evidence. Individual entries are therefore not deletable in the ordinary way. The log is shortened as a whole instead: entries go after 24 months, and the hash the remaining log starts from is recorded at each deletion. Where erasure of an audit entry is required, we will discuss what can be done, usually redaction of a field rather than removal of a row.

Publication is permanent. A published advisory, and any credit in it, is mirrored into databases we have no relationship with. We will remove a credit from our copy on request. We cannot remove it from anybody else's. This is the honest scope of Art. 17 here, and it is why credit is asked for as consent in the first place.

On termination

As set out in the general agreement: return or deletion at your choice, 30 days of export availability by default, backups expiring on their own cycle.

Advisories you published stay published, for the reason above.

Versions of this document
2026-10-20 in force since 20 October 2026
2026-10-03.3 in force 3 October 2026 to 20 October 2026
2026-10-03.2 in force 3 October 2026 to 3 October 2026
2026-10-03 in force 3 October 2026 to 3 October 2026
2026-10-01 in force 1 October 2026 to 3 October 2026
2026-09-06 in force 6 September 2026 to 1 October 2026