Security

Courtesy translation. Only the Italian version of this document has legal value: if the two texts diverge, the Italian text prevails. Italian law applies to the relationship in any case.

Our approach

Security for a platform that holds its customers content and brand identity is not a feature to bolt on at the end: it is a design constraint.

We apply three simple principles. Collect the minimum, give each person only the access their work requires, and make what happens verifiable.

The measures described here are the ones article 32 of the GDPR calls for: appropriate to the risk, not maximal in the abstract. We revisit them when the product changes or when an incident teaches us something.

Encryption in transit

All traffic to the platform and to the website runs over HTTPS. Plain connections are redirected to the encrypted version.

The technical cookies the site sets carry the Secure attribute, so they are never sent over an unencrypted connection, and the session ones also carry HttpOnly.

Calls to connected suppliers, from language models to publishing services, run over encrypted and authenticated channels.

Encryption at rest

Stored data, including content, uploaded materials and backups, is encrypted at rest by the platform or by the infrastructure hosting it.

Sign up drafts, which may hold business data before an account even exists, are encrypted server side and never left in the browser.

Passwords are not kept in clear text in any recoverable form.

Secret management

Supplier interface keys, tokens for connected services and the credentials a customer configures to publish on their own site are secrets, and we treat them as such.

• They are encrypted at rest with authenticated encryption.
• They never appear in logs, in error messages or in interface responses.
• Once saved they are not displayed again in the interface: they can only be replaced.
• They are reachable only by the application components that need to use them.

Access control

Every access to production systems is under a named identity. There are no accounts shared between people.

We apply least privilege: each person receives the permissions their role requires and nothing more. Permissions are reviewed when a role changes and revoked when the engagement ends.

Our staff access customer data only for support that was requested, diagnosis of a fault or a legal obligation, and it leaves a trace.

Isolation between customers

Each customer works in a separate space. One customer content, materials, settings and keys are not reachable from another.

Separation is enforced at data level and checked on every request: the workspace identifier is part of the authorisation check, not merely an interface filter.

One customer content never feeds another customer content and never contributes to any shared model.

Backups and restore

We take regular backups of platform data, kept encrypted and separate from the production environment.

Restore procedures are documented and rehearsed: a backup that has never been restored is not a backup, it is a hope.

Backup retention follows the same minimisation logic as the data itself: keep what is needed to restore, no more.

Logging and monitoring

We record the events that matter for security and diagnosis: authentications, operations on data, outcomes of processing runs, application errors.

Logs exist to understand what happened, not to profile people. They contain no secrets and, as far as technically avoidable, no sensitive customer content.

An error monitoring system flags anomalies in real time, so a defect is seen by us before it is seen by the customer.

Incident handling

We have a documented procedure for handling a security incident. In short.

1. Detection: the anomaly comes from monitoring, from an internal report or from an external report.
2. Containment: spread is limited immediately, even at the cost of temporarily degrading a feature.
3. Assessment: we establish what was exposed, which customers are affected and whether personal data is involved.
4. Communication: affected customers are informed and, where relevant, assisted with the notifications the law requires.
5. Remediation: the cause is fixed and the fix is verified.
6. Review: we write down what happened and what changes so it does not repeat.

Incident notification

If an incident involves personal data processed on behalf of a customer, we inform that customer without undue delay, as required by article 33.2 of the GDPR.

The first message goes out as soon as the incident is confirmed, even if the picture is not yet complete, and is followed by updates as the analysis progresses.

The customer, as controller, remains the party required to notify the supervisory authority within the deadline set by article 33 of the GDPR and, where applicable, to inform data subjects. We assist with the technical information needed.

Duties under the data processing agreement

Responsible disclosure

If you have found a vulnerability, write to info@flarseo.com with "security" in the subject. We read and we reply.

• Describe the problem, the steps to reproduce it and the impact you believe it has.
• Do not access data that is not yours, do not modify it and do not delete it.
• Do not publish the vulnerability before it is fixed or before we have discussed it together.
• Avoid tests that degrade the service for other customers.

We take no action against people who report in good faith and respect these conditions. We run no bounty programme: we say thank you and, if you want, we credit you.

What we do not claim

We would rather have an honest page than an impressive one.

• We claim no certifications we do not hold: no ISO certification, no third party attestation report.
• We do not present periodic third party penetration testing as established practice.
• We do not promise the absence of vulnerabilities: no system can promise that.

If any of these change, this page will say so with a new version and a new date, not before.

The measures described here are those in place at the date shown above. The contractual security obligations are those in the agreement delivered as an annex to the contract, in Italian, at signup.