Data processing commitments

Scope

This page covers the personal data OrbiVigil handles for an account holder — the named individual(s) at a commune, SDIS, préfecture or similar body who hold an OrbiVigil account — and the territory data they configure. It does not cover the wildfire detections themselves, which are derived from public satellite and weather sources, not from personal data.

Roles, kept simple

We deliberately avoid asserting a legal controller/processor characterisation on this page — that determination depends on your organisation's own use of the service and is properly made with your counsel, not assumed by ours. What we can state plainly: for the account holder's own professional email and the territories they configure, OrbiVigil performs processor-like duties — we store and act on the data to run the service (send alerts, render the dashboard), we do not sell it, and we do not use it to train models or for any purpose the account holder did not ask for.

These are our standard commitments, not a legal opinion on your organisation's obligations under GDPR Article 28. A formal DPA naming the parties and roles precisely is available on request (see §6).

What we process, and why

• Account identity: name, professional email.
• Session security metadata: IP address, user agent, coarse network-derived location.
• Configured territory: name, centre point and radius of each saved monitoring area, so alerts can be geo-fenced.
• Institutional pilot metadata: contact name, professional email, optional phone, commune/INSEE code.
• Billing identifiers for paid plans (a payment-processor customer identifier); no card data is held by OrbiVigil.

Our standard commitments

• Confidentiality. Sign-in is magic-link based (no password to phish or leak) with optional two-factor authentication available on the account.
• Security measures. Data is served and stored on a managed edge platform rather than a self-managed origin, which removes an entire class of server-hardening and patching risk from our side of the boundary.
• Purpose limitation. Territory and contact data configured for a pilot are used only to run the monitoring and alerting the account holder asked for — watched-area coordinates are never inferred or guessed beyond what was supplied or the official commune centroid.
• No silent role escalation. The pilot-provisioning path can only ever create the fixed mairie role; no caller-supplied value can create a higher-privilege account through that path.
• Breach notification. We do not have a codified, contractual breach-notification SLA to point to in this repository today. We commit to notifying an affected institutional account's registered contact without undue delay if we become aware of a breach affecting their data; the specific notice period is set out in a signed DPA, not assumed here.
• Deletion on termination. A lapsed trial or ended pilot removes the paid entitlement (alerts stop) but deletes nothing automatically — by design, so a commune's history and configuration survive a lapse. Any account holder can delete their own account, self-service, from the account dashboard at any time: a confirmation email is sent first, and only clicking the emailed link deletes anything — at that point any active subscription is canceled immediately and the account, its saved areas and its two-factor setup are permanently removed. For anything the self-service flow doesn't cover, or to request deletion on someone's behalf, use the contact form.

Sub-processors

• The managed edge platform that hosts and stores the service, including transactional email.
• The payment processor, for accounts on a paid plan only. Both are named in the signed DPA and to institutional buyers on request.

See also /trust/ for our data-protection practices in full.