What we collect, and what we won’t go looking for.

Version of November 2, 2026

Who is responsible

Remanso operates the platform and answers for what is stored on it. Privacy questions go to the person responsible for the protection of personal information, at confidentialite@remanso.ca. We answer within thirty days.

What we collect to create an account

Three things, and all three earn their place:

• Your full name — so your colleagues can see who changed an entry in a record.
• Your email — it is your username, and it’s where expiry notices and password resets go.
• Your organization’s name — to create your space and make you its first responsible person.

We also keep, on the technical side: when the account was created, when you last signed in, and the IP address of your active sessions. That last one exists so you can end a session you don’t recognize.

The language of the page you signed up on, then the one you choose in your settings: we keep it with your account, so Remanso greets you in it. If you choose to follow your device, the screen follows your browser.

Of the sign-in itself we keep the bare minimum needed to recognise you: your hashed password — we do not know it and cannot recover it — or, if you use Google or Microsoft, the tokens that service hands us for the same purpose. We also keep the browser of each active session, alongside its IP address and for the same reason: to let you recognise, and close, a session that isn’t yours.

If you sign in with Google or Microsoft

Those two are offered, alongside email and password, because they spare you one more password. When you use them, we receive from them your name, your email, your profile picture if you have one, and a technical identifier that lets us recognize you next time.

What we don’t receive, and don’t ask for: your contacts, your posts, your friends, your calendar, your files, your history. We request the bare minimum those services call basic profile.

Limited use. Information obtained from Google services is used only to identify you and open your account. It is not sold, not transferred to third parties, not used for advertising, and not read by a human — unless you ask us to in order to fix a problem, the law requires it, or there is a security reason we would explain to you. This use complies with the Google API Services User Data Policy, including its Limited Use requirements.

We never post anything as you, on any of these services.

What your organization stores about its people

This is the sensitive part, and it isn’t ours: that information belongs to your organization, which remains responsible for it. We handle it on your organization’s behalf.

Depending on which modules you use, it covers: the names of employees and volunteers, their qualifications and certifications, the dates they were earned and expire, and the supporting documents you upload.

Three fields on a person’s record are optional. Two go together: a person’s date of birth and their photograph. The date serves one purpose — checking age — and a photograph can only be kept on file from age 18. With no date of birth on record, no photograph can be uploaded at all: unknown counts as no. This rule lives in the code, not in a setting — it cannot be turned off.

There is a precise reason for that. Our customers give real responsibility to people of fifteen or sixteen, and keeping a photograph of a minor calls for a consent we have no way to collect or to prove. We would rather not keep it at all.

A photograph appears on that person’s own record and nowhere else: never in a list, never in an export — with one exception, the exit archive described below under “Your rights”, which hands the organization, and each person for themselves, everything it holds, photograph included — and never in what another employee sees.

The third is the hourly rate. It serves one purpose: estimating what hours of work cost — those of a planned week and, if your organization tracks its budget in Remanso, those it charges to its budget lines. This is not payroll — Remanso pays nothing, withholds nothing, issues no tax slip, sets no one’s pay and calculates no seniority. This rate is not used to calculate overtime or premiums. The premiums and overtime Remanso takes into account are the ones your organization gives it, through its own rules or an entry made by hand on a shift (see below): it stores them, shows them and exports them without deciding anything.

It follows the same rules as the photograph, and two more. It appears only on a person’s record, never in a list and never in a week export. It appears on no employee screen, not even that of the person concerned. And it is visible only to members the organization has granted the “see costs” permission — reserved for administrators by default. It does appear in the exit archive, which carries a person’s whole record — rate included: the one a person downloads about themself, and the whole organization’s, which only an administrator downloads and which does not take the “see costs” permission into account.

The total shown on a schedule is a daily aggregate: hours with no rate on file are excluded and reported as such.

In the budget, what a line’s hours cost — the committed amount and the estimated actual — is computed the same way, on screen and in the budget status export. A schedule total and this amount are computed only for members with the “see costs” permission, and neither is hidden below two people: either can show what a single person’s hours cost, and so their rate — to members who already have permission to see it.

Two other optional pieces of information go together: a person’s hire date and priority rank. They serve two purposes, and only two: when your organization chooses to give a shift away after a delay, breaking ties between the people who raised their hand; and, when it has schedules picked in turns, setting the order of turns — the hire date, then the employee number, never the priority rank. This is not a seniority calculation for payroll: Remanso compares the dates your organization entered — or, for seniority at a place, the date of the first shift the person held there. They appear on the person’s record and, for the order of turns, the hire date also appears in the list that the organization’s management sees; a person sees their own hire date and their own rank in the list, never another employee’s.

That choice is then made by the software alone, by the rule your organization picked: seniority, rank, hours already on the schedule, or chance. The “Open shifts” screen tells every employee, before they raise a hand, the delay and the rule that apply, and the decision goes through the same checks as the administration’s — required qualification, overlap, approved leave — and never gives a shift that would put someone over the weekly maximum hours on their record. This last check dates from September 26, 2026.

If your organization uses time tracking, we keep the hours actually punched. For each shift: the arrival time, the departure time, the unpaid break taken, the paid break taken when your organization grants one, and where the entry came from — the person punched it themselves, an administrator entered it, or the software closed a departure nobody had punched. That last case is always flagged: approving an hour nobody declared is precisely what we refuse to make invisible.

To that we add, where they exist, the note in which the person explains a gap and the note in which an administrator decides, along with who decided and when. Paid time is frozen at the moment of that decision, together with the sentence that explains it — “start tolerance, seven minutes”. It is frozen for a reason that protects the person: without it, changing a setting would rewrite timesheets that had already been approved. And this stays outside payroll — Remanso sorts minutes into categories your organization has named; it pays nothing and issues no tax slip.

Your phone’s location is asked for only at the moment you punch, and only if your organization has chosen it. Your organization can set an area around its workplaces; by default, no location is asked for. When it has chosen it, the “My hours” screen asks for your phone’s location at the moment you press “I have arrived” or “I am leaving” — never before, never after, never in the background. Your browser first asks your permission, and you can refuse: the punch still goes through, marked “without a location”, and goes to approval.

We keep only the distance between that point and the shift’s place, and the verdict that follows from it — inside the area, outside it, or unknown. Your coordinates are used for that calculation, then forgotten: they are never recorded, and nobody can see where you were. The location is computed by your phone; Remanso calls no location service. If your organization refuses punches outside the area, a punch made far from the place is refused, and the screen tells you so. The punch kiosk asks for no location: it is already in its place.

We record no biometric data. No screen reads a fingerprint or a face: biometric information calls for express consent we would have no way to collect or to prove. What we don’t collect can’t leak.

A punch kiosk is a public screen, and its PIN is kept encrypted. Your organization can put a tablet in a workplace: you type your employee number, then a six-digit PIN, drawn at random or chosen by an administrator. The kiosk only checks a slow, salted fingerprint of the PIN, which cannot be turned back into the PIN. The PIN itself is kept encrypted, with a key that never leaves the server: only the people who configure your organization’s modules — its administrators, unless it decides otherwise — can read it back, to give it again to someone who forgot it. We also keep the date it was set, and the last time the kiosk was used.

A kiosk assigned to a location sees only that location’s shifts, and it locks for a minute after ten failed attempts. It exists only if your organization creates one: until someone does, and until a PIN is set, none of this is recorded.

The same tablet can also take register readings, if your organization chooses. You identify once, with the same number and PIN, for a working session that ends after ten minutes without activity, after one hour at most, or at the press of a button. Each reading keeps who took it, the kiosk and the time. When the network drops, the tablet keeps the readings in a queue on the device: identifiers, the values and the signed session — never a name or a PIN. The queue is sent as soon as the network returns and is emptied as it goes; a reading the server refuses stays on the tablet’s screen, so it can be copied, until someone clears it. This paragraph was added on 20 October 2026, when readings came to the kiosk.

The paragraphs on time tracking and the punch kiosk were added on 22 September 2026, when time tracking arrived in the product. Those on location and the paid break were added on 24 September 2026: until then, no Remanso screen asked for a device’s location. A PIN that administrators can read back dates from 25 September 2026: until then, it was shown only once.

Time off. A leave request keeps the dates, the kind of absence, the decision and who made it — and the reason, if the person writes one. That field is optional in the software: requiring a reason for sickness is an organization’s policy, not a rule we impose. It is the most delicate piece of information the product can receive, and that is precisely why it is never mandatory.

Day-to-day work leaves traces, and they carry names. Who raised their hand for an open shift and what they said about it; who was offered an open shift, when, and the moment the person saw it in Remanso; who asked for a replacement, who took it, and why; which device is assigned to whom and since when; which team a person belongs to — so where they work and what they can see; and the free-text notes attached to a shift, an availability, a device or a logbook entry. These are scheduling facts, not judgements.

“Seen” is measured in Remanso, never in your email. An invitation to take a shift goes out by email, and that email carries no tracker: whether you open it is neither measured nor passed on. What the administration sees is the moment the invited person, signed in, opened the open-shifts list showing that shift — and that list tells them so. None of this is recorded until your organization invites someone.

Both additions date from 24 September 2026. They describe invitations to open shifts, which arrived in the product that day.

Recertification sessions, if your organization plans them: who registers or withdraws, who is on the waiting list and in what order, and the result the administration records after the session; who teaches it: a person on file, or the name of an outside instructor; and, for each registration, the language to write to them in, and when their reminder went out. Confirmations and reminders go out by email, with no tracker, like invitations. This addition dates from 25 September 2026.

Training sessions — in-service training, a team meeting — follow the same form as recertification sessions: who registers, who waits, and the attendance the administration records afterwards. They record no qualification. Each person’s total training hours are calculated from the sessions where their attendance is recorded; they are not written separately. This addition dates from September 26, 2026.

The publication notice. When a schedule is published, an email says so to the people who asked for it in their app — to them alone, and for as long as they want it. We keep that choice, and the language to write to them in. The email does not carry the schedule, only the link to see it once signed in, and no tracker. This addition dates from September 26, 2026.

Emails to staff in Participants, if your organization switches them on: a notice when a progress report is returned to the instructor or submitted to the coordinators, and a daily summary of returned or overdue reports. They name groups and counts, never a child; they go to the address of the person’s account, in their language, through Mailjet, already named below. We keep only the record that a summary went out, so it does not go out twice. Nothing is sent until your organization ticks the box. This addition dates from October 21, 2026.

Attendance on a location’s tablet. On a location’s attendance tablet, the list of participants (first name and last-name initial) exists only for the length of the instructor’s session, which opens with their employee number and PIN and closes after ten minutes without a touch or at “Finish”; if the network is down, each attendance mark waits on the tablet, as identifiers with no name at all, until it is sent, and for at most twenty-four hours. This addition dates from October 21, 2026.

If your organization collects availability for a period, we keep, for each person the request is sent to, their answer — yes, backup or no —, the time slots they give and the note they add; who entered it if it was not them, and when; when the request and its reminders went out, and the moment the person saw it in Remanso. The email and the notification carry only a link. Before answering, the person reads how the shift-pick order is set, the hire date on their record, and whom to contact to have it corrected or their rank reviewed. These answers are kept twelve months after the end of the period, then deleted. This addition dates from October 24, 2026.

The availability request email: it goes to the address on the person’s account, in the language of the screen it was sent from, through Mailjet, already named below; it carries only your organization’s name and a link. A reminder goes out once a day at most.

If your organization has schedules picked in turns, the software alone sets the order of the people who answered yes: the hire date on file, the oldest first, then the employee number, then the name; a person with no hire date goes after those who have one, and a person added to the list later goes last. Each person sees this rule before answering, then their own rank — never another person’s — and whom to contact to have it reviewed. For each person on the list we keep their rank, the hire date and the number kept when the list was built; the state of their turn, its start and end times and the moment the notice was sent to them; the note the manager writes there. The email and the notification carry only a link. This information is kept twelve months after the end of the period, then deleted. This addition dates from October 24, 2026.

The shift-pick email: it goes to the address on the person’s account, in the language of the screen the manager acts from, through Mailjet, already named below; it carries only your organization’s name and a link, when the list is built and when the person’s turn comes.

A person’s phone number and emergency contact. If your organization’s administration records them, we keep on a person’s record their phone number and, if the administration records one, the name, number and relationship of someone to reach in an emergency. None of it is required and no postal address is asked for. Only the administration can read it: this information appears in no staff list, no export file of that list, no email, no notification and no text message, and it is passed on to no one. It stays on the record as long as the person is on file, archived or not; emptying the field erases it. A person who has an account finds their own number and emergency contact under My data, and they are included in your organization’s archive. They are destroyed with your organization’s records, at the time given below. An emergency contact is a third party: your organization is responsible for obtaining their agreement before recording them. This addition dates from October 25, 2026.

Leave balances. If your organization’s administration records them, we keep on a person’s record, for each type of absence, the days of leave the administration grants them for the year, an adjustment and a note. The number of days they have left is not kept: it is calculated each time it is read, from the approved absences. None of it is required. The administration reads the days granted, the adjustment and the note, on the person’s record and in the window where it decides on an absence request; the person sees only, in their own space, the days they have left for the year, by type of absence. This information appears in no email, no notification, no exported list and no payroll export, and it is passed on to no one. It stays on the record as long as the person is on file, archived or not. A person who has an account finds it under My data, and it is included in your organization’s archive; it is destroyed with your organization’s records, at the time given below. This addition dates from October 25, 2026.

The shift log. We keep a log of the schedule: who created, edited, published or removed a shift, or assigned someone to it, and when — and, in the same way, who cancelled, restored, duplicated or split it, or who released themselves from it. Each line carries the name of the person who took the action (or the words “the System” when it is an automatic task), the person concerned and, for an edit, the old and new values of the time, the break, the place, the role, the qualification, the scope, the budget line and the shift’s note, cut to 80 characters. The log is read on the shift’s page, by the people in your organization who have access to schedule management; it is not in the employee’s own space, appears in no email or notification, and is passed on to no one. No automatic purge erases it: it is kept as long as your organization has an account, even when the shift is removed or the person is archived, and it is destroyed with your organization’s records, at the time given below. It is included in your organization’s archive; a person who has an account finds under My data the lines that concern them (a shift they were assigned to or taken off), with the name of whoever acted, but not those where they are only the author of the action. This addition dates from October 25, 2026.

Notes about a person. Your organization’s administration can write notes about a member of its team. We keep, on that person’s record, the notes the administration writes there, with the name of their author and their date; a note is free text of 2,000 characters at most. Only the administration reads them: the person concerned does not see them in the application, and they appear in no list, no exported file, no email and no notification, and are passed on to no one. If a person who has an account downloads their data, under My data, these notes are part of it; they are also included in your organization’s archive. They stay on the record as long as the person is on file, archived or not, unless the administration removes them, and they are destroyed with your organization’s records, at the time given below. This addition dates from October 25, 2026.

The usual week. We may keep on a person’s record the days and hours they can or cannot normally work, with, if given, the dates between which it applies. This information is only used to flag, when choosing who to assign to a shift, that the shift falls outside their usual availability; it never prevents an assignment. It is entered by the people in your organization who keep the staff records; they read it, as do the people who assign shifts (who see only the flag), and the person sees it too, read-only, in their own space. It appears in no email or notification and is passed on to no one. It stays on the record as long as the person is on file, archived or not. A person who has an account finds it under My data, and it is included in your organization’s archive; it is destroyed with your organization’s records, at the time given below. This addition dates from October 25, 2026.

Keys and access. If your organization keeps a register of its keys, cards and lockers, we keep, for each one, its tag, what it opens and a note, as well as the keys, cards and lockers a person holds, since when, and the log of when they were handed out and returned — including when they are reported missing or withdrawn —, with the name of the person concerned and of the account that recorded the event. A person’s name is the one already on their record: the register adds no other information to it. None of this is passed on to anyone, by email or notification, and none of it leaves Québec. It can be viewed by the members of your organization with access to the inventory, within the scope they have been given; those who view a person’s record see there what the person holds, never the log. The person does not see it in the application. A line of the log cannot be edited and no screen erases it: it stays as long as your organization has an account, even when the key is withdrawn from the register or the person is archived, and it is destroyed with your organization’s records, at the time given below. The lines that name a person appear in My data if they have an account, and the whole register is in your organization’s archive. This addition dates from October 25, 2026.

The training log. When a person attends a training or recertification session, we keep on their record their attendance and, if the person who records the results writes one, the short note addressed to them at the end of the session (300 characters at most). We also keep the skills the session had people practise: what the session exercised, never a level or a grade on the person. The person reads their own history, note included, in their own space; the administration reads it on the person’s record, within the scope of its teams. It appears in no email, no notification and no printed document. The people who can export the staff list can also export these sessions as a file, within the same scope. This information stays on the record as long as the person is on file, archived or not, is included in My data and in your organization’s archive, and is destroyed with your organization’s records, at the time given below. This addition dates from October 25, 2026.

Field observations. If your organization observes a person at their post, we keep the observation on their record: the scenario, the date, the place, each criterion met or not with a short comment, the name of the observer, and also the lifeguard post where it took place, the overall result chosen by the observer, the follow-up requested or done, and the fact that it is an observation. The overall result (compliant, needs improvement or non-compliant) is the observer’s own judgment: the software does not calculate it and ranks no one. The person observed reads the finished observation, in full, in their own space — never a draft, never another person’s; the administration reads it within the scope of its teams. It appears in no email or notification and is passed on to no one. It stays on the record as long as the person is on file, archived or not, is included in My data and in your organization’s archive, and is destroyed with your organization’s records, at the time given below. This addition dates from October 25, 2026.

If your organization prepares a supervision and rescue plan (POSS) with the wizard, for each review made with it we keep the person who reviewed a supervision plan, with the role they give and the day of the review. The person is the one whose staff record is attached to the signed-in account; the role (“aquatics manager”, for example) is required, and the screen asks that no name be written in it. A review saved without the wizard keeps only the role and the day. The person’s name appears only in the plan’s review history, on the plan screen, for those who have the permission to manage supervision plans; the printed sheet shows only the role and the day. The person finds this link under My data, and it is part of your organization’s archive. If their record is deleted, the link is removed and the review stays with its role and date; if it is only archived, the link stays. The review follows the plan, so your organization, for the time given below. Nothing is sent by email or notification, and nothing leaves Quebec. This addition dates from October 25, 2026.

Visibility measurement of a pool. If your organization measures what a person on post can see from each spot of a pool, the session runs on tablets opened by a link: none asks for an account, none names anyone. We keep what your organization records there — the drawing of the pool, the posts, the conditions of the session, a note, and, for each square, whether one sees, sees with difficulty or does not —, with no name, no email and no IP address; please write no person’s name in the notes. Each tablet keeps in its browser a random identifier, which tells it apart without naming anyone and which stays until the browser data is cleared, along with the gestures not yet sent, which are cleared once sent. A session’s link stops working when the session is finished. No outside service is involved: the QR code is drawn here. These data follow the fate of your organization’s records, for the time given below. This addition dates from October 25, 2026.

Counting stations. A tablet placed at the entrance to a site or zone can record how many people are present — a total, never a name. To be authorized, the tablet shows a six-character code, valid for fifteen minutes, that an administrator of your organization enters in Remanso from their own device; no password is typed on the tablet. Remanso then sets a technical cookie on the tablet (specific to that station, lasting 90 days without use) that lets it enter totals for that station only. The cookie contains no name; Remanso keeps only its fingerprint, with the date of authorization, the last use and the name of the administrator who authorized the device. The administration can withdraw a device’s authorization at any time. The counts entered from a tablet carry neither a name nor a device. This information stays in Quebec, with the rest of your file, and follows its retention period: no separate purge removes revoked or expired devices. This addition dates from October 26, 2026.

Site alerts. If your organization has chosen it, we email the people scheduled at a site that will be closed and, if they have turned on notifications, send a notification with fixed text (“A message from your organization”, with no name, no time and no place). The email names the site and the day, and the time when the closure starts at a given time — never the reason. A “closed” notice, also without a reason, then appears on the site’s screens. Likewise, if it has chosen so, managers and the staff scheduled on site receive an email when a site reaches its capacity: it gives the site, the count, the capacity and the time of the count, never a person. By default, nothing is sent. These emails go to addresses already on file, through Mailjet, already named below, and contain only what precedes. This addition dates from October 25, 2026.

The season summary and the activity log. These two screens keep nothing new: they re-read what the modules already record. The summary shows only totals (hours, counts, averages), never a line per person, in the page as in the CSV and PDF files; in a very small team, though, a total can be enough to recognize what concerns one person. The activity log, reserved to your organization’s administrators, brings together actions the modules already record: who granted or removed access to a record, who changed a schedule, an enrolment or a device loan. It names the staff members involved, with their account email for access events; it names no child. Each trace is kept by its module, for its own period. This addition dates from October 25, 2026.

Notifications on the device, if you turn them on from your space: the address your browser’s notification service gives this device, the two keys that encrypt what is sent to it, the language of the screen you turned them on from, the kinds of notices you chose (schedule posted, shift to fill, message from your organization, red alert from a register, availability request or turn in the shift pick), and the time of the last delivery. For Remanso’s owner only, one more kind of notice exists: “A new email has arrived”, which says neither from whom nor about what. A notification names no one: it says “Your schedule is posted”, and the rest opens in Remanso, behind sign-in. You remove it in one step, for this device or for all of yours; an address the service declares expired is removed on its own. This addition dates from September 26, 2026.

One kind of notice is an exception: the red alert from a register (for example, a value outside the standard in a pool). It names the site, what is red and its value, because a notice that says nothing is of no use; it never names a person. Like every notice, it is encrypted end to end, but it may appear on the device’s lock screen: your organization chooses whether it shows the site and the value, the site only, or no detail. This addition dates from October 26, 2026.

Skills evaluations, if your organization uses them: the date, the scale chosen, the level reached per skill, the notes written, and who recorded them. It is the only place in the product where one person appraises another, and we treat it as such.

A signature is a typed name, never an image. Logbook entries and supply requests carry one: it is text, typed into a field, saying who did the entry. We collect no drawing, no image of a handwritten signature, and no biometric data.

And many screens keep who did the thing: the author of an announcement, of a Notepad page or of a lesson plan, the person who uploaded a document, the one who decided a request, the one responsible for an activity. In the Notepad, reading itself leaves a trace: who read which page, and who was mentioned on it. That is what lets you go back over a change and know who to ask about it.

Acknowledgements. A Notepad page can ask people to confirm they have read and understood it. We then keep who confirmed, for which version of the page and when; the people who write in that notepad see who has confirmed and who has not yet. An edited page asks for the confirmation again, and the earlier ones remain. This addition dates from September 26, 2026.

People identified in a Notepad page. A person who writes in your organization’s Notepad can identify a person whose record they can open: it is always a deliberate act, never an automatic detection of names. We then keep, on that person’s record, the Notepad pages where they are identified, by whom and when; the text of the page is not copied to the record. Your organization’s administration reads this link in the Notes tab of the record, within the limits of its scope, and only for pages it can itself read: it sees the page’s title, its space, its author and its date, with a link to the page. The person identified does not see it in the application, and it appears in no list, no email and no notification. If they have an account and download their data, under My data, these links are part of it, with who identified them and when, and with the page’s title, space, author and date only if they can read the page; they are also included in your organization’s archive. The person’s name stays in the text of the page for as long as the page keeps it, and in the earlier versions of the page that the history keeps (which are also in your organization’s archive). The link is removed when the name is removed from the page, when the page is deleted or when the person’s record is, and it is destroyed with your organization’s records, at the time given below. The Notepad is not meant for health information, nor for that of clients or participants. This addition dates from October 28, 2026.

Your account’s security. You can protect your account with a second verification: a six-digit code produced by an app on your device (no text message, no outside service). We keep, encrypted, the secret that produces those codes, the date it was turned on, the number of recent failed attempts, the last code accepted and the moment a lock lifts after five failed attempts; we also keep the fingerprint (never the code itself) of ten single-use backup codes and the date each one was used, and we note, on each session, the moment the second verification was given. An organization’s administrator can require this verification of its administrators or, if it chooses, of every member of its organization. We send the person concerned an email notice, at their account’s address, when their second verification is turned on, removed or reset (by an administrator of their organization or by the Remanso team, after checking their identity another way), or when their organization requires it of them; that notice contains no code, no secret and no link. We also keep a record of an organization’s security changes: what changed, when, the account of the administrator who made the change (or the platform) and the account of the member concerned. At an organization’s request, the Remanso team can open “organization sign-in”: members then sign in through the identity service the organization chose. We keep that service’s address, the organization’s identifier there, the secret it entrusted to us (encrypted), the domain names it proved it owns and, for each member, the identifier that service gives them and the date of their last sign-in through it, and, on each session, the organization whose sign-in opened it. That service receives your browser, never your Remanso data. A security cookie (see “Cookies”) is set during that sign-in and cleared afterwards. The second factor and the organization sign-in identifiers go with your account; the security record and the organization sign-in settings go with your organization’s records, at the time given below. No third-party service is added to the list. This addition dates from October 31, 2026; the requirement for every member and the email notice date from November 2, 2026.

A premium or overtime entered on a shift. In the timesheet, a person in your organization who has the right to edit the schedule can enter by hand, on an employee’s shift, a premium or overtime: by choosing one of your organization’s rules, whose values are then copied, or, if they also have the right to set premiums and overtime, by typing a value for that one shift. We keep, for that shift and therefore for that employee: its kind (premium or overtime), its code, its name, its calculation, its value, the minutes it covers, the written reason and the account of whoever entered it. The timesheet shows its name, code and duration to whoever reads it; the value, the calculation and the reason are shown only to members the organization has granted the right to set premiums and overtime. The shift’s log keeps that the entry was placed or removed, by whom and when, with its code, its minutes and the first eighty characters of the reason, never its value. The employee does not see it in their own space; they find the whole line under My data, and it is included in your organization’s archive. It also appears in the payroll export file your organization produces, under its code and name with a number of hours — without its value or its reason. Remanso pays nothing and does not set anyone’s pay: it stores the entry, shows it and exports it, and the figures it derives from it (hours covered, estimated supplement) follow the rule or the value your organization entered. It stays as long as the shift exists — a shift that carries one cannot be deleted, only cancelled — or until someone with the right to edit the schedule removes it, and it is destroyed with your organization’s records, at the time given below. It stays in Quebec with the rest of the record; no third-party service is added to the list. This addition dates from October 31, 2026.

Announcements: “I have read this” and questions. An announcement written by your organization’s managers can open in a window when you arrive, ask you to confirm that you have read it and ask you up to five questions (short or long answer, single or multiple choice). An announcement’s text names no one, and appears in no Remanso notification or email. When an announcement asks you to confirm you read it, we keep, for the person who confirms: their member account and the moment they confirmed having read the announcement. When it asks questions, we keep, for the person who answers: their answers and a random number that groups those of a single submission, with their member account and the moment they gave them, unless the announcement is anonymous (then no account and no time, only the day they answered). A person answers an announcement only once, and its questions can no longer change from the first answer on. By default, answers carry the name of whoever gave them; the managers can choose, before the first answer, that an announcement is anonymous: no account and no time is then kept with the answers, and an anonymous announcement cannot, at the same time, ask for confirmation of reading (that confirmation carries a name). All that remains is that the person answered, and the day. This protection holds for the application’s screens, exports and your organization’s archive; it does not protect against someone with direct access to the database. The window says so before you send. The results are read by the people in your organization who open the managers’ announcements screen (never employees): the number of confirmations, the names of who has confirmed or not yet, the totals per choice and the free-text answers, with each person’s name except for an anonymous announcement, whose results only appear, question by question, once at least three people have answered that question. Under My data you find your confirmations and the answers given under your name; those of an anonymous announcement are not there, since the application does not link them to your account. This information is included in your organization’s archive. It stays with the announcement — it disappears when the managers remove it —, with the member — for their confirmations and named answers —, and it is destroyed with your organization’s records, at the time given below. It stays in Quebec with the rest of the record; no third-party service is added to the list. This addition dates from November 2, 2026.

Favorites in the left-hand menu. Each person can pin the modules they use most, and the application can suggest others based on what they open often, in the “Often used” block of the menu (three at most, never a module that is already pinned or one the person is not allowed to open). For this, we keep, for each person and each organization: how many times they have opened each of the modules a favorite can point to, as a score that is halved every two weeks, with the moment of the last opening counted. An opening counts when the person opens a screen of the module, at most once per half hour and per module; we keep neither the date of each visit, nor the page address, nor the time spent, and we never count the basic screens, the settings, or the modules always shown in the menu. This count is used only for that suggestion: it appears in no report and on no screen of your organization, and no one but the person sees the suggestion it produces. You find it under My data, and it is included in your organization’s archive. It stays as long as the person is a member of the organization (the weight of a module they no longer open fades on its own), then it is destroyed with the member, or with your organization’s records, at the time given below. Pinning a module replaces the suggestion, and each person can decline suggestions: under “My favourites”, “Stop suggesting favourites” stops the count and erases the one already kept. It stays in Quebec with the rest of the record; no third-party service is added to the list. This addition dates from November 2, 2026.

Finally, anyone can save their own views of a schedule — a filter, a sort order, a location. They serve only the person who created them.

We keep a record of granted access. When an organization’s administrators link an account to a person’s record — which gives that account the person’s schedule, hours, leave and availability — we log who did it, for which account, and when. Removing that access is logged the same way.

This log cannot be edited or deleted — that is what makes it a log. Only the administrators of the organization concerned can read it, it disappears with that organization, and it keeps the name and email as they were at the time of the action, even if the account has since been deleted.

For criminal record checks we made a decision we won’t move on: we record only that a check was done, its date, and whether it shows an impediment. Never the contents of the report, never the reasons, never the record itself. Your organization needs to know whether someone may work with vulnerable people — not why. What we don’t store can’t leak.

If your organization recruits with Remanso

An applicant is not an employee, and the previous section does not cover them: someone who applies entrusts information to an organization that has not hired them, and may never hire them.

What an organization stores in that case: the name, the email, the phone number and the position applied for; the state of the application and the date it arrived; and the interview appraisals — a level per criterion, and what the person conducting the interview writes during it.

This information follows exactly the same rules as an employee’s: it belongs to the organization, it does not leave Quebec, it disappears with the organization. And someone who applied has the same rights as anyone else — to know what we hold, to correct it, to have it deleted.

Participants and their guardians

If your organization registers participants — in lessons, groups, a club —, it deposits with us the participant’s name, date of birth, the number your registration system gives them, and how to reach their guardians: their name, email, phone number, relationship to the participant and the language to write to them in. Add their registrations: the activity, the group and their dates. Add their attendance at each lesson of their group, and the skills the instructor saw them achieve, lesson by lesson. And the report cards your staff write. They usually come from a file you export from your registration system.

Many participants are minors, and that is why the list stops there: no photograph, no health information, no free note about the person. Attendance and observed skills date from September 26, 2026. A report card carries, for each skill, whether it is acquired, whether the level was passed, the recommended next level and what the instructor writes; it goes as a PDF, by email, to the guardians — never to a minor participant alone. Report cards date from September 26, 2026.

This information is not kept forever: it is removed 90 days after the end of their last session. A participant is not an employee: they have no record, no schedule and no access to the product, and they have the same rights as anyone — to know what we hold, to correct it, to have it deleted.

One exception: report cards sent to families. A report card (a progress report) sent to the guardians is kept five years after the end of the child’s last session, so a family who lost it can ask for it to be sent again. This copy carries what the report card says: the child’s name, their group and level, the skills and the result, the note the instructor writes to the family, and the guardians’ email addresses needed to send it again. Nothing else outlives it: everything else about the child is removed 90 days after the end of their last session, as above. A request for erasure deletes these kept report cards right away. This addition dates from October 21, 2026.

This section dates from September 26, 2026.

Private lesson requests

Your organization can publish a form where a parent requests a private lesson for their child, without an account. They write their name, their email, their phone number if they wish, the participant’s first name and date of birth if they give it, the level and location they want, and the days and times they are available; we also keep the language of the form, to call them back in theirs. Nothing else: no free-text box, so that no health information gets in by accident.

The IP address of the submission is used to slow down bursts of submissions: it stays in memory for a few hours and is never written. We do not write to the parent: your organization calls them back. Instructors see a request without name or contact details until one of them takes it; it is then readable only by them and by the coordinators.

A request is removed 90 days after it is closed, or after 90 days without anyone touching it. This section dates from September 26, 2026.

Forms

Your organization can create its own forms — an incident report, a shift report, a playground inspection — and have its staff fill them in. A submission keeps what the person answered in each field, the files they attached, their name, and the signature they typed or traced, with the date. Your organization decides the fields: an incident report can thus contain information about a member of the public, including an injury. Ask only for what you need.

The people your organization designates are notified by email at each submission; that email carries only the form’s title and a link, never the answers.

Each form carries its own retention period, chosen by your organization between one month and ten years: a submission is removed, with its files, at the end of that period, counted from its submission. This section dates from September 26, 2026.

Incident follow-up. If your organization turns on incident follow-up, it can record an incident or accident that happened with the public. For an incident, we keep the time and place, the kind of incident, the age band of the person involved (never their exact age), the nature of the injury and the part of the body affected (health information, never the person’s name), whether first aid was given and whether emergency services were called, the number of witnesses, the staff witnesses, a reference to the insurer’s file, the follow-up written by your organization, and the name of the person who reported it. The follow-up is the status, the person responsible, the due date and dated notes. Only your organization’s administration and management read them, with no scope restriction; staff can report an incident but cannot read it back. Nothing is passed on to anyone: the notice e-mail carries only the form’s title and a link. An incident is removed on the retention date your organization chose, at most thirty-six months after it was reported, or sooner if it deletes it; it leaves with your organization if it closes its account. This addition dates from October 25, 2026.

Guided setup

An organization can ask us to build its platform with it: we take its spreadsheets, import its people, its places and its qualifications, and train the people who will use it. The request keeps the name and the phone number the person writes in it, the days and times that suit them, and the message they add if there is one; we also keep who sent it and when. Nothing else: no extra email, no calendar, no third-party service.

The request is read only by your organization’s administration, in the product, and by the person on our side who answers it. It stays until your administration withdraws it, or until we remove it ourselves once the guided setup is done: it is then gone completely. This section dates from October 11, 2026.

If you apply for a position

When an organization opens an application page on Remanso, you can upload your résumé and other documents (PDF, DOCX, JPG, PNG or an iPhone photo). We keep what you write there — your first name, your last name, your email, your phone number and your answers to the organization’s questions —, the documents you upload (their name, their type and the document they fill), the language of the page, the date of your agreement, the date and the number of your uploads. Documents are stored in Québec, can be read only by the organization that is hiring, and never travel by email; the GPS position of a photo is removed on arrival. Do not include your social insurance number.

The organization chooses how long it keeps your documents and your answers after the hiring ends (30, 90 or 180 days, 90 by default), then they are erased for the people it did not select. Your name, contact details and interview notes stay in the organization’s file, which keeps them until it deletes them; you can ask it to erase everything at any time. This section dates from November 2, 2026.

Suggesting a new register type

Someone who manages your registers can suggest a register type that does not exist yet. We keep what they write in the form — the register’s name, what it checks, the items and their thresholds, the frequency, what requires it, who fills it in and their notes —, the files they attach, their name, their email address and when they sent it. The form asks them not to name anyone.

The suggestion reaches us by email, through Mailjet, with their answers and a link: their files stay on our server in Quebec, and we open them in Remanso. If they choose to attach their files to the email, the files also go through Mailjet and stay in our mailbox: they then leave Quebec, and the form says so before sending. For each file, we keep whether it left that way. A copy of their answers is sent back to them by email.

The suggestion belongs to your organization: it is included in your archive, the person who sent it finds it in their data, and it is destroyed with the organization — except the email we received, which stays in our mailbox. This section dates from October 19, 2026.

The “Problem or suggestion” button

Anyone who is signed in can write to us from this button, to report a technical problem or suggest an improvement. We keep the summary, the description, what they expected, how often the problem happens, the device and the browser, the links they paste, the files they attach, their name, their email address, the page they were writing from and when they sent it. The form asks them not to name anyone and to hide names in their screenshots.

The message reaches us by email, through Mailjet, with their answers and a link. Their files stay on our server in Quebec and are never attached to the email: we open them in Remanso, behind a sign-in, and every opening is recorded in a journal. A copy of their answers is sent back to them by email.

The message belongs to your organization: it is included in your archive, the person who wrote it finds it in their data, and it is destroyed with the organization — except the email we received, which stays in our mailbox. This section dates from October 25, 2026.

Files attached to an interview

During an interview, the hiring organization may attach to its notes a photo, a voice recording, a drawing or a document handed over. These files are stored in Quebec, with the interview; only the people in the organization who can read that interview open them. They are never transcribed, analyzed or sent elsewhere, and the GPS position of a photo is removed. The organization chooses how long it keeps them; they are deleted with the interview record, and the person photographed or recorded must be told beforehand. They are included in the organization’s archive and destroyed with it. This section dates from November 2, 2026.

Email sent to Remanso

Remanso also receives email, and it is not your organization’s: anyone who writes to an @remanso.ca address (support, privacy, a question before signing up…) entrusts us with what they write. We then keep the message, its subject, the name and address of the person sending it and of those it is addressed to, the attachments, and the replies we send. This email is never mixed with an organization’s records, and it is kept in Quebec, on the same machine as everything else. One person reads it: Remanso’s owner. We do not analyze it, we build no list from it, and we do not entrust it to anyone beyond what the next paragraph describes.

To reach us, the message passes through Cloudflare, which relays it without keeping it. If that relay fails, a copy of the whole message is forwarded to a personal mailbox of the owner with Microsoft, outside Quebec, so that nothing is lost. When we reply, the reply goes out through Mailjet, as described below. A new-email notification, if the owner has turned any on, says neither from whom nor about what.

If you have written to us, you have the same rights as everyone: to know what we hold of your correspondence, to have it corrected or deleted, by writing to confidentialite@remanso.ca. This addition dates from October 26, 2026.

Where your data lives

This needs saying precisely: for a Quebec organization, it is the question that matters most.

Payment is an exception: billing information — your name, your email address, the amount and, for an invoice, your organization’s name and purchase order number — is processed by Stripe, outside Canada. Your organization’s records do not leave Quebec.

Card reading is the exception: the image of a card uploaded with “Read the card” is read by Microsoft in Toronto, Ontario, then deleted. It does not leave Canada, and anyone who prefers not to use it uploads their card on the row of its qualification, as before.

Notifications are an exception too: to be delivered, they go through the browser’s notification service, outside Quebec. Their content is encrypted and names no one (a register’s red alert may name a site and a value, as your organization chooses); anyone who does not turn them on receives none.

Email is an exception too: a message sent to @remanso.ca passes through Cloudflare before reaching Quebec, where it is kept, and if that relay fails, a copy is forwarded to a personal mailbox of the owner with Microsoft, outside Quebec. Our hand-written replies go out through Mailjet. No organization’s records are involved.

The public site you are reading right now is a different thing: a static site, also served from Quebec, by the same host. It carries no form and collects nothing — signing up leads to the service. It is only a set of files: it has no access to the database or to your records.

Eight third-party services are involved, and here is exactly what they see:

• ServaRICA (Rica Web Services) — the server’s host, in Montréal. It rents the machine on which the service, its database and this public site run. We give it no access to the service or to the database; but, like any host, it controls the physical machines the disks sit on. That machine is in Quebec, in Montréal. This addition dates from October 25, 2026.
• Cloudflare — traffic and email routing. Requests to the site and to the service go through its network, whose servers are spread around the world, and are decrypted there for as long as it takes to pass them on, including those that carry your records. This is a passage, not a place where anything is kept: we entrust it with no records. It also relays, without keeping it, email addressed to @remanso.ca before it reaches Quebec.
• Mailjet — sending our email: address verification, password resets, expiry notices, participants' report cards, register suggestions (and their files, if the person suggesting chooses so), messages written to our team from the “Problem or suggestion” button (their text and a link, never their files), emails to staff that your organization can switch on (notices and summaries about progress reports), availability requests (a link, nothing personal), turns in the shift pick (a link, nothing personal), site alerts (a site, a day, never the reason or a person), hand-written replies to our correspondents. The message and the recipient’s address pass through its infrastructure, in Europe. We entrust it with no records.
• Google and Microsoft — sign-in, only if you choose to sign in with one of them. The one you choose learns that your account with it is being used to open a Remanso session, and when. We send it none of your information or your organization’s: it is the one that hands us what is described above.
• Stripe — subscription payment. It sees the name and email address of the person paying, the amount, the tier chosen, the state of the subscription, and a technical identifier of your organization (a code, not its name). If you choose to pay by invoice rather than by card, it also sees your organization’s name and, if you give one, your purchase order number: they are printed on the invoice. If you give the email address of your accounts payable department, Stripe notifies it of each invoice; the person who gave the agreement then receives the link from us, by email. We also send that address a private link to the Remanso invoice: the email carries only that link, never an amount. The link needs no sign-in — whoever holds it sees the invoice page, which shows your organization’s name, your purchase order number, the billing email address and the amounts, read from Stripe when it is opened. It is signed, expires after 120 days and is not stored by us; share it only with the people who process your invoices. Your card number never passes through our servers: it is entered in a form served by Stripe and goes straight to them. We entrust it with none of your organization’s records — no people, no qualifications, no supporting documents.
• Microsoft (Azure AI Document Intelligence) — reading qualification cards, when someone uploads theirs with “Read the card”. The image is read in Microsoft’s data centre in Toronto, Ontario: it therefore sees all of its text, including the name and, if it appears, the date of birth. We ask it to delete the result as soon as it is read; at the latest, it deletes it within 24 hours, and uses it for nothing else. We keep only the qualification and the dates the person confirms; the text read is stored nowhere. This addition dates from September 26, 2026.
• Browser notification services — Google (Chrome and Android), Apple (Safari), Mozilla (Firefox) and Microsoft (Edge), depending on the device’s browser, if you turn notifications on. They carry an end-to-end encrypted message, which they cannot read, to the address they themselves gave the device: so they see that address, and the time and size of the delivery. Their servers are outside Quebec, most often in the United States. The message names no one (except a register’s red alert, which may name a site and a value: see above). This addition dates from September 26, 2026.
• Microsoft (the owner’s personal mailbox) — email addressed to @remanso.ca, only if its relay to Quebec fails. A copy of the whole message, attachments included, is then forwarded to the personal mailbox of Remanso’s owner, outside Quebec: Microsoft sees that message like any mailbox’s, and it stays there until the owner deletes it. No organization’s records are involved. This addition dates from October 26, 2026.

To locate your places, the service also queries Adresses Québec, the Quebec government’s public address service. It receives only the text typed in a place’s address field (an arena, a pool, an office), sent from our server in Quebec to suggest the exact address. That is not personal information, and nothing else is sent to it: no names, no records, not your IP address. So we entrust it with nothing about you.

What we keep about payment. On our side, the subscription keeps the email address of the person who agreed to the subscription and when they did, the two identifiers Stripe assigns us (one for your organization as a customer, one for its subscription) and the time of Stripe’s last message. No card number is kept on our side. The people your organization authorizes for billing read the agreement and that email, which is also used to send them copies of invoices and notices about the subscription; the platform sees the Stripe identifiers in order to support it. This information is part of your organization’s archive and follows its records, for the time given below. This addition dates from October 25, 2026.

This section changed on September 13, 2026. Until then the service was hosted in France and we said so here. The move to Quebec is done.

It was clarified on September 24, 2026: the address search for places is described here.

It changed on October 25, 2026: the service and this public site are both hosted by ServaRICA, in Montréal. Nothing is hosted in France any more.

This section changed on October 14, 2026. Online payment went live and Stripe was added to the list above.

Who can see what

Each organization is isolated from the others. 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 service’s code, which filters every read by the organization of the person signed in.

Inside your organization, you decide who sees what. On our side, technical access is limited to the people who need it to keep the service running, and we don’t open your records out of curiosity or to analyze them.

We do not sell, rent or trade any information. We hand it to a third party only where the law compels us, and we tell you when we’re allowed to.

How long we keep it

• Your account — while it’s active. Once it is closed, it is deleted on request, by an operation we carry out by hand.
• Your organization’s records — while your organization is a client. When the subscription ends, we let you retrieve a copy, then delete them on request, by an operation we carry out by hand.
• Sessions — seven days without activity.
• Email sent to Remanso — there is no automatic deletion yet: the owner deletes it by hand, and you can ask for what you wrote to be deleted by writing to confidentialite@remanso.ca. It follows the backups, kept thirty days.
• Backups — one a day, kept thirty days, then destroyed. Each one is checked by an actual restore: if it doesn’t read back, it is reported as failed, set aside for examination and never used. Before any restore we also set aside the state of the database: that copy stays until we remove it ourselves. All of these copies stay in Quebec: on the server, and each day a copy is pulled to a second machine, also in Quebec, that is not at the host. This protects against losing the server or against deletion, not against a disaster that would hit both places at once. We would rather tell you than let you assume.

After that, the data is destroyed. Not archived: destroyed.

Your rights

Quebec’s Act respecting the protection of personal information in the private sector gives you rights, and we honour them without asking why:

• Know what we hold about you, and get a copy of it.
• Correct anything inaccurate or incomplete.
• Withdraw your consent, and close your account.
• Take your data with you, in a structured, commonly readable format.
• Complain to Quebec’s Commission d’accès à l’information if our answer doesn’t satisfy you.

On taking your data with you, we go further than the law requires, and it’s written on our values page: a full export is available at any time from inside the application, without asking us first, even when the subscription is read-only. Each person downloads what their organization holds about them in Remanso — their account, their record, and what attaches to it: their shifts, qualifications and certifications, leave and punches — from their account menu, under My data. An administrator of the organization downloads the whole organization’s records, documents included, under Export data; a custom role, even one based on administrator, does not give access to it.

In both cases it is a .zip archive built when you click — allow up to a minute if your organization has many documents. It holds one CSV file per table (UTF-8, semicolon-separated, readable in a spreadsheet), the documents as they were uploaded, a manifest that counts the rows and gives each file’s hash, and a README in both languages that explains the format.

From the organization’s archive, only secrets are left out: hashed passwords and sign-in tokens, open sessions, pending verification and reset links, a device’s notification address and keys, secret tokens and addresses (invitation, upload, kiosk, screen, public form) and punch PINs. They open doors: an archive that travels must open none.

In My data, your sessions and your devices are included, without their token or keys. Not included are the rows that name you only as the author or person responsible for an action (they are most often about someone else), or that concern people without an account. Each archive’s README names what is not in it, and why.

Deleting your account and your data

One way, today: write to confidentialite@remanso.ca from the account’s own address. We confirm within thirty days, without asking why.

The Delete my account button in settings doesn’t exist yet — we commit to adding it, and this section will say so when it’s done. Until then, email is the only way, and it works.

If you signed in with Google or Microsoft, deleting your Remanso account also removes the link to that service. Revoking access on their side — in Google or Microsoft security settings — cuts us off, but does not delete your Remanso account: for that, write to us as above.

If you are an organization’s responsible person, deleting your account does not delete the organization’s records: those belong to the organization. To close the whole organization and destroy its records, write to us — we first confirm the request comes from someone entitled to make it.

Cookies

The site you are reading, remanso.ca, sets none. The service, app.remanso.ca, sets twelve, and each one serves something you are doing or something you chose. None is for advertising, none follows you from site to site, none is read by a third party, and none can be read by a script on the page.

• Your session (__Secure-better-auth.session_token) — the one that keeps you signed in from page to page. It expires after seven days without activity, and disappears when you sign out.
• Signing in with Google or Microsoft (__Secure-better-auth.state) — only during that detour, it checks that the browser coming back is yours. Five minutes.
• Organization sign-in (remanso_sso) — only during sign-in through your organization’s identity service: it checks that the browser coming back is yours. Ten minutes, cleared on return.
• Confirming your address (remanso_verifier) — right after you sign up, it keeps the address you just typed, so we can resend the link without asking for it again. Thirty minutes, and it is cleared as soon as you are signed in.
• Resetting your password (remanso_reinit) — it carries the reset link while you choose a new password, so the link does not stay in the address bar. Sixty minutes.
• An invitation (remanso_invitation) — it carries the invitation while you sign in or create your account, and is cleared as soon as the invitation is settled. One hour at most, or twenty-four hours when the invitation is used to create your account.
• A copied or cut shift (remanso_quart) — the schedule’s clipboard, between the moment you copy or cut a shift and the moment you paste it. Thirty minutes.
• The open organization (remanso.org) — which one to show when you belong to more than one. One year.
• The theme (remanso.theme) — light or dark, only if you picked one; without it, the screen follows your device. One year.
• The collapsed menu (remanso.rail) — only if you collapsed it. One year.
• The columns of the staff list (remanso.personnel_colonnes) — the ones you chose to show, only if you chose some. One year.
• Notices already seen (remanso.avis) — up to when, on this device, you opened the notification bell, so it doesn’t light up again for what you have already seen. It stays on your device: we read it on each page and keep nothing of it. One year.
• Announcements already closed (remanso.annonces) — the simple announcements (with no “I have read this” and no question) you closed on this device, so that each opens only once. It carries a code specific to your account, never your name; another account in the same browser does not read it. One hundred and eighty days.
• Announcements put off until later (remanso.annonces.tard) — those waiting for a confirmation or for answers, for which you chose “Later”. It is tied to your sign-in and disappears when you close your session.
• No announcement waiting (remanso.annonces.rien) — a fingerprint (no name, no readable identifier) saying that no announcement is waiting for you, so the following pages do not look for one. It only holds for your sign-in, five minutes at most, and stops holding as soon as an announcement of your organization is published, changed or removed.

A sixteenth cookie is not for our clients: it lets the platform administrator see, for eight hours, the modules we still hide from organizations. No client receives it.

An authorized counting tablet receives one more, specific to its station (see “Counting stations”): it only travels to that tablet’s addresses and is used by Remanso alone.

The service also keeps its stylesheet, fonts and icons in your browser’s cache, so pages display faster — drawings only, never a page or a piece of information.

Some screens also keep something in the device’s memory — this is not a cookie, and none of it goes to a third party. On the roll-call tablet and the readings kiosk, a reading or an attendance mark that could not be sent waits on the device, as described above; on a visibility-measurement tablet, a random identifier tells the tablet apart without naming anyone, and the gestures not yet sent wait; on the television of a signage screen, the screen’s secret address is kept by its browser, and, for the time of a pairing by code, a device secret.

No advertising cookies, no trackers, no third-party analytics. That’s also why you had no banner to dismiss on your way in.

If something goes wrong

If an incident affects your information and carries a risk of serious injury, we notify you and the Commission d’accès à l’information, as the law requires. We’ll tell you what happened, what it touched, and what we’re doing about it — not a form letter.

When this page changes

The date at the top is the current version.

Three changes are announced by email before they take effect, never after:

• when we start collecting something we were not collecting;
• when we widen who can see it;
• when we hand it to a third party, or keep it somewhere else.

Those are the only ones that change anything for you, and they are rare. If one of them doesn’t suit you, you can leave with your data, at no cost.

Everything else appears here with an updated date, without an email: one more screen showing what you have already entrusted to us, a correction, a clarification of this text. We ship several times a day — telling you about every release would make noise, and noise is what stops people reading what matters.

What has changed

Version of November 2, 2026. Additions, and no commitment withdrawn.

• Added. Account security: the second verification (a code produced on your device), the ability for an organization’s administrator to require it of its administrators, the record of an organization’s security changes, and the “organization sign-in” the Remanso team can open at an organization’s request, with the security cookie it sets (see below). No third-party service is added to the list.
• Added. The premium or overtime a person in your organization enters by hand on an employee’s shift: its kind, its code, its calculation, its value, the minutes it covers, the reason and who entered it, and who can see it (see below). No third-party service is added to the list.
• Clarified. This page said that Remanso calculates neither overtime nor premiums. It still does not set anyone’s pay, but it takes into account the premiums and overtime your organization gives it, through its own rules or an entry made by hand on a shift: the sentence about the hourly rate now says so.
• Added. Announcements that ask you to confirm you have read them or to answer questions: who confirmed and when, the answers (under the person’s name, or without any name or time when the announcement is anonymous), who can read the results, and what My data returns (see below). No third-party service is added to the list.
• Added. Left-hand menu favorites suggested from usage: for each person, how many times they open each module (a score that fades, with no visit dates or addresses), what My data returns of it and who sees it (see below). No third-party service is added to the list.

Version of October 30, 2026. A correction: a commitment published on October 26 is withdrawn, because it is not yet kept.

• Withdrawn. On October 26, 2026, this page announced that the deletion of an organization’s records had become automatic, and that closing was requested on the “Subscription” screen. Neither is in service today: automatic deletion is suspended, and online closing is not open. Closing an account or an organization is requested by email at confidentialite@remanso.ca, and deletion is done on request, by an operation we carry out by hand — as before October 26. We will publish automatic deletion again the day it is in service, and not before. The terms page, which already said the close-account button doesn’t exist yet, and this page now say the same thing.

Version of October 28, 2026. Two clarifications, and no commitment withdrawn.

• Made more precise. The “Team notebooks” module is now called “Notepad”: it is the same module, and the page now uses that name throughout.
• Made more precise. The names of the rooms of a floor plan are no longer proposed by an artificial-intelligence model: that function has been switched off on the service since October 25, 2026. It never sent a plan out of our server, and it still sends none.
• Added. Email sent to Remanso (which passes through Cloudflare before reaching Quebec, with a fallback mailbox at Microsoft: one more third-party service in the list), counting stations, and what the browser of a signage screen keeps.
• Added. People identified in a Notepad page: the link from a page to a person’s record, which says who set it and when (see below). No third-party service is added to the list.

Version of October 25, 2026. This revision re-reads the whole page against what the service actually does. It removes no commitment about how we handle your information: it adds what was missing, makes a few points more precise and withdraws two statements we could not prove — an accurate text is worth more than a reassuring one.

• Hosting. The service, its database and this public site are hosted by ServaRICA, in Montréal. Nothing is hosted in France any more, and the backup copies are in Quebec.
• Added. The supervision and rescue plan (POSS) and the staff record of the person who reviewed a plan, visibility measurement of a pool on tablets, site alerts (capacity reached, closure of a site), the season summary and the activity log, what we keep about payment. None of these additions adds a third-party service to the list below.
• Made more precise. What Cloudflare sees in passing; backups (a copy that fails is set aside, and the state of the database from before a restore is kept until we remove it); the list of cookies (twelve, three of which were missing), with what some screens keep in the device’s memory.
• Withdrawn. The separation between organizations rests on the structure of the database and on the service’s code, which filters every read; we no longer say that no query, even badly written, can read another organization’s data. And we no longer say of the host that it does not read your records: we say that we give it no access to the service or to the database.
• Modules retired. Your organization’s messages to its team (the “Messages” module) and the rental of your spaces to outside groups (the “Facility rentals” module) are no longer part of Remanso. Their tables were removed from the service along with what they held: the text and recipients of messages, outside groups, their requests and their proof of insurance. This information is no longer collected; on our side, it remains only in the backup copies made before the removal, which follow the rules described below.