Security and incident response

We call a security incident any event that affects the confidentiality, the integrity or the availability of the data held by LIORA. 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 inform the supervisory authority.

• Your account and billing data: LIORA is the controller of that data. The notification obligations fall to it.
• The data of your store's customers: LIORA 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 by the director of LIORA.

We acknowledge receipt no later than the working day following your message. 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 LIORA alone and cannot stand in the way of criminal proceedings brought by the public authorities.

The assessment is made by the director of LIORA, who is also responsible for the technical side of the service. There is no on-call team: that is a fact 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 — impersonation, unsolicited approaches, financial harm.

From this assessment follow the priority given to the fix and the notifications to be sent.

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.

Where the breach concerns data for which LIORA 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 store data obtained through Shopify, we also inform Shopify, in the manner provided for by its API terms of use.

We do not make any public announcement about an incident until the flaw is 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, nor that given to the data subjects.

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.

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.

A security policy is worth only the promises it keeps. So here is what LIORA 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 availability commitment: the service is provided "as is", as our terms of use state.

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

The standing measures — hosting of account data in the European Union, hashing of passwords, the role and undertakings of our processors, retention periods — are described in our Privacy policy, which this page does not replace.