Security and Incident Response

This page describes how EngraveSafe, operated by Clearstage Labs, protects the data it holds and what happens if something goes wrong. It is written to be checked: each item below names the specific mechanism behind it rather than a general assurance.

What data is at stake

EngraveSafe holds very little. For an order flagged as missing personalization it holds the order number and items, the customer's e-mail address, their name when Shopify provides it, and the details the customer types into the form. It does not hold addresses, phone numbers or any payment data. Everything else it stores is operational: which orders were checked, and when.

Encryption

• In transit: all traffic to the app is HTTPS. The connection from the app to its database requires TLS with full certificate verification against a pinned certificate authority, so the app refuses to start if it cannot verify the database it is talking to.
• At rest: the database is hosted on Supabase, which encrypts stored data with AES-256 and is SOC 2 Type 2 compliant.
• Shopify access tokens: encrypted a second time by the app itself, with AES-256-GCM, before they are written to the database. The key lives only in the hosting environment, never in the database or the source code, and the app refuses to start if the key is missing, invalid, or not the key that encrypted the stored tokens. A copy of the database on its own therefore does not yield a usable token.
• Backups: taken daily by Supabase and held in that same encrypted storage. Because access tokens are encrypted by the app before storage, they are ciphertext inside a backup as well.

Test and production data are separate

Staging and production are two different Shopify apps with different credentials, two different hosting projects and two different databases. They share no secrets, and deploying one cannot repoint the other. No real customer data is copied into the test environment; test data is generated.

Limiting access

• EngraveSafe has one operator and no other staff. Nobody else has an account on the hosting platform, the database, the Shopify Partner organization or the source repository, so there is no standing access to remove.
• Every one of those accounts is protected by two-factor authentication with an authenticator app, in addition to a password that is not reused anywhere else. A stolen password alone does not grant access to the hosting environment, the database, the Shopify Partner organization or the source repository.
• The application itself never exposes one store's data to another: every request is bound to the store it was authenticated for, and every database query is scoped by that store.
• Customer data is never copied out of the database for convenience — not into spreadsheets, local files, analytics tools or support tooling.

Access log

Every access to protected customer data is recorded: the merchant opening the dashboard, the merchant sending the form link, the customer opening or submitting their own form, and every deletion, whether it came from a Shopify privacy request or from the retention timer. The log records the store, who acted, what they did and how many records were involved. It deliberately contains no customer data itself — no e-mail address, no name, no form answer — because an audit trail that copied the data would simply be a second place to lose it from. Log entries are kept 365 days.

The log is reviewed monthly, and after any suspected incident. The review asks one question: does the pattern of access match what the app is supposed to do? Reads from merchants, form activity from customers, deletions only from compliance requests and the retention timer. Anything else is investigated before it is dismissed.

Retention and data loss prevention

• Personal data on a flagged order is deleted automatically 180 days after the order was flagged; see the Privacy Policy for exactly what goes and what remains. Data nobody holds cannot be lost.
• Shopify's privacy requests are not handled in the moment and forgotten: each one is recorded durably and completed by a worker that retries until it succeeds, so a crash or an outage cannot silently drop one. If a request is still open as its 30-day deadline approaches, or keeps failing, the operator is alerted.
• Error messages, logs and alerts are scrubbed of e-mail addresses and never contain tokens, keys or ciphertext, so diagnostics are not a side channel for the data they describe.
• Incoming Shopify webhooks are verified by HMAC signature before anything is read from them, and recorded so that a redelivery cannot be processed twice.
• Deletions and the record of them commit together as one transaction: a deletion that fails halfway leaves neither partial data nor a log entry claiming it succeeded.

Incident response

An incident is any event that may have exposed, altered or destroyed data EngraveSafe holds, or that may have given someone access they should not have. A suspected incident is treated as an incident until it is ruled out.

Severity

• S1 – confirmed exposure. Protected customer data, or a credential that grants access to it, is known to have reached someone unauthorized.
• S2 – possible exposure. A credential may have leaked, an unexplained access appears in the log, or a vulnerability that would allow either is found.
• S3 – no exposure. An availability or correctness problem with no data at risk: the app is down, or a job is failing.

Roles

With a single operator there is no escalation chain to maintain and no ambiguity about who responds: Clearstage Labs is the incident responder and the decision-maker, reachable at snakeeyes3407@gmail.com. The escalation path runs outward instead — to Shopify Partner Support, and to the hosting and database providers, whose own support and status channels are used when the cause may lie with them.

What happens, in order

• Contain first. For S1 or S2, revoke or rotate the credential involved, and if the app itself is the exposure, take it out of service rather than leave it serving. Containment is not delayed to finish investigating.
• Preserve evidence. Before changing anything further, capture the hosting logs, the relevant access log entries and the timeline of deploys and configuration changes, and keep them outside the affected system. Evidence is collected before remediation, because remediation destroys it.
• Determine scope. Using the access log and the database, establish which stores and which records were involved, and over what period. "We don't know" is recorded as such rather than guessed at.
• Notify. For a confirmed S1, notify Shopify through Partner Support and the affected merchants directly, without waiting for the investigation to be complete, and say plainly what is known, what is not yet known and what is being done. Merchants are told what their own customers need to be told. Where a data protection authority must be notified, that is done within the deadline that applies.
• Remediate and verify. Fix the cause, then confirm the fix with a test that would have caught the problem — a test, not an inspection — so the same failure cannot return unnoticed.
• Write it down. Record what happened, what was done and what changed as a result. Each incident either produces a change or an explicit decision not to make one.

Reporting a problem

If you believe you have found a vulnerability or a data problem in EngraveSafe, please write to snakeeyes3407@gmail.com with enough detail to reproduce it. Reports are acknowledged within three business days. Please do not access, modify or retain anyone else's data while investigating, and please give us a reasonable opportunity to fix the issue before describing it publicly.

Changes

We'll update this page if anything changes and note the date above.