Privacy Policy
MolTrace processes account data, project metadata, spectral files, analysis outputs, usage logs, support communications, billing metadata, and audit events to provide the platform, secure customer workspaces, improve reliability, and support regulatory review.
Data we collect
Section titled “Data we collect”- Account and organization information
- Uploaded spectral files and raw FID archives
- Analysis results, reports, approvals, and audit trail events
- Usage, diagnostics, support, and security logs
- Billing and subscription metadata handled by payment processors
How data is used
Section titled “How data is used”Data is used to operate MolTrace, process analyses, generate reports, enforce security controls, provide support, maintain auditability, and improve product reliability. Customer data must not be used for model training unless the customer has explicitly opted in through an approved data-use agreement.
Cookies and local storage
Section titled “Cookies and local storage”MolTrace is built to minimize browser-side tracking. We do not use advertising or cross-site tracking cookies, and we do not sell personal data.
- Strictly necessary (always on). The signed-in application stores your authentication tokens and a client identifier in your browser’s
localStorageto keep you securely signed in, and a small first-party cookie remembers interface preferences (such as the sidebar state). These are essential to operate the product and cannot be switched off. - Analytics. The public website (
moltrace.co) uses Vercel Web Analytics, a privacy-friendly, cookieless measurement tool. It records aggregate page-view and performance metrics without setting cookies, without cross-site tracking, and without building advertising profiles of individual visitors.
Because MolTrace sets no non-essential cookies, no cookie-consent banner is required; this section is provided for transparency. If we introduce any optional analytics or marketing technologies in the future, we will add a consent mechanism and update this policy first.
Retention
Section titled “Retention”Retention depends on workspace settings, customer contracts, GxP obligations, and applicable law. Default questionnaire values for legal review are:
| Record type | Draft retention position |
|---|---|
| Analytical files and generated reports | 7 years unless a customer contract requires a different validated retention period. |
| Audit logs | Indefinite retention for regulated workspaces unless legal counsel approves a shorter period. |
| Account and support records | Retain while the account is active, then delete or archive according to the contract. |
Data residency
Section titled “Data residency”MolTrace runs as a single-region deployment with no tenant region pinning. Every tenant is served from the same production region; you cannot today contract for your workspace to be stored or processed in a region of your choosing, and no EU-pinned deployment is available. The production backend, managed database, and object storage all run in Google Cloud us-central1 — see Deployment & Hosting → Platform hosting (Google Cloud) for the infrastructure detail and Compliance → Trust Center for the sub-processor register.
Region pinning is a roadmap item, not a shipped option. The internal residency note enumerates the four things region pinning would require, each with an honest per-item status, so a residency question gets a straight answer instead of an implied capability. If your organisation has a residency requirement, raise it before contracting — nothing here should be read as a commitment to store or process data outside the single production region.
Processing is US-based, so any transfer of personal data out of the EEA or UK will depend on the transfer mechanism agreed in the data processing agreement (standard contractual clauses where required). The DPA template and sub-processor list are pending legal approval — see Compliance → Certifications and assurance. (v0.62.0, 2026-06-26)
Rights and contact
Section titled “Rights and contact”Customers may request access, correction, export, deletion, portability, or restriction where applicable. Privacy requests should route to privacy@moltrace.com.
Data-subject requests and the right to erasure
Section titled “Data-subject requests and the right to erasure”These are controls designed to support the customer’s GDPR obligations as controller; they are not a compliance certification, and MolTrace holds none.
For customer workspace data MolTrace acts as a processor and the customer is the controller. Under Art. 28(3)(e) MolTrace assists; it does not decide. The controller verifies the requester’s identity, decides the scope of the request, applies the Art. 15(4) balancing where third-party rights are engaged, and issues the response to the data subject. MolTrace supplies the discovery and the plan behind that response.
The supporting tooling is a planner library used by MolTrace personnel — not a product feature. It has no API endpoint and no user-facing surface, and it is run on documented controller instruction. It provides three things:
- Access report (Art. 15 discovery). Enumerates every store holding data about the subject — including stores that cannot be exported or erased — plus the facts only the processor is in a position to know: sub-processor recipients, retention windows, where the data came from, and the automated-decision position.
- Erasure plan (Art. 17). A per-store disposition for the request, store by store.
- Response deadline (Art. 12(3)). One month, with the two-month extension available only if the subject is notified, with reasons, inside the first month.
Execution of deletions is deliberately not automated. Nothing is destroyed because a plan says so; deletions are carried out on documented controller instruction.
What the personal-data map covers
Section titled “What the personal-data map covers”The classification map behind the planner covers every personal-data store group in the map (15 today) and is unit-tested. Each store carries one of four honest dispositions:
| Disposition | What it means for the data subject |
|---|---|
| Erase | The data is destroyed. |
| Pseudonymise + restrict | Identifiers are replaced or hashed and the record is retained under restricted processing. Reported as retained and restricted — never as erased. |
| Retain (legal obligation, Art. 17(3)) | Destruction is refused because retention is required by law or by a records obligation the controller is subject to. |
| Immutable ledger | The record sits in the tamper-evident audit chain and cannot be rewritten — see below. |
A legal hold suspends destruction everywhere, and never downgrades the immutable-ledger disposition.
Pseudonymisation is not erasure
Section titled “Pseudonymisation is not erasure”Under Recital 26 a tokenised or hashed record is still personal data. A store whose disposition is pseudonymise is therefore reported as retained and restricted, never as erased. This is an invariant enforced in tests, not a drafting convention.
The same honesty applies to the existing ALCOA+ soft-delete: archiving a controlled record retains the row and is reversible by design (see Compliance → ALCOA+ hardening for controlled records), so it is reported as retained and restricted, not as deleted.
What cannot be erased today
Section titled “What cannot be erased today”The audit chain’s canonical payload covers the identity fields. Rewriting those fields to erase a subject would break the chain — an erasure-by-rewrite is indistinguishable from tampering — and would undercut the 21 CFR Part 11 §11.10(e) retention expectation the chain exists to support. Stated plainly, and worth telling your DPO up front: identity cannot be erased from the immutable audit ledger today.
The enabling change is crypto-shredding — hashing ciphertext and destroying the per-subject key. It is documented as a seam with four preconditions, not claimed as a capability, and it is not implemented. Do not plan around it as though it were available.
One store is genuinely different: security_events has no hash chain over it, so its identity columns are safely pseudonymisable and are mapped that way. (v0.62.0, 2026-06-26)
Policy generator questionnaire
Section titled “Policy generator questionnaire”Use these structured answers when generating the production Privacy Policy, then send the output to counsel before publishing.
| Question | Draft answer |
|---|---|
| Product type | SaaS / cloud software for scientific analysis and regulated documentation support. |
| Personal data | Email, name, organization, role, support communications, usage logs, billing metadata. |
| Customer data | Spectral files, raw FID archives, project metadata, reports, approvals, and audit events. |
| Processors | See the sub-processor register in Compliance → Trust Center — that register is the single source of truth. |
| Hosting regions | Google Cloud us-central1 (United States), single region. No tenant region pinning; no EU-pinned deployment is available. See Data residency. |
| Cookies and tracking | No advertising or cross-site tracking cookies; cookieless Vercel Web Analytics on the marketing site; localStorage auth tokens + a functional UI-preference cookie in the app (strictly necessary). No consent banner required. |
| Regulatory regimes | GDPR, UK GDPR, and CCPA/CPRA where applicable. Add other regimes as operations expand. |
| User rights | Access, rectification, erasure, portability, restriction, objection where applicable, and complaint routes. |
Legal review gate
Section titled “Legal review gate”This page is live as the customer-facing policy location, but final production language must be approved by legal counsel before paid onboarding.