Trust center

Subprocessor register

Data processing agreement (DPA)

Data location

Reversibility and exit

Artificial intelligence

Per-connector data inventory

Our own ReCyF assessment

We run on our own organisation the ReCyF assessment we ask our clients to run — all twenty objectives, at the scope of an essential entity, rather than the fifteen our size would let us stop at. We are below the size thresholds of the NIS 2 directive and are therefore not a regulated entity: this is voluntary. It is backed by a security policy, a risk analysis, a continuity plan and a quarterly security committee.

Security measures

Every line below describes code running in production, and every line is held to it by an automated test that fails if the code stops being its description. The headers you can check yourself, from your browser, without asking us.

• —Security headers in production: one-year HSTS (max-age=31536000, includeSubDomains), our pages refused inside another site (frame-ancestors “none” and X-Frame-Options: DENY), nosniff, and a Permissions-Policy that declines the camera, microphone, geolocation, payment and USB — none of which the platform ever uses.
• —A content security policy that restricts the origins: base-uri and form-action limited to the site, object-src set to “none”, and a connect-src limited to the site and our payment provider — so a script cannot open a connection to an arbitrary domain. It does allow inline scripts, which Next.js rendering depends on, and images from any HTTPS domain: it is therefore neither a defence against script injection nor a watertight barrier to exfiltration, and we prefer to write that down rather than let the word “strict” imply it.
• —Passwords hashed with argon2id, the algorithm recommended today.
• —Two-factor authentication: an authenticator app (TOTP, RFC 6238) or a one-time code sent by email, whichever each member prefers, with recovery codes issued once at enrolment. It is mandatory by default for every agency created since 2026-09-28; for agencies that already existed it is a setting to switch on, because imposing it retroactively would have confined all of their members to an enrolment screen overnight. Where it applies, it applies to the whole agency rather than to volunteers: until a member has enrolled a factor, their session reaches nothing but the enrolment screen.
• —Connector credentials encrypted at rest with AES-256-GCM.
• —The connectors that read your tools are read-only, and the refusal is enforced at the transport rather than left to each integration's good intentions: beyond authenticating and closing their own session, they write nothing. The product's only outbound write is the ticket you push yourself to your PSA or RMM, described in article 8 of the data processing agreement.
• —Isolation between agencies verified by 23 automated tests replayed on every code change: an agency trying to read, modify or delete another's data is told “not found”, and the GDPR export contains no row belonging to another client.
• —Rate limiting across the whole API, with stricter counters again on the authentication pages.
• —Audit log exportable as CSV.
• —Automatic backups every 24 hours, kept for 30 days. Restoring them was verified end to end on 2026-09-16: a restored instance ready in 4.5 minutes, 53 tables compared against production, and the 13 non-empty ones found with identical row counts. Nothing schedules that test — the date above is the last one, not the promise of a cadence.
• —Every change passes continuous integration before it reaches production: types, lint, a dependency audit, translation parity and the test suite, including the 23 isolation tests above. An audit that finds a critical advisory stops the release rather than annotating it. Dependabot watches dependencies continuously: on 2026-09-16, 2 critical remote-code-execution advisories were closed the day they were raised. Every image carries the fingerprint of the commit that produced it, so any version ever deployed can be found and rebuilt identically.
• —No third-party analytics and no third-party error tracking, anywhere. Analytics are Umami, self-hosted and served from vigicap.fr: the script comes from our own domain, not someone else's. Errors go to GlitchTip, also self-hosted, reachable only from the Scaleway private network. No usage or diagnostic data reaches a US analytics or error-tracking service. The product's one third-party script is Stripe's, loaded on the screen where you pay for your own subscription and nowhere else — our public pages load none at all. We name it rather than write "no third-party scripts", which would be shorter and untrue.
• —In the event of a personal-data breach, notification within 48 hours. That is a contractual undertaking, shorter than the 72 hours of GDPR article 33, precisely to leave you time to notify the authority within it.

Check our headers yourselfSee live service statusReport a vulnerabilityVendor security sheet

Who we are

A trust page that does not say who publishes it is not one. These details come from the register and can be checked against it.

• NEXTLAB SAS
• SIREN 108 181 421
• 2 avenue d'Iéna, Résidence Les Jardins de Chaillot, 75116 Paris
• Participant Identification Code (European Commission) : 861319164
• Contact : Laurent Bertière — contact@vigicap.fr