Trust Centre

1.System status

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

A public status page showing live availability and incident history is Planned and will be published at status.safetyops.etechflow.com before the first merchant installs. Until then, service questions go to etechflow0@gmail.com.

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 Planned
• 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.

The system that enforces and logs that automatically — time-boxed grants, after-the-fact review and emergency-access logging — is specified and Planned. Until it is in place, access is controlled through infrastructure permissions and recorded manually.

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 Planned.

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 Planned.

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. No external AI provider is connected yet. The merchant setting to switch off external AI processing entirely for sensitive documents ships before any provider is enabled Planned.

8.Backups and recovery

Automated, encrypted backups kept separately from production are Planned, with initial recovery targets of 24 hours for both recovery point and recovery time. We intend to improve the recovery point objective as the platform matures.

Restores will be tested, not assumed. A recovery test checks that the audit history and attachments come back intact, not just that the database starts. The first restoration test runs before the app is made available to merchants Planned, and we will publish the date it was last carried out.

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. A public status page, an in-app emergency export procedure, support escalation and a post-incident timeline are Planned and ship before launch.

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.