GAdvisory data processing annex

What this annex is

The Art. 28(3) specifics for hosted GPlatform Advisory. 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.

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.

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 Contabo GmbH, both in Germany, plus our own hardware in Germany — 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 of a signed-in user where there is one. Stored in the EU.

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.

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 safeguards in its data processing terms.

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

Two 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.

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.

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.

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.

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. 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.