Security and incident response

We call a security incident any event that affects the confidentiality, the integrity or the availability of the data we hold. This covers in particular:

• Unauthorised access: someone views data they are not entitled to see — a compromised account, a stolen access key, an exploited flaw.
• Loss of data: data becomes unrecoverable, through accidental deletion or technical failure.
• Alteration: data is modified without authorisation, or in an uncontrolled way.
• Disclosure: data is made visible to people who should not have seen it.

This applies to the data of the merchants who use LIORA as much as to the data of their own customers, which the application accesses in order to work.

An interruption of service that makes no data inaccessible, and that neither exposes nor alters it, is a matter for support and not for this policy. A failure that lastingly prevents access to your data, on the other hand, does affect its availability: it is dealt with here.

This distinction governs everything that follows, and in particular who must notify the supervisory authority.

• Your account and billing data: Hugo BILLAUX EI is the controller of that data. The notification obligations fall to it.
• The data of your store’s customers: Hugo BILLAUX EI acts on your behalf, as a processor. You remain the controller of that data, and it is for you to notify the supervisory authority where a breach requires it. Our role is to alert you and to assist you.

Write to direction@liora-eu.com, describing what you have observed and, if possible, how to reproduce it. This mailbox is read in person by the sole trader who operates LIORA.

We acknowledge receipt no later than the working day after your message arrives. That commitment covers the acknowledgement, not the resolution: how long a fix takes depends on the nature of the incident, and we do not set in advance a deadline we could not meet.

If you are a security researcher, you may report a vulnerability to us at the same address. We do not run a bug bounty programme, and we will not bring proceedings against anyone who reports a flaw to us in good faith without having exploited it beyond what was necessary to demonstrate it. This undertaking binds Hugo BILLAUX EI alone and cannot stand in the way of criminal proceedings brought by the public authorities.

The assessment is made by the sole trader who operates LIORA, who is also responsible for the technical side of the service. There is no on-call team: that is a consequence of our size, and we prefer to write it down rather than let anyone believe in an organisation that does not exist.

We begin the assessment as soon as we become aware of the report and carry it out as quickly as the incident allows. We set no deadline: it depends on what there is to examine. Three criteria guide it:

• The nature of the data affected: account data, billing data, the data of a merchant’s customers.
• The extent: one account, several, or the whole service.
• The risk to individuals: what someone could do with the data concerned — identity theft, unsolicited approaches, financial harm.

Each incident is classified at one of three severity levels, which determine the priority given to the fix:

• Level 1 — critical: a confirmed or strongly suspected personal data breach, the compromise of an administrative access or of a secret, or harm to store data obtained through Shopify. Immediate containment, all other work suspended, and notifications within the time limits set out below.
• Level 2 — high: an exploitable flaw with no sign of exploitation, or a failure that lastingly prevents access to data. Priority fix, and a search for any sign of exploitation, which would move the incident up to level 1.
• Level 3 — moderate: an event with no harm to data — a blocked attempt, a configuration fault with no exposure, a theoretical vulnerability. Scheduled fix.

The level assigned is raised as soon as the facts require it. Notifications depend not on the level but on the facts: a mere suspicion affecting data obtained through Shopify is enough for Shopify to be notified, whatever the level.

As soon as an incident is confirmed, and before any search for its cause, we seek to stop it:

• Revoking compromised access: closing the sessions concerned, disabling the accounts involved.
• Rotating secrets: renewing the access keys and tokens that may have been exposed, including the credentials we hold with our technical providers.

Remediation follows, once the bleeding has been stopped:

• Fix: the cause is identified, corrected, then deployed.
• Verification: we replay the incident scenario to check that it no longer works.

Cutting off compromised access always takes precedence over continuity of service: if we have to shut down a feature in order to stop a leak, we shut it down.

As soon as an incident is suspected, and before any fix that might erase them, we preserve the items that make it possible to establish the facts: logs, timestamps, and the files and messages involved. They are used only to analyse the incident and to respond to the authorities, and are not kept for longer than the incident remains in the register.

Where the breach concerns data for which Hugo BILLAUX EI is the controller — account, billing — we notify it to the CNIL, the French data protection authority, no later than 72 hours after becoming aware of it, unless it is unlikely to result in a risk to the rights and freedoms of the data subjects (Article 33 of the GDPR). If not all the information is available within that time, we notify what we know and complete it afterwards.

Where the breach concerns the data of a merchant’s customers, we inform that merchant without undue delay, in accordance with Article 33(2) of the GDPR. It is then for the merchant, as the controller, to decide whether to notify the supervisory authority. Our message states the nature of the breach, the categories of data affected, the likely consequences and the measures already taken, so that the merchant can reach that decision.

Where the breach is likely to result in a high risk to the data subjects, they are informed of it (Article 34 of the GDPR). For account data, that communication falls to us. For a merchant’s customers, it falls to the merchant, who alone is the controller and alone has the relationship with them: we provide the merchant with the information required (Article 28(3)(f)).

Where the incident affects, or may affect, store data obtained through Shopify, we notify Shopify within 24 hours of becoming aware of it, as soon as there is a mere suspicion and without waiting for the assessment to be completed, as its API terms of use require.

We do not make any public announcement about an incident until the flaw has been fixed, so as not to show others how to exploit it. That reserve delays neither the notification to the authority, nor the information given to merchants, to the data subjects or to Shopify.

Every incident is recorded in an internal register, including where it gives rise to no notification. The register states the date of discovery, the facts, the data concerned, the assessment made, the measures taken and, where applicable, the notifications sent — to the authority, to merchants, to the data subjects and to Shopify — with their dates.

This register is kept under Article 33(5) of the GDPR, which requires every breach to be documented so that the supervisory authority can verify compliance with those obligations. It is produced to the authority on request.

Once the incident is closed, we look for what made it possible, not for who is responsible. The question is always the same: what allowed this to happen, and what will stop it happening again?

The remediation therefore does not stop at the defect itself: where possible, we add an automated check that fails if the defect reappears, so that the same cause cannot produce the same incident twice.

These are the measures that protect your data at all times. We mention only what is actually in place.

• Encryption in transit: all connections to the site, the application and the login service use HTTPS, which browsers are required to use (HSTS).
• Encryption at rest: the application’s database, which also holds the files you upload to it, is encrypted by its host; the application’s other files are kept in private, encrypted storage. Access tokens for Shopify stores are also encrypted by the application itself (AES-256-GCM), with a key kept outside the database.
• Separation by business: in the application’s database, every item of data belongs to a business, and it is the database itself that refuses to show one business the data of another (row-level security).
• Restricted access: the application’s database can be reached only from a list of authorised addresses, and the application connects to it with a role with limited rights, separate from the one that changes its structure.
• Passwords and login: passwords are stored in hashed form; two-factor authentication is offered to every customer and required of every member of our team; the number of login attempts is limited; resetting a password closes all sessions open on the site, but not a session already open in the application, which ends on its own when it expires.
• Logging: every action taken by our team on a customer account is recorded — author, action, date — and kept for three years; in the application, the activity log shows who did what, and every export of personal data leaves a trace in it.
• Backups: the application’s database is backed up automatically every day by its host, and these backups are encrypted.
• Hosting in Europe: the application and its data are hosted in France; the site runs in Paris and its database is in Frankfurt.
• Organisation: access to the administration tools is reserved for authorised persons, each limited to the tabs needed for their role, and on a read-only basis if they do not need to act; these persons are bound by confidentiality.

The retention periods and the role of each of our providers are described in our Privacy policy; the undertakings we give for your customers’ data, in our Data processing agreement.

A security policy is worth only the promises it keeps. So here is what Hugo BILLAUX EI does not have, today:

• No 24/7 on-call cover: a report sent on a Sunday evening is not read until the next working day.
• No security operations centre: we have no team monitoring the service continuously.
• No certification: neither ISO 27001, nor SOC 2, nor any equivalent. We claim none.
• No bug bounty programme: vulnerability reports are welcome, but they are not paid for.
• No guaranteed availability rate: we are bound by an obligation of means, with no availability rate, as our Terms of sale state.

What is described above, on the other hand, is what we actually do. This page will be updated if our means change.