Skip to content
FR EN
Sign in Try 21 days
Try 21 days Sign in
FR EN
Security

What we do, and what we don’t have yet.

A security page that only says the nice things is a brochure. This one separates what is in place and checkable from what is missing, and dates its own state.

State as of October 30, 2026

The short version. Your data is hosted in Montréal, kept apart from one organization to the next, and backed up every night with a copy verified by an actual restore. We do not, however, have a certification (SOC 2, ISO 27001), a third-party penetration test, or multi-factor authentication in service — the last section of this page names them, with the rest.

Where your data is

The service, its database and this site are hosted by ServaRICA (Rica Web Services), in Montréal, on a single server. Nothing is hosted in France any more. The exceptions — the few third-party services some information passes through — are named one by one in the privacy policy; this page does not replace it.

The service can only be reached through an outbound Cloudflare tunnel: no web port is open on the server. Only the administration access (SSH) is, by key only, with protection against repeated attempts (fail2ban); the system’s security updates install automatically. Cloudflare ends the encryption (TLS) before relaying traffic to the server; the privacy policy describes what it sees in passing.

Security headers

The public site (remanso.ca) sends on every response: a content security policy (Content-Security-Policy) that admits only resources from remanso.ca, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (geolocation, microphone and camera closed), Cross-Origin-Opener-Policy: same-origin and a one-year Strict-Transport-Security, subdomains included.

The service (app.remanso.ca) sends a content security policy with no third-party origin, frame-ancestors 'none' (no other site can show it in a frame), object-src 'none', nosniff, X-Frame-Options, Referrer-Policy, a one-year Strict-Transport-Security over HTTPS, and Cache-Control: no-store on its pages, so a “Back” button on a shared computer does not replay a closed screen. Any write coming from another site is refused (403).

What these headers do not do. Inline scripts and styles are allowed ('unsafe-inline'): the service does not yet use a per-request nonce, which weakens the protection against script injection. And one page can be framed by other sites: the player of a signage screen, by decision. You can check all of it yourself in a browser’s developer tools, “Network” tab.

Accounts and access

  • Passwords are at least twelve characters; they are stored hashed, never in clear.
  • The email address is confirmed before the account is used.
  • A session expires after seven days without activity. Resetting a password closes all of the person’s other sessions.
  • Sign-in with Google or Microsoft is possible, in addition to the password.
  • Inside your organization, you decide who sees what, by role and scope. On our side, technical access is limited to the people who need it to run the service.

Separation between organizations

Every row in the database belongs to an organization, and the database itself refuses to attach a row to one from another — not only the service’s code. What each person can then read is set by the code, which filters every read by the organization of the person signed in. We do not claim that a coding mistake is impossible. That is why, at every deployment of the service, an automated sweep creates two throwaway organizations and checks that a hand-crafted address shows nothing of the neighbouring one. The sweep can be skipped explicitly for an emergency deployment; that is not the rule.

Backups and recovery

One backup a day, at night, kept thirty days in Quebec. Each one is verified by an actual restore: if it cannot be read back, it is flagged as failed, set aside and never used. Every day a verified copy is pulled onto a second machine, also in Quebec, which is not at the host. That protects against losing the server or against a deletion, not against a disaster that would hit both places at once.

Since the backup is daily, a recovery after a disaster can lose up to a day of entries; this is not a numeric commitment. We publish neither a recovery time objective nor a maximum acceptable data loss: we have not measured either on the current installation.

If an incident happens

Our written commitment is the one in the privacy policy: in the event of an incident affecting your information and presenting a risk of serious harm, we notify you and the Commission d’accès à l’information, as the law requires, telling you what happened, what is affected and what we are doing. We do not publish a detailed internal procedure: it is not written yet.

Reporting a vulnerability

Write to confidentialite@remanso.ca, with a description and the steps to reproduce. The same details are in security.txt. Please do not access other people’s data beyond what is needed to show the problem, do not test by overload, and give us time to fix it before you discuss it. A message sent to this address is an email like any other: the terms promise an answer from a person within two business days. for a security report, we acknowledge receipt within one business day. We do not promise a time to fix.

What we don’t have yet

A public buyer has the right to read this before signing, not after.

  • No certification: neither SOC 2 nor ISO/IEC 27001.
  • No penetration test by an independent third party. Our checks are our own: automated tests and internal reviews.
  • Two-factor authentication is available, but optional. Each person can turn it on for their own account (a one-time code generated on their device, ten backup codes, a lockout after five failed attempts). It is required of no one by default: the administrator of each organization chooses whether to require it — of its administrators only, or, if they prefer, of every member (since November 2, 2026) — and can change that choice. The person concerned is notified by email when their second verification is turned on, removed or reset, or when their organization requires it of them (the email contains no code and no link). If they lose their device and their backup codes: an administrator of their organization can reset it; as a last resort, the Remanso team does so after checking their identity by a means outside the platform. Passkeys (WebAuthn) are not offered.
  • Single sign-on (SSO/SAML/SCIM) with your organization’s identity provider is not in service at this date. The intended design: it will be enabled organization by organization, on request, by the operator. SAML and SCIM are not offered.
  • The access log is not in service at this date. An activity log of changes exists for administrators; it does not say who merely opened a record.
  • No published recovery objective (RTO/RPO), no status page, and no promised uptime: the terms say so.
  • A single server, with no automatic failover, and a single person running Remanso: no second administrator is designated at this date, and no replacement procedure exists yet.

We will update this page when one of these changes — in either direction.