Compliance Matrix
Goal: See what OpenX provides toward data-integrity requirements, and what it does not.
NOTE
No certification
Fathym holds no certification of any standard listed here, and OpenX does not make a workspace compliant with any standard on its own. This page names what the product provides toward those requirements. Whether a given workspace meets a requirement is for you and your auditor to decide.
The record: Provenance
OpenX keeps its record of changes in Provenance, set up in Environment -> Provenance with Save configuration (that Save builds the storage; it does not wait for Deploy). There is no separate audit log or amendment log node: the Provenance Log node, available once Provenance is provisioned, only forwards chosen Provenance records out to a data connection. See Activity Log.
What OpenX provides
| Feature | What it does |
|---|---|
| Storage in your cloud | Provenance records are kept in Azure Blob Storage in the Azure subscription your workspace is connected to, in containers kept apart per workspace and per scope |
| Tamper evidence | Each record carries a SHA-256 hash over the whole record, chained to the record before it. A verify call checks the whole chain, a segment, or one record, and reports where it broke |
| Append-only writes | A record is written only if its place in the chain is empty; it is never overwritten. The server sets each record's id and hashes, and refuses a caller who tries to |
| Attribution and time | Each record is stamped with the signed-in identity and the server's clock. An identity or time sent by the caller is not used |
| Immutability and holds | The storage gets a time-based Azure immutability policy, which can only be extended, and is locked in production. An open study scope is put under a legal hold until it closes |
| Retention | Retention periods of 7, 15 or 30 years, or 146,000 days (the Azure maximum, shown as Indefinite), set per kind of record. The configuration record must be kept at least as long as the records it governs |
| Signing | Signing a record names what the signature means. Sign in again to sign can require the person to sign in again once per signing session or for every signature; it is off by default |
| Corrections | A correction keeps the original, names a reason from a set list, and is a new record. When approval is turned on, the approver cannot be the person who made the correction - checked on the server |
| Access rights | Access rights decide what each member can change. Access, licence and connected-app changes need a management right; only an owner adds or removes members |
| Export | Provenance records export as CSV or JSON for a date range. A data connection's rows download for a time range as CSV or JSON Lines |
| Removal | Members can be removed. Records can be removed, choosing whether everything goes or only the configuration. Provenance itself is never deleted (retiring it is not built yet), and a workspace with locked Provenance cannot be archived |
What is recorded, and what is not
Recorded in Provenance, once it is provisioned:
- Saves that change simulators, data connections, surfaces, warm queries, schemas, agents, integrations, interfaces, Provenance Log nodes, Provenance or mail accounts, with the state before and after.
- Accepting a proposal, and undo and redo of an accept.
- Team membership, owner and access-card changes, in the workspace's AccessControl trail.
- Removals carried out by a Deploy, naming who staged, accepted and deployed each one.
- Corrections, approvals, rejections and signatures, and a refused sign-in at signing.
- Sends through Communications (a hash of the message and recipient counts, never the recipients' addresses, subject or body), and document writes through the table routes (a hash and ETag, never the document).
- Each run of the chain verify.
- Events you append through the Provenance API.
Each record names how its actor got in: as a team member, an app or a job.
NOTE
Not recorded today
Licence, cloud and data store set-up changes, warm query runs, calls from an AI over MCP, and data downloads are not written to Provenance. The record of a Save is written just after the Save completes; if that write fails, the Save still stands. Writes made straight at your own Azure resources never pass through OpenX.
ALCOA++ mapping
| Principle | What OpenX provides | Limits |
|---|---|---|
| Attributable | The signed-in identity on every record, correction, approval and signature | Only for what is recorded (above) |
| Legible | Structured records with the state before and after; reasons on corrections; CSV and JSON export | |
| Contemporaneous | The server's clock on every record | A Save's record is stamped just after the Save |
| Original | Append-only writes; a correction keeps the original; immutability policy on the storage | The policy is locked only in production |
| Accurate | SHA-256 chain with a verify call; sign-in again to sign | Sign-in at signing is off unless you turn it on |
| Complete | Recorded Saves of the tracked kinds; for data kinds, a Deploy records a removal before it tears it down | See "Not recorded today" |
| Consistent | One record format; the server sets each record's id and hashes | An appended event's action and entity type are free text |
| Enduring | Retention periods that can only be extended; legal holds on open scopes; the configuration record outlives the records it governs | |
| Available | Query, verify and export through the API; records in your own subscription | Export does not verify the chain; run verify for that |
| Traceable | Each record chained to the one before it; removals name who staged, accepted and deployed | |
| Transparent | The verify answer names its algorithm, range and any break; you can read the storage yourself |
Standards customers ask about
Fathym holds no certification for these; the features below are what the product provides toward them.
| Standard | Features that support it |
|---|---|
| 21 CFR Part 11 | Tamper evidence, attribution and time, retention, signing with sign-in again, access rights, corrections |
| EU Annex 11 | Tamper evidence, attribution and time, corrections with approval, retention, access rights, export |
| ICH Q7 | Attribution and time, corrections that keep the original, retention |
| GAMP 5 | Tamper evidence with a verify call, access rights, the record of configuration changes |
| ICH E6(R3) | Attribution and time, append-only writes, retention, legal holds on open study scopes |
| EU GMP Chapter 4 | The ALCOA++ mapping above |
| EU AI Act | Proposals a person accepts (by default), access rights, the record of configuration changes |
| EU Data Act | Export of Provenance records and of data connection rows; records in your own subscription |
| FDA CSA guidance | Tamper evidence with a verify call, and the record of configuration changes |
| SOC 2 | Access rights, the record of changes, storage in your own subscription |
| HIPAA | Access rights, the record of changes, member removal |
| GDPR | Export, member removal, document deletes through the table endpoints, the region you state for an additional data store account |
Your data stays yours
Provenance records sit in your own Azure subscription, and you can query and export them at any time through the API - not only when you leave. If you stop using OpenX, the storage and its records stay where they are.
Get started
- Give the workspace its private landing zone, then open Environment -> Provenance.
- Choose the retention periods and the signing setting, and click Save configuration.
- Optionally, drag a Provenance Log node onto the canvas to forward chosen records to a data connection.
For the record's API (query, verify, export), see Activity Log and the REST API. For validation questions, contact your Fathym account team.