What Precision processes, why, and what you can do about it.

1. Who is responsible

Precision is delivered as a dedicated instance per customer — a separate deployment on a separate subdomain. Responsibility therefore splits in two.

1.1 Your employer is the controller for data inside a Precision instance

If you use Precision because your organisation gave you an account, your organisation is the controller of the data in that instance. They decided to use Precision, they decide who gets an account, what is recorded on a release, and how long the activity log is kept. Precision acts as their processor under GDPR Art. 28 / nFADP Art. 9, on their documented instructions.

Direct your access, correction and deletion requests to your organisation first. If you send one to Precision, we forward it to the controller and assist them under Art. 28(3)(e); we do not answer it on our own authority, because we are not entitled to.

1.2 Precision is the controller for its own website and mailing list

For the public website at precisionrelease.org and for the marketing / waiting-list mailing list, the controller is Sebastian Michaelsen, Bannstrasse 4, 6312 Steinhausen, Switzerland, reachable at sebastian@michaelsen.io.

No Swiss representative under nFADP Art. 14 is needed: that provision is for controllers domiciled abroad, and this controller is already domiciled in Switzerland.

2. What personal data is processed

2.1 Inside a Precision instance

On free text and attachments: Precision does not require personal data in these fields, but it cannot prevent it. What ends up there is determined by the controller's own usage policy, not by the product. Controllers should instruct their users accordingly; special-category data (GDPR Art. 9) has no place in a release record.

2.2 Error reports

Deployed instances report unhandled exceptions to GitLab Integrated Error Tracking. The payload carries the authenticated user's numeric ID only — no name and no email address — alongside the stack trace, release tag and server name. Retention there is 90 days.

2.3 On this public website

The public site is served from a Cloudflare Worker. It carries no analytics, no tracking scripts and no cookies. What any web server sees remains: the IP address, request URL, timestamp, user agent and referrer reaching Cloudflare's edge.

There is one third-party embed, and only one: the bot challenge in front of the waiting-list form (challenges.cloudflare.com). Its widget script and iframe load from that host, so your browser discloses its IP address and user agent to it, and when you submit the form your IP address is sent with the challenge token to be verified. The host is Cloudflare, which already serves this page — no further party is involved — but the embed is real and we would rather name it than let "no third-party embeds" stand.

2.4 Webfonts

Both this website and the authenticated application UI serve their webfonts from their own origin. No font CDN is involved and no third party learns your IP address from a font request.

3. Purposes and legal bases

3.1 Instance data — the controller's determination

For data inside a Precision instance the legal basis is the customer's to determine, not Precision's. In practice it is one of GDPR Art. 6(1)(b) (performance of the employment or service relationship), Art. 6(1)(c) (a legal obligation — DORA, FINMA Circular 2023/1 and BaFin BAIT all require documented, attributable change authorisation), or Art. 6(1)(f) (legitimate interest in operating and auditing ICT change management). Under Swiss law the corresponding frame is nFADP Art. 30/31: processing by a private person is lawful unless it unlawfully breaches the data subject's personality, with consent, an overriding private or public interest, or a statutory basis as grounds of justification.

Precision itself processes that data on a single basis: the controller's documented instructions under GDPR Art. 28(3)(a) / nFADP Art. 9.

3.2 Precision's own processing, as controller

4. Who receives the data

Personal data is disclosed to the sub-processors listed on the compliance posture page. Precision does not sell personal data, does not use it to train models, and does not disclose it for any purpose other than delivering the service — except where disclosure is legally compelled, in which case the commitments in the processor agreement apply.

Two further disclosures are not sub-processing but do reach third parties, and are listed here rather than left out. The first is the identity provider's avatar host: once a user is signed in, the application renders their profile picture from the URL their identity provider supplied at sign-in, so their browser discloses its IP address and user agent to that host on every page load. The identity provider is the customer's own choice and does not process data on Precision's behalf, but the disclosure happens. The second is the set of channels a customer configures for themselves, below.

Personal data may leave an instance through channels the customer themselves configures: a digest email to project members — the project's current members, resolved live at send time, with no snapshotted recipient list — a signed webhook POST to a URL the customer supplies, or a Discord incoming webhook. Two properties of the webhook channel belong in this notice. With the recent-activity section enabled, the payload carries the name of each acting user — directly identifying personal data, not the pseudonymous identifier used for error reports. Because of that, Precision requires https on that hop: an http:// destination is refused when the channel is added, and a channel configured before that rule existed stops delivering rather than continuing in cleartext. There is no exception for loopback or private-network addresses. A redirect from the destination is refused rather than followed, so the receiver cannot downgrade that hop or move the delivery to a host the customer never configured. The signature on the POST authenticates the sender; the encryption is TLS's doing, and neither keeps the data in region. Section 11 of the compliance posture page sets out where these deliveries go and what they carry.

The recipient of such a delivery is chosen by the controller, not by Precision, and Precision is not in a position to assess it. Controllers should treat each configured channel as an onward disclosure they are responsible for — the required transport encryption protects the hop, not the choice of who is at the end of it.

5. How long data is kept

Retention is set out per category in the retention statement that accompanies the processor agreement. The two headline points:

• The activity log retention window is operator-configurable. Its default is to never prune — an instance keeps its full audit history until the operator sets a positive window.
• Sign-off records are append-only. Withdrawing a sign-off does not delete the signature event; it flips the release status back and records the withdrawal. This is a deliberate audit property and it constrains what erasure can mean for that record — see section 6.

6. Your rights

Under the GDPR you have the right to:

Under the nFADP the corresponding rights are the right of access (Art. 25), the right to data portability (Art. 28), and the right to have incorrect personal data corrected (Art. 32(1)). Deletion of the data, and prohibition of a particular processing activity or disclosure, are claimed under Art. 32(2), which routes them through the personality-protection actions of the Civil Code rather than granting them as a direct statutory right — see 6.2.

6.1 Limits on erasure that you should know about

Two records in Precision are deliberately not erasable on request by the instance operator alone:

• The activity log is application-immutable. No code path updates or deletes a row; deletion happens only through the operator's retention window.
• Sign-off signature events are append-only and carry a printed-name snapshot. The database also refuses to delete the release they belong to and the user account of their signer, so a signer's account cannot be deleted while their sign-off exists.

Both exist because a regulated buyer's supervisor requires an attributable, tamper-evident record of who authorised a production change. An erasure request touching them is handled under GDPR Art. 17(3)(b) (processing necessary for compliance with a legal obligation) or Art. 17(3)(e) (establishment, exercise or defence of legal claims), as assessed by the controller — not waved away.

6.2 Complaining to a supervisory authority

Germany / EU. Under GDPR Art. 77(1) you may lodge a complaint with the supervisory authority of the EU member state of your habitual residence, your place of work, or the place of the alleged infringement. In Germany the competent authority is the data protection authority of the relevant federal state (Landesdatenschutzbehörde); the Federal Commissioner (BfDI) is competent only for federal public bodies and for telecommunications and postal providers. The BfDI publishes the list of state authorities at www.bfdi.bund.de.

No single lead authority applies here. The one-stop-shop mechanism (GDPR Art. 56) is for controllers with an establishment in the EU; the controller named in section 1.2 has none. Each data subject instead uses the individual complaint route in Art. 77(1) above — the authority of their own habitual residence, place of work, or the place of the alleged infringement.

Switzerland. The supervisory authority is the Federal Data Protection and Information Commissioner (FDPIC / EDÖB), www.edoeb.admin.ch. Note the difference from the EU regime: the FDPIC does not adjudicate individual complaints. It opens investigations on a report or of its own accord under nFADP Art. 49 and can issue orders under Art. 51. Individual data-subject claims are enforced through the civil courts under nFADP Art. 32(2).

7. Marketing and the waiting list

The waiting-list form on this site collects one field: your email address. Nothing else is required and nothing else is inferred. Signing up is a double opt-in: submitting the form sends a confirmation link, and your address is only added to the list once you click through on that link.

8. International transfers

Some recipients in the sub-processor register are established outside the EEA and outside Switzerland — today that means US-incorporated companies.

• Transfers out of the EEA require a legal basis under GDPR Chapter V: an adequacy decision (Art. 45) or appropriate safeguards such as the Standard Contractual Clauses (Art. 46(2)(c)).
• Transfers out of Switzerland require that the destination state affords adequate protection — the list is in Annex 1 to the Swiss Data Protection Ordinance (SR 235.11) — or appropriate safeguards under nFADP Art. 16, with the narrow exceptions in Art. 17.
• Between the EEA and Switzerland, transfers are straightforward in both directions: Switzerland is recognised by the European Commission as providing an adequate level of protection under GDPR Art. 45, and the EEA states appear in Annex 1 to the Swiss ordinance.

Checked against the official Data Privacy Framework list on 16 September 2026: Cloudflare, Inc. and GitLab Inc. are both certified under the EU-U.S. DPF, the UK Extension, and the Swiss-U.S. DPF, covering EEA, UK and Swiss transfers. Resend is certified under the EU-U.S. DPF and the UK Extension only; its DPA separately incorporates the EU Standard Contractual Clauses, which cover the EEA leg independently of DPF status. The full breakdown, with participant-record links, is in section 12 of the compliance posture page.

9. Automated decision-making

Precision performs no automated decision-making producing legal or similarly significant effects within the meaning of GDPR Art. 22 or nFADP Art. 21. Every release decision the product records — planning, sign-off, completion — is taken by a named human and attributed to them.

Precision does expose an MCP server so that a user's own AI assistant can read and change release and project state through their credentials. Those actions are recorded in the activity log with the channel marked as MCP, and are attributed to the calling agent — the name it declares for itself, which Precision records as a self-declaration rather than a verified identity — to the tool it called, and to the personal access token it used, alongside the person that token belongs to. Everyone with access to the project sees that attribution, the token's name included, and auditors see it in the release evidence packet. The screen where a token is created says so, and suggests naming a token after its purpose rather than a device, a place or a person. Precision records no prompts, conversation content or agent reasoning. The AI assistant is the user's own tool and is not operated by Precision; whatever the assistant reads is disclosed to whichever AI provider the user has chosen.

10. Security

The technical and organisational measures are maintained in the annex to the processor agreement. In summary: transport encryption, encrypted session cookies, no password storage at all (authentication is federated to the customer's identity provider), per-project role-based access control, a tamper-evident audit log, and a dedicated database per customer instance.

What is not in place is set out plainly on the compliance posture page — no certification, no external audit, no penetration test, and no documented backup or restore procedure.

11. Changes to this notice

This notice is versioned in the Precision repository alongside the code it describes. Material changes are communicated to customers under the notification terms of the processor agreement and, for the mailing list, by email to subscribers before the change takes effect.