What Precision has built — and what it has not.

1. Read this first

Precision is a pre-1.0 product in closed beta. It holds no certifications and no external assurance reports. Rather than leave a procurement questionnaire to infer that from silence, here is the explicit list.

The written data-protection pack behind section 6 — processor agreement template, sub-processor register, retention statement, breach-notification commitment and residency statement — is an engineering draft. It has not been reviewed by a qualified data-protection adviser and must not be relied on in a contract until it has been.

2. How to read the tables

Every control table below carries the same statuses used in Precision's internal clause-by-clause mapping. They are reproduced here unflattened, because the difference between them is the whole point of the page.

Shipped

Built and in the product today.

Verified

Shipped and covered by a passing test or an external audit finding. No row on this page carries this status, because no external audit has taken place.

In progress

Partly built. Each row names what is still missing.

Planned

Not built. A roadmap item, not a capability. Do not score it as one.

N/A

Outside Precision's scope — the control belongs to the customer or to another system.

Repealed

The provision itself is no longer in force. The row is kept because vendor questionnaires still cite it by name, not because it is an obligation Precision should be scored against.

Where a row is more limited than its heading suggests, the limitation is written into the row rather than left for a follow-up call.

3. Controls shipped today

The short version, before the clause tables. Each of these is in the product now; the sections that follow say which clauses they answer and which they do not.

4. DORA — the lighthouse regulation

Regulation (EU) 2022/2554 on digital operational resilience for the financial sector, in force 17 January 2025. DORA leads Precision's mapping for three reasons: it is the broadest current EU regime covering ICT change management in financial services; its Article 28 makes Precision itself a regulated ICT third-party provider the moment it is sold into a financial entity, which forces exit, sub-processor and incident obligations onto the product rather than only onto the contract; and alignment with it largely subsumes the EBA ICT guidelines, BaFin BAIT and FINMA Circular 2023/1.

That is the deliberate difference from vendors whose published mappings target product-security and US-federal frameworks. Precision's frame is change management under European financial supervision.

Article 8 — Identification

Article 9 — Protection and prevention

Article 10 — Detection

ICT change management

This is the table the product exists for, and the one where the distinction between shipped and planned matters most.

Article 28 — Precision as an ICT third-party provider

These are obligations on Precision as a vendor rather than features of the product, and they are the weakest part of the posture today.

5. EBA guidelines, BaFin BAIT and FINMA 2023/1

All three land on the same control: a documented, approved, risk-assessed change process applied to ICT systems. Precision's answer to each is the DORA change-management table in section 4 — the same shipped controls, the same gaps. No separate clause-level mapping is maintained for them, because DORA's is stricter and subsumes them.

Two of the three rows below are no longer live obligations for a DORA-scoped buyer. The EBA provision has been deleted outright, and BAIT excludes institutions that run ICT risk management under DORA. Both are kept because vendor questionnaires still ask for them by name, but the live requirement in each case is DORA's, mapped in section 4. Details under the table.

One point in Precision's favour that is easy to miss: BAIT carves itself out for exactly this buyer. Its preamble (Rundschreiben 10/2017 (BA), Fassung 16.12.2024, Tz. 1) states that the circular's scope follows AT 2.1 MaRisk, and that from 17 January 2025 institutions that must operate ICT risk management under Art. 5–15 or Art. 16 of DORA are excluded from it. That is an exclusion from the circular's scope, not a repeal: BAIT has no expiry clause, and Tz. 3 preserves MaRisk alongside it. For an institution that must run ICT risk management under those DORA articles, BAIT does not apply from 17 January 2025 and the corresponding obligations sit in DORA instead, so section 4 is the whole answer. The row above is kept for institutions outside that carve-out and for reviewers whose questionnaire still asks.

6. GDPR and Swiss nFADP

Regulation (EU) 2016/679 and the Swiss Federal Act on Data Protection (nFADP, SR 235.1, in force 1 September 2023) apply to every customer, independent of financial supervision.

Who is who. Precision is sold as an instance per customer. The customer is the controller for everything inside their instance — their users, projects, releases, attachments and activity log. Precision is the processor for that data, acting on the customer's documented instructions. Separately, Precision is the controller for its own public website and mailing list. The full statement is the privacy notice.

7. NIS2

Directive (EU) 2022/2555. Precision maintains no clause-level NIS2 mapping, and presenting one would be an overclaim. What exists is a set of supply-chain and logging practices that answer the kind of question a NIS2-scoped buyer asks of a supplier:

• Build supply chain. New npm package versions are quarantined for 72 hours before they can enter a build, and package install scripts are disabled outright. Shipped
• Patch cadence. Demonstrated rather than promised: three high-severity transitive advisories in one framework were resolved and released in under a day. Shipped
• Logging and traceability. The tamper-evident activity log in section 3. Shipped
• Vendor security posture statement and incident-notification SLA. Neither exists. This is a known roadmap item and the honest answer to a NIS2 supplier questionnaire today is "not yet". Planned

8. ISO/IEC 27001:2022

Precision is not ISO 27001 certified and holds no Statement of Applicability. The organisational Annex A controls — governance, HR, supplier management — belong to an operating organisation's ISMS, and no such organisation has been incorporated. What can honestly be mapped is the subset of Annex A that the product implements.

9. SOC 2, PCI-DSS and SOX ITGC

Secondary frameworks that appear on questionnaires even when they are not the buyer's primary regime.

SOC 2

No SOC 2 report exists. Type II is a stated intention alongside the product build, not an achieved state, and no audit period has been observed. The product-side criteria that would be in scope are logical access controls, user authorisation before access, authentication, system monitoring, and change management — all of which are the same controls mapped in sections 4 and 8, with the same shipped/planned split. The one criterion answered by a shipped control is system monitoring and anomaly detection, via the hash-chained activity log.

PCI-DSS v4.0

In scope only when a customer's own system handles cardholder data. Precision itself processes no cardholder data.

Requirement 6.5.1 is the one that maps: changes to all system components in the production environment are made according to established procedures. It carries six bullets, and Precision answers them unevenly — two are partly answered, three are roadmap items, and one is outside what the product does at all:

1. Reason for, and description of, the change. Partly answered: release-level sign-off requires the signer to state a reason, and the hash-chained activity log records the change. In progress
2. Documentation of security impact. Risk classification of changes is a roadmap item. Planned
3. Documented change approval by authorized parties. Partly answered: the signing permission is held separately from the planning permission, and the signature record names the signer and the time. Per-event approval and MFA step-up at signing are roadmap items. In progress
4. Testing to verify that the change does not adversely impact system security. Evidence linkage per sign-off is a roadmap item. Planned
5. For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production. Precision does not test software changes for secure-coding compliance and does not gate a release on such a test. This is a control over the customer's own build and review pipeline, not something Precision provides or enforces. N/A
6. Procedures to address failures and return to a secure state. Precision records a release and its rollout events but has no rollback or failure-handling workflow. Planned

Requirement 6.5.2 — upon completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks, and documentation is updated as applicable — is the one requirement outside 6.5.1 that Precision partly supports. Confirming a set of requirements after a change is what a release checklist is, and keeping the record updated is what a release record is. Precision supplies neither the PCI requirement list nor any verification that the confirmation is truthful: the customer defines the checklist and the evidence. In progress

Requirements 6.5.3 (pre-production environments separated from production, enforced with access controls) and 6.5.4 (roles and functions separated between production and pre-production to provide accountability such that only reviewed and approved changes are deployed) are controls over the customer's own environments. Precision neither provides nor enforces them, and claiming them as roadmap items would misrepresent what the product is for. N/A

SOX ITGC

Relevant to customers with US-listed parents. The change-management control area — authorised, tested, documented, segregated changes — is answered by the DORA table. The logical-access area is answered by federated SSO and per-project roles; periodic access review has no dedicated UI and is a planned item.

10. Annex 11 and GAMP 5 — the pharma horizon

EU GMP Annex 11 and GAMP 5 are an adjacent, horizon market for Precision, not its primary target. Nothing here is offered as a validated-system claim, and Precision has not been validated for GMP use by anyone. Three Annex 11 clauses are nevertheless in reach of controls that already exist, because the DORA-driven design happens to run alongside them — one fully, one only in part, one not at all:

• § 14 — electronic signatures. The clause asks for three things: that the signature have the same impact as a handwritten signature within the company, that it be permanently linked to the respective record, and that it carry the time and date of signing. Precision ships the third outright, and answers the second evidentially rather than preventively: a deterministic hash over the release's signable state binds the signature to what was signed, but the signed record stays editable and nothing in the product recomputes or flags drift — the link proves what was signed, it does not hold the record still (see the note in section 4). The first item is not a product property at all; it is the customer's to establish in their own quality system. A note on what is not an Annex 11 § 14 requirement: the sign-off also requires the signer to state what the signing means. That is a signature manifestation under 21 CFR Part 11 § 11.50, and Part 11 is explicitly out of Precision's scope — it is a capability, not a clause answered here. In progress
• § 9 — audit trails. The append-only, hash-chained activity log, plus the per-release evidence packet an auditor can verify offline. Shipped
• Periodic review of audit trails. There is no workflow for an accountable role to record that a periodic log review happened. The log is reviewable; the attestation that it was reviewed is not a product feature. Planned
• GAMP 5 supplier documentation package — user requirements, functional and configuration specifications, risk assessment, supplier audit support. None of it exists. It would be produced on a horizon buyer's demand, and IQ/OQ/PQ remains the customer's. Planned

11. Where the data sits

The honest answers, in the order a vendor-risk reviewer asks them.

12. Sub-processors

Five third parties are involved in delivering Precision. The full register — data categories, legal entity, location and contract status per provider — forms an annex to the processor agreement and is available with it.

One further browser-side disclosure that is not a sub-processor, stated here because a reviewer will ask and because a customer who does not want it should hear about it before rollout rather than after. Once a user is signed in, the authenticated application renders their profile picture straight from the URL their identity provider supplied at sign-in. The user's browser therefore discloses its IP address and user agent to that provider's avatar host on every page load — the same disclosure class as the webfont entry above. The identity provider is the customer's own choice and does not process data on Precision's behalf, which is why it is not in the table; the disclosure is real regardless.

Three US-incorporated companies are in that list — Hetzner and Bunny Fonts are both EU-incorporated (Germany and Slovenia respectively). Corporate location is a distinct question from data location, and both matter: a US parent may be subject to US legal process regardless of where bytes sit. Checked against the official Data Privacy Framework list on 16 September 2026:

Changes to the register carry a proposed 30-day advance notification commitment. The channel for that notification is not yet defined.

13. Using this page in a vendor security questionnaire

This page is public, needs no login, and has a stable address at https://precisionrelease.org/compliance. It is written to be cited directly in a questionnaire response, and the section anchors are stable enough to link to.

The documents behind it — the processor agreement template with its technical-and-organisational-measures annex, the sub-processor register, the retention statement, the breach-notification commitment and the residency statement — are maintained alongside the product's source and are available on request. They are engineering drafts pending data-protection review; treat them as disclosure of the current position, not as warranties.

There is no dedicated business enquiries address yet, because no legal entity has been incorporated to own one. The contact named in the privacy notice, section 1.2, is an individual standing in ahead of that — route questions there, or through the contact you already have with the project.

This page is versioned with the product. It is updated in the same change that alters a control it describes, which is also why every row above names its limits rather than its aspirations.