Trust Centre

1.System status

Supplement SafetyOps is pre-launch. It is not yet available to merchants, and no production merchant data is held.

Our status page is published and carries the outage procedure, recovery targets and incident history.

Because a reporting deadline keeps running during an outage, the status page is a control, not a courtesy - see section 8.

2.How data flows

Where consumer safety information goes, and where it deliberately does not:

1. In - a consumer submits the branded intake form, emails the merchant's support address (forwarded to a unique per-merchant address), or a staff member enters a phone or social-media report by hand.
2. Preserved - the original message is stored unchanged. Everything later is a separate layer: a structured extraction, then a human-reviewed version. The original is never edited.
3. Enriched - where the merchant has connected Shopify, we read the related order and product using read-only scopes. We do not read postal addresses.
4. Assessed - a trained person at the merchant reviews it. Software calculates deadlines and flags possible serious outcomes; it decides nothing.
5. Out, only on the merchant's instruction - an investigation package to a named manufacturer under a scoped, time-limited, redacted and audited grant; or a submission dossier the merchant downloads and files themselves through the FDA's own portal.
6. Retained - six years, versioned, with an append-only audit trail.

A diagrammed version of this flow for security reviewers is Planned.

3.Encryption

• In transit - TLS 1.2 or higher on all connections, including between our own internal services
• At rest - strong encryption on the database and file storage
• Files - encrypted, with no publicly reachable file URLs
• Backups - encrypted, with keys held separately from the backups themselves
• Secrets - never in source code or config files. Migration to a managed secrets service with scheduled rotation Planned

4.Who can see what

Inside a merchant's account

There are ten roles: intake agent, customer-support manager, qualified reviewer, safety reviewer, QC approver, regulatory approver, submission operator, executive escalation, read-only auditor, and system administrator.

Consumer contact details are visible only to roles that actually need them. Bulk export needs its own permission, is logged, and raises an alert. Permission checks happen on the server - never by just hiding buttons.

Separation of duties is configurable, because a three-person brand cannot staff ten roles. Where one person does two steps, the audit trail shows it plainly. Shared accounts cannot apply an electronic signature.

Our own staff

By default, none of our staff can see merchant data. Our policy is that access needs a named business reason, an approval and an end date, and is removed immediately when someone changes role or leaves.

That is enforced and logged automatically. A grant is time-boxed to a maximum of 24 hours, cannot be granted to yourself, requires a written reason, raises an alert rather than a quiet log line, counts every use, and is reviewed afterwards by somebody other than the person who held it. Ending a grant takes effect immediately.

Development and test environments contain only synthetic or sanitised data - real customer data never goes into them. That one is in force today.

5.Keeping merchants separate

Every record carries a tenant identifier - cases, attachments, products, users, audit records, reports, exports and API requests.

The only sanctioned way data crosses between organisations is an explicit case grant - for example a brand sharing an investigation package with its manufacturer. Those grants are limited to named records, time-limited, revocable, redacted according to a profile, and audited.

6.Logging and alerts

Every access to consumer contact data is logged with who, what, when, which role, what changed, why, and whether it was a person or an automated process. The append-only audit trail and its hash chain are built and tested; connecting the last of the application screens to it is .

We will monitor and alert on failed logins, unusual export activity, bulk downloads, permission changes, emergency access, and attempted deletion of a regulated record. An attempted deletion is already recorded as an audit event; the alerting layer is .

7.How we handle AI

AI helps staff by reading an unstructured message and suggesting structured fields, and by flagging text that may describe a serious event so it gets reviewed sooner. Every output is a proposal shown to a person.

The pattern we enforce: the model proposes, a deterministic authorisation service checks role, case status, approvals, completeness, scope and tenant, a person explicitly confirms, and only then does the system act.

AI never directly holds the ability to send email, disable products, issue refunds, delete customers, submit to a regulator, dispose of inventory, publish anything, start recall communication, or change permissions.

Incoming emails and documents are treated as untrusted. Their content is evidence, never instructions - a malicious attachment cannot tell the system what to do.

Identifying details are removed before text is sent to an AI provider, and that redaction step is built. Before using any provider we check whether data is used for training, how long it is kept, where it is held, and what the contract says. Our current AI provider is Google (Gemini API). It receives redacted text: email addresses, telephone numbers, links and our own case references are removed before anything is sent. Names are deliberately not removed. A complaint often needs “the consumer’s mother” or a clinician’s name to be intelligible, and stripping them produces a garbled extraction that a reviewer then has to correct - which makes the final regulated record less accurate, not more. A merchant who is not comfortable with that can switch external AI off entirely, and it is off by default for documents marked sensitive - and it returns suggestions that a person accepts or rejects. It makes no regulatory determination. The merchant setting to switch off external AI processing entirely for sensitive documents is live.

8.Backups and recovery

Backups run nightly, encrypted with AES-256 before they touch disk, with the encryption key held separately from the backups themselves. Recovery targets are 24 hours for both recovery point and recovery time, and we intend to improve the recovery point objective as the platform matures. Backups are retained for 90 days, matching our Retention Policy.

Restores are tested, not assumed. A restoration test runs weekly and automatically. It restores the most recent backup into a throwaway database and then checks that the schema, the tenant-isolation policies, the audit history and its hash chain, and the attachment records all came back intact - not merely that the database starts. A test that only proved the database starts would prove nothing worth knowing.

If we are down and your deadline is not

A merchant's reporting deadline keeps running even if our system is unavailable. Our offline submission checklist exists today as SOP-010 in the SOP pack, and every merchant receives it. Our status page sets out what to do during an outage. The compliance archive is downloadable in the app at any time, and is emailed as a secure expiring link automatically if the app is uninstalled. Affected merchants receive an incident timeline they can place on their own records.

9.Incident response

We have a documented incident response policy with four severity levels, named roles, and defined escalation.

We preserve evidence before fixing anything, because remediation usually destroys what is needed to work out the scope and notify accurately.

Notification: affected merchants without undue delay once scope is known, and within 24 hours of confirmation for a SEV-1. Regulators where required and within the statutory deadline. Merchants are the controller of consumer data, so we equip them to notify consumers rather than doing it ourselves.

Every incident gets a blameless review within five business days, with tracked actions.

10.Subprocessors

These are the outside services we use. Each is assessed before we engage them and bound by data protection terms.

This list is kept current. We will update this page before engaging any new subprocessor, and merchants can subscribe to notifications of changes by contacting etechflow0@gmail.com.

Data is processed in the United States, on Oracle Cloud Infrastructure in Ashburn, Virginia. The database, files, backups and application stay in the US region wherever possible.

11.Testing and vulnerability disclosure

We scan dependencies and containers automatically, and patch on a severity-based schedule.

An independent penetration test has not been carried out yet. One is planned, and this page will be updated with the result and remediation status when it has happened. We will not claim an independent test has taken place before it has.

Report a suspected vulnerability to etechflow0@gmail.com. We will acknowledge it and keep you updated.

12.Shared responsibility

Some things are ours to get right. Some are yours.

13.Limits of FDA and external data

Where we show information drawn from public FDA sources - such as recall or adverse-event databases - it is context only. It is never a determination about your product, and it never drives a decision in the app.

• Public FDA datasets are incomplete, lag real events, and are not verified case by case.
• An entry in a public database does not establish that a product caused an event.
• The absence of an entry does not establish that nothing happened.
• We do not transmit reports to FDA, and we hold no FDA portal credentials.

Every externally sourced item is shown with its source, the date it was retrieved, and a statement that it is contextual. Your own case record is always the authoritative one.

14.Compliance roadmap

What we are working towards, in order, and what is honestly not done yet.

This table is updated as items move. If something you need is not on it, ask.