GControl data processing annex

What this annex is

The Art. 28(3) specifics for hosted GPlatform Control. It is part of the data processing agreement, which carries the obligations.

Where you run GControl on your own infrastructure you are the controller and there is no processing on your behalf to agree — but we do receive the small upstream payload described in the privacy notice, for which we are the controller in our own right. The two are different relationships and it is worth keeping them apart.

Nature and purpose of the processing

Operating the control plane for your applications: holding their licences and entitlements, carrying their catalogue and releases, recording their health and usage, taking and tracking their backups, and keeping the audit trail of what was done to them.

Categories of data subjects

• Your administrators and operators — the people who hold accounts in the control plane and act in it.
• The end users of applications you run, only as counts. No end-user identity is processed here.
• People named in an audit entry as the actor of an action.

Categories of personal data

Account data for your people in the control plane: name, email address, role, session and recovery records.

Audit entries: who did what, when, the subject of the action, the reason given, and the hash chaining the row to the one before it.

Command records: which verb was asked for, by whom, with what reason, what your side decided, who consented, and the outcome.

Support session records: the scope and reason of a session, who requested and who approved it, when it expired, and whether a shell was approved and opened.

Operational measurements: health samples, meter buckets, seat and user counts, instance and application versions. These describe systems rather than people, with the exception of the counts, which are numbers and not identities.

What is not processed

The end users of your applications, their content, their identities. The readings behind a usage aggregate. Your backup contents. Any credential of yours.

Processing operations

Collection, storage, retrieval, use, restriction, erasure within the limits below, and backup. Containment actions — freeze, seal — where the terms allow, each recorded on both sides.

Sub-processors

Those named in the general agreement — IONOS SE and Contabo GmbH, both in Germany, plus our own hardware in Germany — and no others for this service.

Security measures particular to this service

• Instance authentication is a per-instance identifier plus a rotating bearer secret over TLS.
• The audit chain is hash-linked and anchored, so a rewrite is detectable.
• Lockdown keys are held per instance and never per org, so one exposure cannot unlock every customer, and the private material lives in Vault with only a path in the database.
• Key custody is registered, and the rule that the two halves of a dual signature never share custody is recorded so that it can be checked rather than assumed.
• Health values are filtered against the application's declared manifest keys before they are stored at all.
• Support access requires approval on your side, a shell requires a second and shorter approval, and expiry is enforced on your side so that a compromised control plane cannot extend it.

Retention

Health samples: 90 days. Meter buckets: kept as the usage and billing record. Instance, licence and entitlement records: for the term and afterwards as the record of it. Audit entries: for the integrity of the chain — see the limit below.

The limit on erasure

The audit chain is hash-linked, which is what makes it evidence, and individual rows are therefore not deletable in the ordinary way. Where erasure of an audit entry is required, we will discuss what is achievable — ordinarily redaction of a field rather than removal of a row.

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.