Security incident response policy
Who responds
The service is published by GRT Ventures OÜ, a company incorporated in Estonia. It is run by a single operator, the company's legal representative, who handles incident response from start to finish. That person can be reached at support@hidemydrop.com, repeated at the bottom of this page. There is no on-call team: this page describes what one person does, in what order and within what deadlines.
What the service calls an incident
A security incident is any event, confirmed or suspected, that leads to the destruction, loss, alteration or unauthorised disclosure of data processed by the service, or to unauthorised access to that data or to the accounts holding it. The following fall under that definition, without the list being exhaustive:
- unauthorised access to a merchant account, to the operator account or to the server;
- disclosure of an access token, an API key, a password or a backup;
- a flaw in the code or in a dependency that exposes order data to a third party;
- loss or alteration of data, including through a handling error;
- an incident at a sub-processor that affects data of the service.
Data concerned
On the merchant side, the service holds the contact e-mail address, the password in hashed form, the shop domain and shop name, the API keys, the Shopify access token, the subscribed plan with its usage data, and the sign-in history of the account. On the buyer side, for each order sent by the shop, it holds the e-mail address and name, the destination country code, the order number, amount and currency, the carrier tracking numbers and the masked tracking identifier, and the parcel's transport events. The service neither receives nor stores the buyer's postal address or phone number. The detail of each category and the retention periods are set out in the privacy policy.
Measures in place
The measures below exist in the code and on the server as of the date shown at the bottom of this page. They are described as they are, without certification or external audit.
- Transport: every host of the service, including the neutral domain of the tracking pages, is served over TLS.
- Shopify access token: encrypted in the database with AES-256-GCM, under a key kept outside the database. Without that key, the stored token cannot be read.
- Passwords: hashed with bcrypt, never kept in plain text, eight characters at least.
- Password reset tokens: only their digest is stored. The token itself is never written to the database.
- Sessions: signed cookie, out of reach of scripts, flagged Secure in production, expiring after seven days.
- Webhooks: every Shopify webhook (orders, fulfilments, uninstall, subscription, GDPR requests) is checked against its HMAC signature. A missing or wrong signature is rejected. Incoming webhooks in WooCommerce format require a signature computed with the merchant's API secret, and the outbound webhooks a merchant configures are signed with a secret specific to that integration.
- Merchant accounts: optional second factor (TOTP code or passkey), sign-in history the merchant can review in the account (date, authentication method, IP address, browser, success or failure), rotation of the API key and secret by the merchant, and a limit on sign-in attempts per IP address.
- Operator access: a single operator account. A TOTP code is required at every password sign-in once it is enabled; otherwise the account must hold a passkey, and the existence of one or the other is re-checked against the database on every back-office request. Viewing a merchant's record, activity feed, a ticket or an attachment, and every change the operator makes to that account (plan, limits, temporary password, TOTP reset, signing in as the merchant, cancelling a deletion), are recorded in the event log of the account concerned, with the operator's identity.
- Hosting: SQLite database on a Hetzner server located in the European Union.
- Backups: daily copy of the database on the server, with rotation. An encrypted backup is taken off the server three times a day with restic.
- Retention: a daily task purges the technical log after 180 days and the sign-in history after 365 days, and records each run in the worker's log, even when there is nothing to delete.
- GDPR requests forwarded by Shopify: the customers/data_request, customers/redact and shop/redact webhooks are received and handled after their signature is checked (order export, anonymisation, erasure of the shop's data).
- Minimisation: no phone number and no postal address, two read-only Shopify scopes (read_orders and read_fulfillments), and the real carrier tracking number is never shown to the buyer.
Detection and reporting
The service has no monitoring centre. Detection rests on four sources: the service's logs (technical log, account event log, sign-in history), the operator's regular reading of the back office, reports received at support@hidemydrop.com, and notices from the hosting provider, from Shopify or from a sub-processor.
Anyone, merchant, buyer or third party, who notices abnormal behaviour of the service or believes they have found a flaw can write to support@hidemydrop.com. The message can stay anonymous and it is read by the operator in person. The service pays no discovery bounty. It only asks that the flaw not be exploited and that the data it would expose not be circulated before it is fixed.
Qualification within 24 hours
A report or an anomaly is examined within 24 hours of its receipt. The examination answers four questions: is this an incident within the meaning of this page, which data and which accounts are affected, since when, and is the exposure still ongoing. An incident file is opened at that point, with a reference, the time the service became aware and the timeline of the known facts. A report that turns out to be unfounded is recorded all the same, with the reason.
Containment
Containment aims first to stop the exposure, even before its cause is understood. Depending on the case, the operator:
- revokes the API keys and tokens concerned, and replaces the session signing key, which signs every account out;
- replaces the server secrets: the encryption key of the Shopify tokens, the API secrets, the credentials and second factor of the operator account;
- switches off a feature, an integration or the whole service, if that is the only way to stop the leak;
- restores the database from the last sound backup when data has been altered or lost;
- sets aside the logs and the material needed for the analysis before any return to service.
Return to service follows the correction of the cause, then a check that the exposure has stopped.
Notification
Merchants. When an incident affects a merchant's data or that of their buyers, the merchant is informed at the e-mail address of their account no later than 72 hours after the service became aware of it, as provided in section 6 of the data processing agreement. The message describes the nature of the incident, the categories of data and of persons concerned, the likely consequences, the measures taken and those the merchant can take on their side. For the data of their buyers, the merchant is the data controller: notifying their supervisory authority and, where applicable, the buyers is their responsibility. The service provides them with the material needed.
Supervisory authority. For the data of which GRT Ventures OÜ is the controller, that is, the data of merchant accounts, the breach is notified to the competent supervisory authority, the Andmekaitse Inspektsioon, the Estonian data protection authority, within 72 hours of becoming aware of it, in accordance with Article 33 of the General Data Protection Regulation, unless the breach is unlikely to result in a risk to the persons concerned. If the notification cannot be complete within that period, it is made in phases. Where a high risk exists for the persons, they are informed directly, in accordance with Article 34 of the same regulation.
Shopify. When data obtained through Shopify is concerned (shop data, order data or access token), Shopify is informed of any breach, actual or suspected, within 24 hours of the service becoming aware of it, through a report to Shopify Support (partner contact form), as required by section 6.2.10 of the Shopify API terms of use.
Post-mortem and incident file
Once the incident is closed, the operator writes a report: timeline, cause, data and accounts affected, containment measures, notifications made, corrections applied to the code or to operations, and what would have allowed earlier detection. That report joins the incident file.
The file is kept by GRT Ventures OÜ, as required by Article 33(5) of the regulation, which asks for every breach, its effects and the measures taken to be documented. It is made available to the supervisory authority and, for what concerns them, to the merchant.
Certifications and availability
The service holds no security certification and commits to no numerical availability rate. The measures described here are the ones that exist. Their list evolves with the code, and the date at the bottom of this page indicates the state described.
Changes
This page may evolve with the service. The date of the last update is shown at the bottom.