Privacy Policy

1. Information We Collect

We collect the following types of information:

• Account information: name, email address, phone number and postal address during registration; if you sit on the board of directors, the form of your title that you choose yourself in your profile (masculine, feminine or gender-neutral, for example « Président », « Présidente » or « Présidence »), which is used only to display that title and is never inferred from your name
• Condo information: information about your syndicate, buildings, units and equipment
• Answers to a question in an announcement: when the board attaches a question to an announcement, the answer you give in the app is kept with the unit concerned and with your name. Depending on the question, it may include an availability, a preference, a quantity, an absence of objection, a free-text comment you write yourself, and a file you upload. An answer is attributable by design: the board needs to know which unit said what. It is never anonymous and it is not a vote. The board may also record an answer someone gave it by phone or by email: that answer then carries the name of the board member who recorded it, it is shown as board-recorded, and it never replaces the answer the co-owner gives themselves in the app.
• Usage data: information about your use of the platform, pages viewed and features used
• Subscription payment information: to pay your CondoAide subscription, we collect either credit card information (Visa, Mastercard, American Express) that you provide to us expressly, or banking details (institution number, transit number, account number) that you likewise provide to us expressly if you choose pre-authorized debit (PAD/ACSS Debit). This information is processed directly by our payment provider Stripe, which is PCI DSS Level 1 certified (the highest level) for payment card data; banking details, which fall outside that standard, are protected by Stripe's security measures and framed by its data processing agreement (DPA). CondoAide never stores your raw card or bank account numbers — only a secure token that does not allow reconstruction of the original number. Automatic collection of co-owner common expenses by syndicates is also processed by Stripe (Stripe Payments Canada, Ltd.): co-owners who activate the debit expressly authorize a PAD/ACSS mandate and their banking details are processed by Stripe, which deposits the funds directly into the syndicate's account. CondoAide never holds these funds nor retains raw account numbers.
• PAD mandate for the subscription: if you pay your subscription by PAD, the mandate itself — signed authorization, mandate identifiers and status, including revocations — is retained by Stripe on our behalf. In our own systems we keep only our Stripe billing references (customer and subscription identifiers) and billing history, not the mandate document. This billing data is retained for 7 years after the subscription ends for tax, accounting and legal-compliance purposes.
• Subscription transaction history: amounts, dates, statuses (successful, failed, returned), failure reasons where applicable — for billing and accounting compliance
• Communications: messages exchanged through our support service, including the files you attach to them, or by email where applicable. Files attached to the support form are kept in our private storage in Québec; they are no longer sent by email. Authorized CondoAide staff can download them, using two-factor authentication; the board members of the syndicate that sent the report can also view them in that report's follow-up, like the text that goes with them. When a board member reports a problem to CondoAide support from the app, the report also includes the pages of the app where it was opened and from which it was sent (without the address parameters), the person's role in the syndicate, the app version and the browser used, and, when session recording is on for that person, a link to the OpenReplay recording of the session (it opens only for authorized CondoAide staff and stops working when the recording is destroyed, after 30 days) and, for a report made from a refused import, the technical identifier of that refusal in our logs, so we can reproduce the problem. Once a report is resolved, the person who sent it may also give, if they wish, their opinion of the answer (“Great”, “Okay” or “Not good”) and a comment. This feedback is optional, does not reopen the report and is read only by authorized CondoAide staff; the other board members do not see it.
• Emails sent to the syndicate's mailbox: if your syndicate uses a CondoAide address (for example conseil@viva.condoaide.ca), what you write there (the message, its attachments, the address it came from, and the name and address of the other recipients it names in "To" or "Cc") is kept in the syndicate's file, and the entire board has access to it, as does, where applicable, the manager mandated by the syndicate. The mailbox belongs to the syndicate, not to one administrator: it is not a private channel to a person, and its contents stay available to the board when its members change. Once that address is in service, the syndicate also sends from it the emails CondoAide produces on its behalf: its notices and announcements to co-owners, but also the notices meant for its board, its treasurer, its manager and the people doing work for it, as well as its electronic signature requests. If you reply to one of those messages, your reply arrives in that same mailbox, available to the same people and kept for the same period. Each email sent from that address is recorded in a send log (sending address, recipient address, date and time), kept by CondoAide on the syndicate's behalf. When the address is not in service, these emails leave from CondoAide's address on behalf of the syndicate, and their footer says whether a reply reaches the syndicate. The board can also write a new email from that mailbox, to any address; replies to it arrive in that same mailbox and are kept with it. The board can address a reply or a new email sent from that mailbox to several people, in "To", in "Cc" or in blind copy ("Bcc"): the name and address of each are kept with the message, and a person in blind copy is never named in the message the other recipients receive. The board can attach files from its computer (PDF, images, or macro-free Word, Excel, PowerPoint and OpenDocument documents) to that email: each file is sent as a link, valid for 30 days and revocable by the board, that recipients open without a CondoAide account; the file itself is never attached to the email. Each opening of a link is recorded with its date and time only, with no IP address or browser, and the board sees it in the conversation; since the same link goes to every recipient of the email, this record does not say who opened it.
• Emails sent to `postmaster@` or `abuse@` at a syndicate address: these two addresses exist to report a delivery problem or the misuse of a syndicate address. What you write there (the message, its attachments and the address it comes from) is not added to the syndicate's file, and its board of directors has no access to it: the message is forwarded to CondoAide's operations mailbox, hosted on our own infrastructure in Quebec, and only our person responsible for the protection of personal information (see section 7) reads it.
• Communication read tracking: when your syndicate publishes an official communication in CondoAide and notifies you by email, we record when you view it in the app. This information is shared with your syndicate's administration, for the sole purpose of confirming that important notices have been received. No tracking pixels are used in emails.
• Uploaded documents: any documents you upload to the Service (registers, attestations, reports, photos, etc.)
• Temporary insurance-proof imports: when an authorized person imports co-owner insurance certificates in bulk, the aggregate PDF and its extracted text are stored temporarily to produce a preview and split proofs by unit. Only the necessary per-unit proofs remain after import; the aggregate file is never added to the syndicate's document registry.
• Claim records: when the board records a loss in the building (for example water damage), the record may name the damaged private portions and the one where the loss started. The link between a claim and a private portion, and its role, is visible only to the directors and to the current co-owners of that private portion; other co-owners only see that a private portion is affected. The current co-owner of a private portion linked to a claim sees its title, date and status, and the role of their own private portion, even when the board has not made the record visible to co-owners; when their portion was damaged, they only learn that the loss started in another private portion, not which one. Recording where a loss started is not a finding of responsibility. When the syndicate claims part of a loss from a co-owner it holds responsible for it (art. 1074.2 of the Civil Code of Québec), the record also names the private portion concerned, the basis of the claim, the facts noted by the board, its status, the amounts claimed and, where applicable, the charge added to that private portion’s account. This information is visible only to directors who manage claims and have access to the syndicate’s finances; the co-owner concerned only sees the charge added to their account.
• Identity of the person who enables automatic collection of condo fees: when a syndicate administrator turns on automatic collection of condo fees, we record who turned it on and when. This is shown to the other administrators of the same syndicate when they are asked to approve a debit, and is used to require that a second person authorise a debit above the syndicate's threshold: whoever enabled the collection cannot approve the resulting debit themselves. It also answers the requirement, under Payments Canada Rule H1, to be able to identify the party behind a pre-authorised debit mandate. It never leaves the syndicate. Within it, it is not restricted to the board: it forms part of the syndicate's record, consulted by the people attached to the building — co-owners and tenants — and it is also readable by those authorised to consult the syndicate's payments, including the accountant. Other external parties (vendors, building professionals, insurers, legal advisers) have no access to it.
• Identity of the person who authorizes a private portion’s PAD mandate: when someone authorizes or replaces the mandate used to debit a private portion’s condo fees, we keep their account identifier and whether or not they were a co-owner on the authorization date in CondoAide. This information is used to prevent any new debit if someone who signed as a co-owner no longer owns the private portion. The board and manager authorized to manage payments then see a warning without seeing the signer’s identity. The person’s identifier is not sent to Stripe. Stripe continues to receive the private portion’s technical identifier in the metadata needed to process the mandate in Canada and the United States (sections 3 and 9).
• Ownership transfer record for a private portion: when the board of directors records the sale or transfer of a private portion, we keep a dated transfer record: the departing and incoming co-owners, their shares, the closing date, the date the syndicate received the notice the acquirer must give it (art. 1065 of the Civil Code of Québec), and the board member who recorded the transfer. If the buyer was the private portion’s tenant, their tenancy ends at closing and they become a co-owner. Only board members authorized to manage members see this record. When the board chooses, the departing co-owner’s debit mandate is revoked: we keep the proof of revocation, the notice sent to the payer and, for each debit after closing, the single cancellation request sent to the payment provider and its answer. The new co-owner may also receive an invitation to authorize the debit of condo fees; we keep the invited person, the board member who invited them, the private portion, the date and the delivery status.
• Identity of the person who declares what the declaration of co-ownership provides for contributions paid before the budget is adopted: when a person authorized to manage a syndicate's settings states that the declaration of co-ownership treats those payments as instalments on the annual contribution, we record who declared it, when, and the article of the declaration that is cited. Every change to this answer is recorded in the syndicate's audit log with the name and email address of the person who made it. The person's identifier forms part of the syndicate's record, readable by the syndicate's members in the app; their name is shown only to people authorized to manage the syndicate's settings. This information never leaves the syndicate and is not used to calculate any contribution.
• IP address: your IP address is processed while you browse the public site and use the platform — security and anti-abuse logs kept by our hosting providers, and momentary city lookup by our aggregate analytics, after which it is immediately discarded. It is passed neither to our product telemetry nor to our error tracking. One exception: when you sign electronically — a proxy, an access agreement, or an acknowledgement of a syndicate document — the IP address and browser used are recorded durably alongside the signature, because they are its proof under section 39 of the Act to establish a legal framework for information technology. Those entries are kept per section 5.
• Calculators used from an artificial intelligence assistant (CondoAide connector for ChatGPT and Claude): if you use our condo fee, special assessment or reserve fund calculators from ChatGPT (OpenAI) or Claude (Anthropic), it is your assistant that sends us the calculation data: amounts (budget, cost of the work, fund balance), private portion numbers and their relative values, construction or replacement years, rates. This connector asks for no account, name or email address, and its fields accept only numbers and predefined choices: it needs no personal information, so do not include any in your request. We do not keep this data: the calculation is made, the result is returned to your assistant, and we keep only a technical log line (tool name, success or failure, duration), without the calculation data or the IP address. The IP address of the call, usually that of the assistant’s servers rather than yours, is used only to limit the number of requests per minute; it is held only in our server’s memory, for that one-minute window, then cleared on the next request or when the server restarts, and it is written neither to a database nor to our logs, apart from our hosts’ security logs described above. OpenAI and Anthropic are not our sub-processors for this service: you chose your assistant, and what you write in it, like the calculator’s answer it receives, is governed by its provider’s privacy policy, which may process that data outside Québec. The link to the full calculator contains the calculation data (amounts, private portion numbers and their relative values, years, rates) and a mark of its origin (the connector), so the page opens with your figures. If you open it, this data appears in the page’s address, and therefore in your browser history.
• Information about a person with no account: when a syndicate migrates its history from another software, a service request may name the person who filed it even though they never held a CondoAide account — a former co-owner who has since sold, for instance. We then keep their name, and nothing else, so the request remains attributable; no email address and no phone number is carried over from the export for that purpose.
• Emergency contact designated by an occupant: someone filling in their occupancy record may designate a contact to reach in an emergency and record their name, the relationship between them, their phone number and, optionally, their email address. That person has no CondoAide account, and this information is visible only to the person who recorded it and to their syndicate's board. We never send them email: these details exist solely so the syndicate can reach them during an emergency affecting the unit, and they may appear in the book provided to fire services.
• Mention of a person in a message: when an authorized person names you with an "@" in a service-request thread or in a work-order comment, we keep the link between that message and you, so that we know who had to be notified. That link is not an access permission: it is filtered on write against who may already read the message, and it is re-checked on every read.
• Request filed by a tenant: when a tenant files a service request, we record at filing time that they filed it as a tenant, together with the private portion they occupy and to which the request relates. The request, its content, its attachments and the board's public replies, with their attachments, can then be viewed by the co-owners of that private portion, for requests filed since their ownership began; they cannot reply to it. When the board redirects the request to the co-owner, we keep that closing reason with the request.
• A syndicate's designation of its own person responsible for the protection of personal information: a syndicate of co-ownership is itself an enterprise under the Act, and designating that person and publishing their title and contact details is its own duty. When it does so in CondoAide, we keep what it publishes: the title, whichever contact details it chooses to make accessible — email, phone or mailing address — and, if it decides to include it, the name, which stays optional. The published contact details may be the syndicate's rather than the person's own. This is the syndicate's designation to its own members; ours is in section 7.
• Access or correction request addressed to a syndicate (Law 25): when you ask your syndicate, in the application, to see the personal information it holds about you or to have it corrected, we record the kind of request, its content, the date it was received and the date the written answer is due. When the syndicate's person responsible for the protection of personal information or its board of directors records a request received by mail, by email or in person, we also record the name of the person who made it and the email or postal address they gave for the answer. The person responsible or the board may note how the person's identity was verified; only they read that note. The written answer, its date and, for a refusal, its reasons and the provision of the law relied on are kept with the request. This information is read by the person who made the request, by the person responsible designated by the syndicate and by its board of directors, and not by the property manager unless they are the person responsible.
• A syndicate's register of confidentiality incidents (Law 25): when a syndicate's board of directors records a confidentiality incident in its register, we record what section 7 of the Regulation respecting confidentiality incidents requires: a description of the personal information involved, the circumstances of the incident, the date or period when it occurred and when the syndicate learned of it, the number of people involved, the assessment of the risk of serious harm, the dates of the notices sent to the Commission d'accès à l'information and to the people involved, any public notice and its reason, and the measures taken, as well as who made the entry and when, and its last change. The board writes these descriptions itself; they may mention people. This information is read only by the syndicate's board of directors, not by the property manager or the co-owners. An entry cannot be deleted in the application, because the law requires it to be kept for at least five years after the syndicate learned of the incident.
• Practical information written by the board of directors: free text a board addresses to its co-owners, its renters or its external accounts, which may contain third-party contact details — a caretaker, a supplier — depending on what the board chooses to include.
• A vendor invoice attached to a work order: when an authorized person attaches an invoice to a work order, the application can read its text in order to suggest the invoice date, its number, the vendor's name and contact details, its GST and QST registration numbers and the amounts billed. These suggestions never save themselves: the person keeps them one by one. The GST and QST registration numbers they keep are stored on the vendor record; where the vendor is a natural person in business, they concern that person. The reading is done in Quebec by our own document analysis service; neither the file nor its text is sent to an external service or to an artificial-intelligence model.
• The syndicate's declaration of co-ownership: when an authorized board member asks for it, or our support team does so to check the syndicate's configuration, the application reads the declaration of co-ownership filed in the syndicate's registry to compare it with what the syndicate has recorded (fractions and relative values, structure, fiscal year, spaces and restricted common portions). The declaration may name people, notably the original co-owners, the declarant and the notary. The text of its pages is kept only while the read runs, and destroyed as soon as it ends. Only the resulting proposal is kept: each value read, with the page and passage it comes from, with the names of people removed. The board decides each correction itself, and each decision is recorded with the person who made it. The read is done in Quebec by our own document analysis service. When its rules cannot read an item, the application may send, with no further action on your part, the text of targeted pages of the declaration to an Anthropic artificial intelligence model in the United States so that it proposes the missing item: the application removes the names of people it detects before sending, the pages it recognizes as those where they concentrate (appearance before the notary, signatures, interventions) are not sent, a request in which an apparent name remains is cancelled, and the file itself is never transmitted (section 3).
• Document uploaded to the free declaration of co-ownership reader: a person without an account can upload a declaration of co-ownership as a PDF to the free public tool. The application reads its text with fixed rules, without any artificial intelligence service, to show the table of fractions, the spaces, the restricted common portions, the fiscal year and the number of directors, each with its page. The document may name people, notably the original co-owners, the declarant and the notary. No account, name or email is asked for; only the person holding the token given to their browser at upload can view or delete the result. The IP address is used, scrambled with a secret key whose value changes with each period, to limit the number of reads; it is not kept in readable form. If they then choose “Create my syndicate with this data”, sign up and create their syndicate, a copy of the document and the result of the reading are filed in that syndicate’s registry, under the access rules of the “Declaration of co-ownership” category; no value read is carried into the syndicate’s data until a board member accepts it. The link that carries this choice through sign-up does not contain the person’s token; it works once and expires with the reading. Anyone holding this link could use it; opened in a browser other than the one where the person clicked, it leads to a confirmation where the board chooses whether to file the document.
• RBQ register answer about a vendor's licence: when one of the syndicate's vendors has a Régie du bâtiment du Québec licence number, we keep with the vendor's record what the public register says about it: the holder name listed in the register, whether the licence is in the register, whether a restriction applies, the date the licence left the register if it did, and the date of the check. When the vendor is a person in business, that name concerns them. The check is made with VériBât when the number is entered or changed, then repeated automatically about every two days. The answer is read by the people of the syndicate who manage its vendors, its work or its finances, is used to warn them of a licence that is not in the register or is restricted, is removed with the vendor's record, and is replaced as soon as its number changes.
• Request for a statement of common expenses due for a unit: when a person who proposes to acquire a unit, or their notary or broker, asks the syndicate for the statement of common expenses due (art. 1069 of the Civil Code of Québec), the board records that person's name, their capacity, the name of the buyer they represent, their email address, the request date, the notice given to the owner (method, date and note) and the date the statement was sent. When the board sends the statement by email, the person receives a link to the document, valid for 30 days; each viewing of that link is logged with its date and time, the originating network (a truncated IP address, which identifies or locates no one) and the browser type, to establish that the statement was provided. The issued statement shows the unit's common expenses due and unpaid, its contribution under the latest adopted budget and the upcoming installments of adopted special assessments; it does not name the owner.
• Invoice issued by the syndicate: when the board of directors bills a fee to a person on the syndicate's behalf (for example the fee for producing an attestation or a statement of common expenses), it records that person's name, the name of the intermediary through whom they receive it ("c/o", for example their broker or notary), their mailing address, their email address when provided, the unit concerned as a reference only, the invoice's details and amount, its dates and, once paid, the payment date and method. This person may be a co-owner or someone who does not use the Service. When the board sends the invoice by email, the person receives a link to the document, valid for 30 days; each opening of that link is recorded with its date and time, the originating network (truncated IP address, which can neither identify nor locate a person) and the browser type. The invoice is never charged to the unit's account.
• Request and delivery of a syndicate attestation: when an attestation is requested for the sale of a unit (art. 1068.1 of the Civil Code of Québec), the board keeps the requester's name, whether they act as the seller's mandatary, their role when they are a mandatary (broker, notary or other), the mandatary's name, the reason for the request, and the email address chosen to receive the signed attestation. The attestation may include the financial and administrative information that the law requires about the unit and the syndicate. It is delivered to the current co-owners in the Service and, when that email address is recorded, to the requester or mandatary through a link valid for 30 days, without waiting for payment of a fee. Every opening of that link is logged with its date and time, the truncated originating network, and the browser type. If the immovable's by-laws allow a fee, the invoice addressed to the seller, c/o their mandatary, may accompany the attestation through a second link; it is never charged to the unit's account.
• Sale file for a unit: when a sale is announced, or as soon as an attestation or a statement of common expenses is requested for a unit, the board keeps a file that follows the sale until the buyer arrives. When it knows them, it records the name and email address of the prospective buyer, the real estate broker and the notary, the date of the promise to purchase and the expected signing date; these fields are first copied from the attestation or statement request. The file also records the request for documents made by the prospective buyer (art. 1068.2 of the Civil Code of Québec): its date, the date the documents were provided, the date of the copy given to the owner and a note, as well as the reason a file was abandoned. It names the seller or sellers from the register of co-owners, even after they leave the syndicate. Only the board members, or the manager, authorized to manage attestations see this file.
• Request for authorization to do work in a private portion: when a co-owner asks the board of directors for authorization to do work in their private portion, or the board records that request on their behalf, we collect the description of the planned work, its location in the private portion and the planned start and end dates, together with the request's status (submitted or withdrawn), the date of any withdrawal and who withdrew it. This information is read by the board and by the person who filed the request, and is used to review it. When the work will be done by a contractor, we also collect the company's name, its Régie du bâtiment du Québec licence number and, if the person provides them, a contact person's name and email address. So that the board knows whether the licence is in force, we check that number with VériBât, which consults the Régie's public register: only the licence number is sent to it, and we keep its answer (the holder's name in the register, whether the licence is in the register, whether it carries a restriction, and the date of the check). This information is read by the same people as the request. Once the work is authorized, the co-owner, or the board on their behalf, may send the contractor the work rules the board has written, through a personal link sent to the email address they provide; nothing is sent to the contractor without that step. The email names the co-owner and the building, and the contractor's replies go to the co-owner. When the contractor opens the link, we keep the date, the truncated originating network (IPv4 /24, IPv6 /48) and the browser family. If they sign their undertaking to follow the rules, we keep the name they type, the address the link was sent to, the licence number, the signed version and its fingerprint, the date and time, and the IP address and browser used, as section 39 of the Act to establish a legal framework for information technology provides. This information is read by the board and by the person who filed the request; the IP address and browser of the signature are not displayed. When the board authorizes the work, we open your private portion's entry in the syndicate's register of improvements (art. 1070 of the Civil Code of Québec) and copy into it the description and location of the work, the planned start date, the reference of the decision and its conditions, and the company's name and licence number; the contact person's name and email address are never copied. While the work is still planned, that entry is read only by the owners of the private portion and by the board; once the work is reported as finished, it is read by the syndicate's co-owners, like the rest of the register. You may add photos taken before and after the work, the invoice and an approximate value, then report the work as finished; the board confirms completion and sets the improvement's category. None of these files is required. Photos, the invoice and the approximate value are read only by the owners of your private portion, by the board and, where applicable, by the property manager; they are not visible to other co-owners. We also keep who reported the work finished and when, and who confirmed it. Two days before the planned start date, and again after the planned end date, we send you an email reminder and an in-app notification; the reminder names the request and your private portion, and blocks nothing.
• Device key used as a second factor (Touch ID, Face ID, security key): if you add a device key to your account to confirm your identity, we keep the key's identifier, its public key, its signature counter, the connection methods the device declares, the date and session in which it was added, the name you give it, if any, and the date it was last used. When you use it, we also record, for that session only, that the key was verified and when. No biometric data is sent to us: your fingerprint or face never leaves your device, and we receive only a public key and a signature. If you have no second factor yet, a one-time code is sent to you by email, through the email service described in section 3, before you add your first key; otherwise, adding a key requires a session already confirmed with your second factor. The same emailed code is required before you add a first authenticator app. If you then add an authenticator app, we record its approval by means of your key (time and session). If you lose your device, our support team can remove a key after verification; the removal is logged and you are notified by email. If your key is synced by a password manager you chose (iCloud Keychain, Google, 1Password), that provider also keeps an encrypted copy to deliver it to your devices, possibly outside Québec; CondoAide sends it nothing, does not choose that provider, and never knows the private key.
• Second-factor recovery codes: when you add your first second factor, and each time you ask for new ones, we create ten single-use codes. They are shown to you only once; we keep only an irreversible fingerprint of each code, with the date they were created and, for a used code, the time and session in which it was used. A used code completes only the sign-in in progress. We also count wrong codes: after five attempts within an hour, the codes are blocked for one hour. We keep the date a code was last used, which serves to protect your account's financial operations after a recovery. Each creation of codes, each use and each block is reported to you by email, through the email service described in section 3; no code appears in it.
• Welcoming the person who buys a private portion: when the board of directors records the sale of a private portion, it may record, for each person who buys, their residence status, their postal address when they do not live in the private portion and, if they do not yet have a CondoAide account, a contact email to invite them to create one. The invitation may contain the welcome message the syndicate wrote, or a text written for that sending only. After the sale, the person who buys receives a notice of the obligations to fulfil for their private portion, for example proof of insurance. The proofs the departing person had filed are reset: their former values are recorded in the syndicate's activity log, which only people authorized to manage proofs can read, and the arriving person sees neither those proofs nor the documents attached to them. The departing person's proxies are revoked and the members of their household linked to them are deactivated.
• Your choice to include your email and phone number in the co-ownership register: the register the syndicate keeps available to co-owners contains the name and postal address of each co-owner; it may contain other personal information about a co-owner or another occupant only if that person expressly consents (art. 1070 of the Civil Code of Québec). If you have an account, you decide, for each syndicate you are a member of and separately for your email and for your phone number, whether to include them. This choice is optional and nothing is checked by default. We keep each of your decisions (consent, refusal or withdrawal), its date and the version of the text shown to you, without copying your email or your number; a withdrawal is added to the history without erasing earlier decisions and applies going forward. Without your consent, your email and phone number remain readable by the board of directors and, where applicable, by the syndicate's manager, to administer it; they also see the date of your consent when you have given it. Another co-owner of the private portion you occupy or hold sees your email or your number only if you have consented to include it in that syndicate's register. Your decisions are read by you and by the people authorized to manage the syndicate's members, and each change is recorded in the syndicate's activity log without your email or your number.
• Meeting held in CondoAide: a person who joins a meeting through the invitation link (/reunion) gives the name shown to the other participants; we keep that name, the decision to admit them or not and who made it. When that person is signed in to CondoAide and is a member of the syndicate (co-owner, tenant, director or manager), we tie their account to their participation. Participants' image and voice are relayed in real time by our video-conferencing server (section 3).

2. Use of Information

We use your information to:

• Provide and improve our condo management services
• Preview insurance-certificate imports, verify their integrity, and produce minimized per-unit proofs
• Read, at an authorized person's request, an invoice attached to a work order in order to suggest the data to record, and file a copy of it in the syndicate's registry under the Invoices category, accessible to the board of directors only
• Process your payments and manage your subscription
• Send you important communications about your account
• Establish, at the request of the syndicate or a co-owner, that a notice or convocation was in fact sent, and to which address
• Inform you of updates and new features, and send you the CondoAide newsletter only if you asked for it: the sign-up box is never pre-ticked, and the subscription starts only once your address is confirmed. You can unsubscribe at any time from your profile or through the link in every newsletter
• Notify you when an authorized person names you in a service-request or work-order thread: the notice is delivered in the platform and by email, and the email repeats an extract of at most 500 characters of the message so you know what it concerns without having to open the platform. The extract is sent only to people who may already read that message.
• Notify the co-owner who receives a private portion's notices when that portion's tenant files a service request, and notify the tenant and that co-owner when the board redirects the request to the co-owner: the notice is delivered in the platform and by email.
• Publish, on a syndicate's behalf and to the members it addresses, its own designation of a person responsible for the protection of personal information, the documents its board addresses to them, and the practical information it adds
• Allow a syndicate to receive and follow up the access and correction requests that the persons concerned address to it, and to answer them in writing (ss. 27 to 35 of the Act respecting the protection of personal information in the private sector), then email the answer to the person who made the request when they gave an email address
• Allow a syndicate to keep its register of confidentiality incidents, keep it up to date and produce a copy when the Commission d'accès à l'information asks for it (s. 3.8 of the Act respecting the protection of personal information in the private sector)
• Ensure compliance with the Loi visant principalement l'encadrement des inspections en bâtiment et de la copropriété divise (S.Q. 2019, chapter 28, commonly called "Bill 16"), the regulation adopted under decree 991-2025, and other applicable regulations
• Respond to your support requests and, from the optional feedback given on a resolved report, improve our support
• Detect and prevent fraud, abuse, and violations of our Terms of Service
• Produce, at the request of a person who proposes to acquire a unit, the statement of common expenses due that the syndicate is authorized to provide after notifying the owner (art. 1069 of the Civil Code of Québec), notify that owner by email or record a notice given another way, send the statement to the requester as a link by email and log its viewings to establish that it was provided, and file the statement in the syndicate's registry, accessible to the board of directors and, for their own unit, to the notified owner
• Bill a fee to a person on the syndicate's behalf, send them the invoice through a link sent by email, record its openings to establish that it was delivered, and record its payment in the syndicate's income
• Produce the syndicate attestation requested for the sale of a unit (art. 1068.1 of the Civil Code of Québec), have it signed electronically, deliver it to the current co-owners and to the requester or designated mandatary through a link sent by email, log openings of that link to establish delivery and, when the immovable's by-laws allow it, include the fee invoice without delaying the attestation
• Follow the sale of a unit in a single file: order the steps the law provides (attestation, statement of common expenses due, documents requested by the prospective buyer, change of owner, debit mandate and the buyer's arrival), show the 15-day deadlines calculated from the dates recorded, and record the delivery of the documents requested by the prospective buyer and the copy given to the owner (art. 1068.2 of the Civil Code of Québec).
• Keep the register of co-owners when a private portion changes hands (arts. 1065 and 1070 of the Civil Code of Québec): record the transfer and the notice received from the acquirer, notify the new co-owner, revoke the departing co-owner’s debit mandate where needed by notifying the payer and requesting cancellation of debits after closing, and invite the new co-owner to authorize the debit of condo fees
• Receive and handle misuse reports and delivery-failure notices sent to postmaster@ and abuse@ at a syndicate address, to keep those addresses able to send and receive mail
• Offer a signed-in person a demo syndicate, filled with fictional data, to try the Service before entering their own syndicate: the emails it produces do not leave it (they are kept as "simulated" and shown in the demo), no payment is collected in it, and nothing is copied from it to a real syndicate. The artificial intelligence features offered in the demo send content to Anthropic as described in sections 3 and 9. We encourage you to use the fictional data provided; any information you enter in it, including about other people, is destroyed with the demo
• Welcome the person who buys a private portion: enter them in the syndicate's register of co-owners (art. 1070 of the Civil Code of Québec), invite them to create their account, send them the syndicate's welcome message and notify them of the obligations to fulfil for their private portion, without letting them see the departing person's proofs
• Keep the co-ownership register (art. 1070 of the Civil Code of Québec): include your email or phone number only with your express consent, given separately for each and for each syndicate, show them to another co-owner of your private portion only with that consent, and keep proof of your decision and of its withdrawal
• Let the board split the cost of a loss between the syndicate, its insurer and a co-owner, record the claim the syndicate makes against a co-owner responsible for the damage (art. 1074.2 of the Civil Code of Québec), with its basis, the facts and its status, and bill the accepted amount to the account of that co-owner’s private portion

3. Sharing of Information

We do not sell your personal information. We share certain information with the following sub-processors, who act on our behalf and are bound by a data processing agreement:

• Supabase — Database hosting and file storage. Categories: all application data. Location: Canada (ca-central-1 region, Montreal).
• Vercel — Web application hosting. Categories: application traffic, no permanent storage. Location: Canada (Montreal / yul1 region) — application execution and its logs stay in Quebec. Vercel Inc. is a US company; the processing is framed by its data processing agreement (DPA).
• Stripe — Subscription payment processing (credit cards + PAD/ACSS Debit bank withdrawals from the syndicate to CondoAide) and automatic condo-fee collection by pre-authorized debit (PAD/ACSS) from co-owners to the syndicate's account. Categories: payer name, email, billing address, payment method, banking information of co-owners who enabled the debit, technical account identifier of the person authorizing a private portion’s mandate, that private portion’s identifier, and subscription and condo-fee transaction history. Location: Canada and United States.
• Amazon Web Services (Amazon SES) — Delivery of the Service's transactional emails (confirmations, notices, reminders) and of authentication emails (account confirmation, sign-in link, password reset). Categories: recipient email address and name, email subject and content, delivery logs (deliveries, bounces, complaints). Location: Canada (ca-central-1 region, Montreal). Emails and their delivery logs are processed in Quebec. Amazon Web Services, Inc. is a US company; processing stays in Canada and is covered by the AWS data processing agreement (DPA). This is the same link we already have indirectly, since Supabase's infrastructure also runs on AWS in Canada. Amazon also handles reception of emails sent to syndicate mailboxes, where that option is active: it receives the message, scans it for spam and malware, and places it temporarily, for at most 30 days, in encrypted storage in the same region, before we load it into our own database in Quebec. Amazon also forwards emails sent to postmaster@ and abuse@ at a syndicate address to CondoAide's operations mailbox, within the same region.
• Brevo — Marketing emails and management of our contact lists (newsletter, non-essential communications). Also serves as the fallback relay for transactional emails when the primary send fails. Categories: email addresses, name, communication preferences, email content. Location: European Union.
• Cloudflare (Turnstile bot check) — Bot check on public forms: signing in, signing up, password reset, the contact form, requests to a professional, testimonials, newsletter sign-up, the reserve fund calculator report and the free declaration of co-ownership reader. The browser sends Cloudflare technical data (IP address, browser and device characteristics, interaction signals) to tell a person from a bot; Cloudflare only returns a validation token to us. No form content and no document is sent to it. Categories: IP address and browser technical data. Location: Cloudflare's global network, outside Quebec; conditions in section 9.
• Anthropic (AI assistant) — Artificial intelligence model that writes the AI assistant's answers. Each question is sent with the latest exchanges of the conversation, the syndicate's name, the person's role in the syndicate (for example "Co-owner"), so that it only points them to screens they can open, and excerpts of the syndicate's registry documents that the person can read, retrieved for the question; these excerpts are not redacted and may name people. Categories: question, conversation, role, document excerpts. Location: United States; terms in section 9.
• Anthropic (the syndicate's insurance policies) — Reading one of the syndicate's insurance policies, on request. When a person chooses "Analyze PDF with AI" for one of the syndicate's insurance policies, the first 10 pages of the file and its name are sent to extract the form's fields, which the person reviews before saving. Co-owners' proofs of insurance are not sent to it to be read: they are read in Quebec by our self-hosted document analysis service (below). Categories: the syndicate's insurance policy, which may name a director or a signatory. Location: United States; terms in section 9.
• Anthropic (analysis, drafting and translation) — Features a person triggers themselves. "Analyze with AI" sends up to 8,000 characters of a registry document's text, or the data of a document produced in the application, without redaction; "Generate with AI" and "Improve with AI" send the syndicate's name, the chosen instruction and the text already entered; the translation buttons send the text to translate (announcement, message, survey question and its choices, obligation, access agreement, syndicate document or dashboard card). For a communication sent with “Notify and track reads”, whose content stays in CondoAide, only survey questions and their choices can be translated by AI, and the writing screen says so next to the button; message translation and AI drafting are not offered there. They are offered when the full content is emailed. These texts may name people. Categories: registry texts and documents, which may name people. Location: United States; terms in section 9.
• Anthropic (reading the declaration of co-ownership) — Fallback reading of the declaration of co-ownership (section 1), when its rules cannot read an item: the text of targeted pages (at most 8 per request, 12 for the table of fractions), from which the application removes the names of people it detects before sending; the pages it recognizes as the preamble, the appearance before the notary, signatures, interventions or an amending deed are not sent, and a request in which an apparent name remains is cancelled. No action by the user is needed: the request happens during the read the board of directors or our support team asked for. The log of each request holds only the model used, the items asked for, the pages sent and the number of names removed, never the text; only the redacted passages that support a proposed value are kept with the proposal. Categories: text of declaration pages, names of people removed. Location: United States; terms in section 9.
• OVHcloud (self-hosted document embeddings) — Hosts our self-hosted embedding model (bge-m3): text from registre documents at every access level is converted into numeric vectors for authorized search. Access remains governed by the source document's classification; the AI assistant searches only documents shared with all co-owners. Categories: text extracted from registre documents. Location: Canada (Beauharnois, Québec). Self-hosted software; no data leaves Québec and the operational sub-processor is OVHcloud.
• OVHcloud (self-hosted document analysis) — Hosts our self-hosted document analysis service: it reads the PDF files an authorized person imports, and the scanned images of an invoice through optical character recognition (maintenance log, reserve fund study, the syndicate's bank account statement, a vendor invoice attached to a work order and the syndicate's declaration of co-ownership) to extract the tasks, study data, transactions or invoice data the person reviews before keeping them. The file is read during the analysis and then discarded by this service; only the data the person keeps is saved in the application. It also reads each proof of insurance filed for a unit, by the co-owner or by the board, or imported in bulk, including a photo, to extract the insurer, the policy number, the coverage dates and the coverage amounts, which the board reviews; the file is sent to it without its name, and the text read is not kept. For the declaration of co-ownership, read at the board's request, the page text is kept in the application while the read runs, then destroyed; only the resulting proposal, with the names of people removed, remains while the document is in the registry (section 5). Categories: content of imported documents, including, for a bank statement, transaction dates, amounts and descriptions, which may name a co-owner, a supplier or another payee, and, for an invoice, its date, its number, the vendor's name and contact details, its GST and QST registration numbers and the amounts billed, and, for a proof of insurance, the insured's name and address, the insurer, the policy number, the dates and the coverages. Location: Canada (Beauharnois, Québec). Self-hosted software; the operational sub-processor is OVHcloud.
• OVHcloud (self-hosted OpenReplay) — Hosts our OpenReplay installation: product telemetry + session recording for technical support. Categories: pseudonymized user identifier, interaction events (pages visited, features used), technical metadata (browser, OS), visual reconstruction of navigation with automatic masking of form fields and sensitive screens. Location: Canada (Montréal, Québec). Self-hosted software — OpenReplay Inc. is not a sub-processor; the operational sub-processor is OVHcloud (hosting and storage).
• OVHcloud (self-hosted GlitchTip) — Hosts our GlitchTip installation: application error and exception tracking, plus application logging. Categories: exception stack trace, log messages, pseudonymized user identifier, URL where the error occurred, technical metadata. Request bodies (form data, authentication headers, cookies) are automatically dropped before storage. Location: Canada (Montréal, Québec). Self-hosted software — the GlitchTip team is not a sub-processor; the operational sub-processor is OVHcloud.
• OVHcloud (self-hosted Plausible) — Hosts our Plausible installation: cookieless, aggregate web analytics (visitor count, pages viewed, traffic sources, city and country) on the public pages of the site. No direct personal information is captured: no cookies, no persistent visitor identifier, no device fingerprint. The IP address is used momentarily to determine the city, then immediately discarded; it is never stored. Statistics are aggregate. Location: Canada (Montréal, Québec). Self-hosted software — the operational sub-processor is OVHcloud.
• OVHcloud (self-hosted video-conferencing server) — Hosting for our video-conferencing server (LiveKit), which relays audio and video for assembly meetings held online. The stream passes through in real time and is not recorded: no meeting is retained, by us or by the host. Categories: participants' image and voice during the meeting, display name, connection timestamps. Location: Canada (Beauharnois, Quebec). Self-hosted software — LiveKit Inc. is not a sub-processor; the operational sub-processor is OVHcloud.
• iDrive e2 (off-site backups) — Storage of our backups: a copy of the database every four hours and a daily copy of uploaded files (registry documents, attachments). The backups retain the information entrusted to the Service. Vector search indexes and their processing queue are not copied because they are rebuilt from source files after a restore. Categories: every category described above. Retention: 30 days. Location: Canada (Montreal, Quebec).
• OVHcloud (secondary backup copy) — A second copy of the same backups, synchronised once a day from iDrive e2, so that the failure of a single provider cannot take the backups with it. Same categories and retention as iDrive e2. Location: Canada (Beauharnois, Quebec).
• OVHcloud (backup production) — Hosts the job that produces our backups: every four hours it reads the database and encrypts the copy on this server before sending it to iDrive e2; once a day it copies uploaded files to iDrive e2, then synchronises the secondary copy. Data only passes through this server during each copy; no backup is kept there. Categories: every category described above. Location: Canada (Beauharnois, Quebec). Self-hosted software; the operational sub-processor is OVHcloud.
• VériBât, another service of Solutions Nicvi inc. VériBât is operated by the same company as CondoAide: it is not a sub-processor, and the information sent to it does not leave the company. It uses it only to answer the check CondoAide asks for, never for its other activities. Checking the Régie du bâtiment du Québec licence number of a contractor against the Régie's public register, when a co-owner names the contractor in a work authorization request or the board of directors adds it to its vendors, then about every two days for the syndicate's vendors. Categories: the licence number, or the text typed to find it (the start of a number or a company name, which may be the name of a person in business); no other information is sent. VériBât returns at most ten entries from the public register (number, holder name and other names, municipality, licence status), never contact details. VériBât does not keep that text; it keeps the number only in the log of a check that failed. Location: Canada (Montreal region / yul1).
• Aggregate web analytics — cookieless. To measure overall traffic on our public pages (visitor count, most-viewed pages, traffic sources, city and country breakdown), we use a self-hosted Plausible installation on the same OVHcloud infrastructure in Montréal. Plausible sets no cookies on your device, stores no persistent identifier, and captures no direct personal information. The IP address is used momentarily to determine the city, then immediately discarded; it is never stored. Statistics are aggregate and are not linked to an identifiable visitor. This aggregate measurement runs for all visitors regardless of your cookie banner choice, because no personal information is involved. Retention: 24 months.
• This list is updated when we add or remove a sub-processor. Significant changes will be communicated through this policy and by email.
• Members of your syndicate and its mandated manager: depending on the permissions configured in your account, certain information may be visible to other members of your syndicate (for example, your name and payment status may be visible to administrators and the treasurer). When your syndicate entrusts its management to a property management company and adds it to its account as manager, that person has access, to carry out its mandate, to the syndicate's financial information: budgets, accounting entries, contributions, co-owners' payment information (debit mandates, payment history, arrears) and vendors' payment details. The manager cannot adopt a budget, decide a special assessment or alone approve a payment above the threshold set by the board of directors.
• Legal authorities: we may disclose your personal information if required by law, by court order, or to protect our rights, your safety, or that of others.
• Insurer and incident responders: we carry professional liability and cyber insurance with CFC Underwriting Limited, on behalf of Lloyd's underwriters. In the event of a confidentiality incident only, information about you may be disclosed to the insurer and to the providers on its approved response panel (CFC Response), for technical investigation, legal defence, crisis communications and preparing the notices required by law. These providers act under mandate and are bound by confidentiality. They operate from the United States and the United Kingdom; see section 9. Nothing is disclosed to them outside an incident.
• Commercial transaction: if another business acquires or considers acquiring our operations or assets, or if we undergo a reorganization or a financing, we may have to share your information with the other parties involved. Unlikely as it is, we must disclose it.

4. Data Security

We take the security of your data seriously:

• Encryption in transit: TLS 1.3 between your browser and our servers
• Encryption at rest: AES-256 on the database, backups and stored files
• Passwords: hashed with bcrypt (never stored in plain text, never reversible)
• Authentication tokens: cryptographically signed with ECDSA on the P-256 curve (ES256); the signing key is never shared with the services that verify tokens
• Authentication: secure authentication, with a second factor of your choice: an authenticator app or a device key (Touch ID, Face ID, security key), and single-use recovery codes if you lose your device
• Hosted in Quebec: application served by Vercel (Montreal / yul1 region); database and stored files on Supabase (ca-central-1 / Montreal region). Your condo association data is hosted in Canada. Some of it is sent outside Canada, notably for subscription payments and for artificial intelligence features; these cases are described in section 9.
• Access controls: strict role-based permissions, logging of all sensitive actions
• Backups in Quebec: Supabase backups with point-in-time recovery (7 days) and daily snapshots; additional backups kept at two distinct Quebec providers (Montreal and Beauharnois), 30-day retention
• Tokenization: bank and credit card information is never stored in plain text on our servers — it is tokenized by Stripe (PCI DSS Level 1 certified for card data)
• Certified sub-processors: Supabase, Vercel and Amazon Web Services are SOC 2 Type 2 certified; Stripe is SOC 2 Type 2 and PCI DSS Level 1 certified
• We commit to an annual third-party penetration test ("pentest").

5. Data Retention

We retain your information as long as your account is active or as required by law. Specific retention periods:

• General account data — 90 days after account closure, unless otherwise required by law.
• Demo syndicate and everything you enter in it — Destroyed, together with the information and files you entered or uploaded, as soon as you reset or delete it, or 30 days after the last activity in the demo, whichever comes first. Activity means opening its dashboard in a new browsing session, or an action recorded in the demo. The scheduled date is shown in the demo's banner. Encrypted residual copies may persist in backups for an additional period of up to 30 days before they are rotated and destroyed.
• Daily usage counters of a demo — The number of artificial intelligence requests and demo creations you make each day, kept to enforce the demo's daily limits, is destroyed 7 days after the day counted.
• Condo documents (registers, log book, attestations) — According to the periods prescribed by the Loi visant principalement l'encadrement des inspections en bâtiment et de la copropriété divise (S.Q. 2019, chapter 28, "Bill 16") and the Civil Code of Quebec.
• Reading of the declaration of co-ownership (page text, proposal, board decisions) — The page text is destroyed as soon as the read ends. The resulting proposal (the values read, with the cited page and passage, with the names of people removed) is kept while the declaration remains in the syndicate's registry; it is destroyed when the document is moved to the trash or deleted, and when a newer read of the same document replaces it, unless a board decision cites it. Board decisions (correction applied or set aside, cited passage, person who decided) are kept for as long as the syndicate's file exists and destroyed with it; the person's identifier is removed when their account is deleted. Encrypted residual copies may persist in backups for an additional period of up to 30 days before rotation and destruction.
• Free declaration of co-ownership reader (uploaded file, page text, result) — The page text is destroyed as soon as the reading ends. The uploaded file and the result are deleted 24 hours after the upload, or as soon as the person chooses “Delete now”. A refused file (too large, unreadable, over 100 pages) is deleted at once. Nothing is indexed or reused. When the person files the reading in the registry of a syndicate they create, the tool’s copy is deleted at the transfer or, at the latest, when the reading expires; the filed document then follows the retention periods of registry documents.
• Temporary aggregate PDF for an insurance-proof import — Until the import succeeds or reaches a terminal failure, is cancelled or replaced, or for no more than three hours, whichever comes first. The aggregate file and its extracted text are then deleted from production systems. Residual encrypted copies may persist in backups for up to 30 additional days before rotation and destruction.
• Co-owners’ proofs of home insurance (certificate, insurer, policy number, coverage dates and amounts) — Three years after the end of the coverage the proof attests, the period during which a claim arising from a loss that occurred during that coverage can still be brought (art. 2925 of the Civil Code of Québec). Until the board of directors has confirmed the end of the coverage, the period runs from the date the proof was filed.
• Claim records (description, private portions affected, follow-up, links to documents, work and transactions, claims made against a co-owner) — Five years after the date of the loss or three years after it was resolved, whichever is later; when the record was modified after its resolution, the three years run from its last modification. The loss must appear on the syndicate’s attestation for five years (Décret 991-2025, art. 10), and this period covers the three-year prescription of any action that may arise from it (arts. 2925 and 2926 of the Civil Code of Québec). A record deleted by the board is destroyed 90 days after its deletion, whatever its status. Otherwise, a record that is still open, or that carries an unsettled claim against a co-owner, is never destroyed. Linked documents follow the period of their own category and condo-fee transactions are kept 7 years; when the record is destroyed, the claim’s title is removed from the description of billed claim charges. A scheduled task carries out the destruction nightly. Encrypted residual copies may persist in backups for an additional period of up to 30 days before they are rotated and destroyed.
• PAD mandate for subscription payment (metadata held by us; signed document retained by Stripe on our behalf) — 7 years after the mandate ends, for tax, accounting and legal-compliance purposes.
• Subscription transaction data (payments to CondoAide) — 7 years for tax, accounting and regulatory compliance purposes.
• Co-owner condo-fee collection PAD mandate (Payment Service, metadata held by us, signed document retained by Stripe on the syndicate's behalf) — 7 years after the mandate ends, including the identity of the person who authorized it and whether or not they were a co-owner on that date, for tax, accounting and legal-compliance purposes.
• Authorization attempts for a private portion’s PAD mandate (person who opens the authorization and their co-owner status) — 30 days when the authorization is not completed; seven years after its use when it is, that is the retention period of the mandate it served to establish. A scheduled task destroys them.
• Proof of revocation of a private portion’s PAD mandate (revocation, notice to the payer and cancellation requests for the debits concerned) — Seven years after the revocation, the mandate’s own retention period, for tax, accounting and Payments Canada Rule H1 compliance purposes. The identity of the board member who revoked the mandate is kept for 12 months.
• Invitations sent to a new co-owner to authorize the debit of condo fees — 12 months after sending. A scheduled task destroys them nightly.
• Ownership transfer record for a private portion (parties, shares, closing date, date the acquirer’s notice was received) — Kept with the syndicate’s file, as the register of co-owners over time (art. 1070 of the Civil Code of Québec), and destroyed with it. The board member who recorded the transfer is removed from the record if their account is deleted.
• Condo-fee transaction data (co-owner debits via the Payment Service) — 7 years for tax, accounting and regulatory compliance purposes.
• Assembly meeting chat (side channel during a virtual meeting) — Kept with the assembly record for as long as it exists — at minimum beyond the 90-day contestation period of art. 1103 CCQ. These messages are never reproduced in the minutes or filed in the syndicate register; a message's author may request its removal at any time.
• Assembly-meeting presence log (participant connections and disconnections) — Kept with the assembly record for as long as it exists — at minimum beyond the 90-day contestation period of art. 1103 CCQ. This log is corroborating evidence of who was actually connected during the sitting; it does not replace the official attendance sheet of the minutes (art. 1102/1103 CCQ). Hosted in Quebec (Supabase, Canadian region).
• Identity of the person who enabled automatic collection of condo fees — The field recorded on the syndicate's profile remains for as long as the syndicate uses the Service, including after automatic collection is turned off — turning it off does not make it untrue that it was turned on. It is replaced as soon as another person turns the collection back on. The corresponding audit-log entry, and the authorisation attached to the debits already made, follow the 7-year period for sensitive-action logs and payment records, and that period governs: for as long as those records are kept, so is the identity of the person who authorised those debits.
• Identity of the person who declared what the declaration of co-ownership provides for contributions paid before the budget was adopted — The person's identifier, the date and the cited article recorded on the syndicate's record remain for as long as that answer stays in effect, and are erased as soon as another answer is saved. Deleting the person's login account does not erase the identifier: it attests who made the declaration on the syndicate's behalf, and it is destroyed with the syndicate's file. The corresponding audit-log entries, which carry the person's name and email address, follow the 7-year period for sensitive-action logs.
• Proxies filed in the syndicate's registry (mandate to be represented at a meeting and, where applicable, the voting instructions it contains) — Kept permanently in the syndicate's registry, with the minutes of the meeting whose quorum and vote count they establish. The law prescribes no period for these documents; we follow the practice recommended by the Regroupement des gestionnaires et copropriétaires du Québec (RGCQ), which keeps them permanently. A standing proxy can also remain in force for several years.
• Proxy registration log (mandate to be represented at a meeting) — Retained as long as the syndicate's file exists, and destroyed with it. This log records the electronic registration of the mandate: the time of signature, the IP address and the browser used, as section 39 of the Act to establish a legal framework for information technology requires for an electronic signature. It now outlives deletion of the proxy itself, which lengthens its retention compared with the previous behaviour: deleting a mandate used to erase the proof that it had existed, and that proof matters precisely when a proxy disappears. The link to the mandate is severed at that point, but the entry stays attached to the syndicate concerned and readable by its board.
• Acknowledgements and signed access agreements (syndicate documents, role agreements) — Kept for as long as the syndicate's file exists, and destroyed with it. Each row attests that a person read a specific version of a document — governance policy, privacy policy, building by-laws, access agreement — and records the moment of signature, the IP address and the browser used, as section 39 of the Act to establish a legal framework for information technology provides. The row is append-only: it cannot be altered or deleted on its own, or it would prove nothing. Deactivating a document does not remove acknowledgements already collected, since the reading did happen. The syndicate's board can see who signed what and when; a co-owner sees only their own.
• Audit logs (sensitive actions) — 7 years for compliance purposes.
• Support communications — 3 years after the last interaction. A file attached to a support message is deleted three years after the message is sent; a file uploaded for a message that is never sent is deleted at most four hours after it was uploaded. Feedback given on a resolved report, and its comment, follow the same retention as the report and are deleted with it.
• Outbound email queue (notices, convocations, reminders) — 90 days after sending. The queue holds the recipient's address and the data used to compose the message: greeting name, unit number, and the details specific to the notice. The rendered message is not kept. This period is operational: it covers delivery follow-up and bounce handling. For most notices, the record of sending also appears in the file the notice belongs to. Convocations to an assembly or a board meeting, their updates, agenda additions and reminders are different: for those, the queue is currently the only place the recipient detail exists. Those rows are kept until 90 days after the assembly or meeting concerned, then deleted; that is the period a co-owner has to ask the court to annul an assembly decision (art. 1103 CCQ). A row whose sending failed for good is deleted 30 days after that final failure.
• Emails received in the syndicate's mailbox (message, attachments, sender address and other named recipients) — 36 months from reception. Text of the email copied elsewhere in the syndicate's file, such as into a service request, a survey answer or a message reply, is removed at the same moment, and the request or the answer remains, showing a dated notice where the text was. A copy of an email CondoAide sent for the syndicate or in its name that comes back into the mailbox (for example through the automatic forwarding of another of the syndicate's addresses) is not received correspondence: it is destroyed by the daily destruction run that follows its reception. An email filed to a record (work order, contract, litigation) or under a legal hold is kept for as long as that filing or hold lasts.
• Board reply or new email sent from the syndicate's mailbox — 36 months from sending, with the same exceptions as the email it answers. A new email from the board is kept as long as a reply received in the same conversation is. The name and address of its recipients, including blind copies, are kept with it and destroyed with it. A legal hold on a person also applies to emails where that person was copied.
• Log of emails sent from the syndicate's address (sending address, recipient address, date and time) — 7 years from sending. The log does not hold the message itself; it establishes that a notice, a notice of meeting or a reply left from the syndicate's address, to whom and when.
• Files attached to a board email sent from the syndicate's mailbox (file, link and opening log) — The file is kept with the email it accompanies, that is 36 months from sending with the same exceptions, and destroyed with it. The link's secret is never kept; its cryptographic digest, expiry and revocation state are kept with the file. The link stops working 30 days after it is sent, or earlier if the board revokes it. The opening log (date and time only) is kept with the email and destroyed with it.
• Emails sent to `postmaster@` or `abuse@` at a syndicate address (message, attachments and sender's address) — 36 months from receipt, in CondoAide's operations mailbox. They are never added to the syndicate's file.
• Quarantined email (spam or malware detected) — 30 days from reception.
• Raw copy of the message at the receiving provider — 30 days. It is a transport buffer, not an archive.
• Email-address suppression state (permanent bounce or complaint) — Kept for as long as the address remains suppressed. When a transactional email permanently bounces or a complaint is received, the address is placed on a suppression list so the Service stops writing to it; that is the entire purpose of the entry, and it lasts as long as the address stays undeliverable. The entry is removed once the address is reachable again, after correction and verified delivery, or following a valid erasure request where no other ground requires keeping it; you can ask for its removal by writing to privacy@condoaide.ca. The row holds the address, the reason, the provider, the technical message identifier and the timestamps of the first and most recent events; no email content is retained. This entry concerns delivery, not consent: it withdraws no newsletter consent and does not alter the marketing lists, which remain governed separately.
• Unconfirmed newsletter subscription request — Deleted 30 days after the confirmation email is sent if nobody confirms. When an address is signed up for the newsletter on our website (or from the calculator, when its box is ticked), we keep the address, the language, the form it came from and the date the confirmation email was sent, without treating the subscription as consented. The confirmation link expires after 7 days, and one address receives at most three confirmation emails. The address is sent to Brevo only once the subscription is confirmed.
• Device key used as a second factor (identifier and public key, counter, connection methods, date and session added, optional name, last use) — Until it is removed, by you from your settings or by our support team, or until your account is deleted; no fixed period. The key serves a purpose only while you use it to authenticate. A key synced by your password manager stays there under that provider's rules, possibly outside Québec, until you delete it there; CondoAide sends it nothing.
• Proof that a key was verified in a session — Until the session ends (sign-out, revocation or expiry) or the key is removed, whichever comes first.
• Pending key verification challenge — Five minutes. An answered challenge is destroyed immediately, and expired challenges are deleted every hour.
• Approval of an authenticator app by means of a key — Kept as long as the approved authenticator app or your account, and destroyed with whichever goes first.
• Second-factor recovery codes (fingerprint of each code, creation date, time and session of use) — Until they are replaced by new codes, until your last second factor is removed or a factor is removed by our support team, or until your account is deleted; no fixed period. The proof that a code was used in a session disappears with that session.
• Recovery-code attempts (number of wrong attempts, end of the block, date a code was last used) — The attempt count resets with the next valid code or after one hour, and a block ends after one hour. The date a code was last used is kept until your account is deleted.
• Sign-up abuse counters (keyed hash of the IP address, and of the email address of an existing account) — When someone tries to create an account with an address that already belongs to an account, the holder of that account is told by email, at most once every 24 hours. To limit attempts and that notice, we keep neither the IP address nor the email address in clear, only a hash keyed with a server secret: the IP hash (for an IPv6 address, its /64 prefix) expires after 15 minutes, the email hash after 24 hours.
• Residence status, postal address and contact email of the person who buys a private portion — The residence status and postal address are kept with the person's entry in the register of co-owners, held with the syndicate's records. The contact email of a person without an account is destroyed as soon as they claim their account, or with their entry if it is deleted. The record of the sale in the syndicate's activity log, which only people authorized to manage members can read, keeps a copy, which follows the audit log period.
• The syndicate's welcome message — Kept while it is in force; replacing or emptying it destroys the former text, and it is destroyed with the syndicate's account. A text written for a single invitation is not saved: it survives only in the email sent, under the period of the email sending queue.
• Former values of a proof reset at a sale — Recorded in the syndicate's activity log, then destroyed from the temporary handoff immediately after the sale is recorded, or within 25 hours at the latest; in the log, they follow the audit log period. A handoff that cannot be recorded in the log is retried every day, flagged to our team, then destroyed at the latest 31 days after the sale is recorded, without having been recorded in the log; a trace that contains none of those values then records its loss.
• Decisions to include your email and phone number in the co-ownership register — Kept for as long as you are a member of the syndicate concerned, and destroyed with your membership in that syndicate, with your account or with the syndicate's account. The record of each change in the syndicate's activity log, which contains neither your email nor your number, follows the audit log period.
• After the periods above, data is permanently deleted from our production systems. Copies may persist in backups for an additional period (up to 30 days) before rotation and destruction.
• Service requests (including history migrated from another software) — Kept for as long as the syndicate is active, then 90 days after the account closes, on the same footing as general account data. A migrated request keeps its original date, so it may predate your arrival on CondoAide by years.
• Links sharing a registry document in a service request — The link secret is never retained. Its cryptographic digest, the document and request it covers, its expiry and revocation state are retained until the link expires. Each link expires after 30 days and can be revoked earlier by the board. The external-access log is kept for 36 months after each access, even if the link or document is deleted in the meantime.
• A syndicate's designation of its person responsible, and its dashboard information cards — Kept for as long as they stand. Withdrawing the designation deletes the record; clearing a card's text deletes it. Closing the syndicate's account removes both.
• Answers to a question in an announcement — Kept with the announcement they belong to, and destroyed with the syndicate's account under the general rule above. A period specific to this category is under review: an answer about an availability has no reason to outlive the work it helped schedule, unlike a request. The retention calendar will be updated once that period is adopted.
• Attachment to a syndicate message (file added by the board, image inserted in the message body) — Kept with the message it belongs to, and destroyed with it. The file has no period of its own: its lifetime is the message's, and deleting the message deletes the file. Since September 2026 the board may attach either a registry document or a file that belongs to the message alone; only the second is covered here. That file is not filed in the syndicate's registry, carries no access level of its own, and is readable only by the message's recipients — a narrower circle than the registry can express, for instance when the message is addressed to a single unit. An image inserted in the message body follows the same rule: it is displayed in the app and is never sent by email, in keeping with our rule that notices carry a link rather than a file.
• Files uploaded and never saved (signature image, pet photo) — A signature image uploaded in your settings, or a pet photo added to your occupant details, is stored as soon as you pick it, before you save. If you do not save it, a daily task deletes it at the latest 48 hours after the upload (previously seven days for a pet photo and no period for a signature image). A saved signature or photo is not affected: it follows the period of your account or of your occupant details.
• Request for a statement of common expenses due, and the issued statement — The request (identity, capacity and email of the person making it, the buyer's name, the notice to the owner and the delivery) is kept for as long as the syndicate's file exists and destroyed with it; a withdrawn request is not deleted, so the record of the notice given to the owner remains. The delivery link stops working 30 days after it is sent. The log of its viewings (date and time, truncated IP address, browser type) is kept for three years, the period of a recovery action, then deleted. The issued statement is filed in the syndicate's registry and follows the retention rule for condo documents.
• Sale file for a unit — The file (names and email addresses of the prospective buyer, the broker and the notary, the dates of the promise and of the expected signing, the prospective buyer's document request and its note, the reason for abandonment) is kept for as long as the syndicate's file exists and destroyed with it, like the attestation and statement requests whose information it repeats. An abandoned or concluded file is not deleted: it remains the record of the steps taken for the sale.
• Invoice issued by the syndicate — The invoice (the debtor's identity, intermediary, address and email, its details, amount and payment) follows the syndicate's retention rule for supporting documents: six years after the end of the fiscal year it relates to, the period set by tax law. A voided invoice is kept the same way, with its number; a draft is destroyed as soon as the board deletes it. When the period ends, nothing is destroyed automatically: a member of the board of directors may destroy the information about the debtor, and only the invoice's number, dates and amounts then remain. The delivery link stops working 30 days after it is sent. The log of its openings (date and time, truncated IP address, browser type) is kept for three years, then deleted.
• Request, signed attestation and delivery link for the syndicate attestation — Information about the request and its requester or mandatary is kept with the attestation in the syndicate's file, then destroyed with that file. The signed attestation follows the retention rule for condo documents. The delivery link stops working 30 days after it is sent, and its secret is then erased. The log of its openings (date and time, truncated IP address, browser type) is kept for three years, then deleted.
• Work rules sent to a contractor (link, openings and signature) — The link secret is never retained; its cryptographic digest is erased as soon as the link expires (30 days) or is revoked. The link sent and the contractor's signature are kept as long as the work authorization request, and destroyed with it. Openings of the link (date, truncated network and browser family) are kept for three years.
• Register of improvements to a private portion (entry, before and after photos, invoice, declared approximate value) — Kept permanently, like the syndicate's register of improvements itself: art. 1070 of the Civil Code of Québec requires improvements made by a co-owner to remain identifiable against the description of their private portion. Information copied from the authorization request follows this period and remains in the register even if the request is deleted.
• Upload request for a file added to the register of improvements — Seven days after the upload for the uploader's identifier and the link to the entry; the technical trace that remains afterwards names no one.
• Requests sent to Anthropic (artificial intelligence features) — According to Anthropic's published practices, deleted within 30 days of receipt, unless its safety systems flag them as violating its usage policy (kept for up to 2 years) or the law requires keeping them. This period applies at Anthropic; what CondoAide keeps of the result (assistant conversation, analysis, values retained from one of the syndicate's insurance policies, proposal drawn from the declaration) follows the periods that apply to it in this section.
• Name of a guest at a meeting held in CondoAide — The name a guest gives when joining through the invitation link, the decision to admit them and who made it, and the account of a member tied to their participation, are destroyed 30 days after the meeting ends.

6. Your Rights

Under the Act respecting the protection of personal information in the private sector of Quebec ("Law 25"), PIPEDA, and applicable laws, you have the right to:

• Access your personal information
• Correct inaccurate or incomplete information
• Request deletion of your data (subject to our legal retention obligations, for example PAD mandates retained for 7 years)
• Withdraw your consent to processing that relies on it, for example the newsletter
• Receive your data in a structured and portable format (JSON or CSV export)
• Object to processing (notably marketing communications)
• Automated decision: to be informed of the personal information and the principal factors used, and of the contact details of the person who can review the decision and to whom you may submit observations, if you are the subject of a decision based exclusively on automated processing (s. 12.1)
• Revoke your PAD mandate for the subscription at any time, free of charge, in accordance with Payments Canada Rule H1
• File a complaint with the Commission d'accès à l'information du Québec (cai.gouv.qc.ca) or the Office of the Privacy Commissioner of Canada (priv.gc.ca) for users outside Quebec
• To exercise any of these rights, contact our Person Responsible for the Protection of Personal Information (see section 7).

7. Person Responsible for the Protection of Personal Information

In accordance with section 3.1 of the Act respecting the protection of personal information in the private sector, CondoAide has designated a Person Responsible for the Protection of Personal Information. This person is your point of contact for any question about the processing of your personal information, to exercise your rights, or to report a concern, an incident or file a complaint.

• Name: Nicolae Racovita
• Title: President of CondoAide and Person Responsible for the Protection of Personal Information
• Email: privacy@condoaide.ca
• Postal address: 4143 chemin Ste-Angélique, Saint-Lazare (Quebec) J7T 2N5, Canada
• Our personal information governance policies and practices are published on our Governance page, as section 3.2 of the Act requires.

8. Privacy Incident Notification

In accordance with the Act respecting the protection of personal information in the private sector and the Personal Information Protection and Electronic Documents Act (Canada), in the event of a privacy incident presenting a risk of serious injury to a person concerned, we undertake to:

• Take necessary measures to manage the incident, limit the harm and prevent recurrence.
• Engage our insurer and its approved response panel as soon as the incident is discovered. Technical investigation, legal defence and preparation of notices may be handled by these providers, and the information disclosed to them is limited to what the response requires. This step does not delay the notifications set out below.
• Inform affected individuals without undue delay, by email or any other appropriate means.
• Inform the Commission d'accès à l'information du Québec within reasonable timeframes. Our internal target is to notify within 72 hours of incident confirmation.
• Document each incident in an internal register, including the nature, causes, corrective measures and lessons learned.
• Cooperate fully with personal information protection authorities in case of investigation.

9. International Data Transfers

Some of our sub-processors process personal information outside Quebec or Canada (see the list in section 3). For transfers outside Quebec and Canada:

• We assess the adequacy of the legislative protections offered in the destination jurisdiction
• We put in place appropriate contractual protections with each sub-processor (Data Processing Agreements)
• We limit transfers to what is necessary for the provision of the Service
• For artificial intelligence features (Anthropic, United States), a request is sent when a person uses one of the features named in section 3. Reading co-owners' proofs of insurance does not use Anthropic: they are read in Quebec (section 3). Reading the declaration of co-ownership sends it with no action by the user, after removing the names of people it detects. No user identifier or account metadata is sent to Anthropic with a request; the content sent may, however, name the syndicate or people (section 3). Anthropic's commercial terms prohibit it from using these requests to train its models; according to its published practices, Anthropic deletes them within 30 days of receipt, except those its safety systems flag as violating its usage policy, kept for up to 2 years, and except where the law requires keeping them.
• For payments (Stripe, Canada and United States), the cross-border transfer serves the performance of the subscription and the collection of common expenses through the Payment Service, which you expressly authorize. It includes co-owners' banking details (financial information) and the private portion’s technical identifier. The account identifier of the person who authorizes the mandate stays in CondoAide and is not sent to Stripe. This flow is framed by Stripe's data processing agreement (DPA); account numbers are never stored in plain text by CondoAide. A privacy impact assessment lets us satisfy ourselves that the residual risk attached to this transfer is minimal and manageable.
• For incident response (CFC Underwriting Limited and the providers on its approved panel, CFC Response), the transfer occurs only in the event of a confidentiality incident and is for investigation, defence and issuing notices. The entities involved are established in the United Kingdom and the United States (London and Austin, Texas). Nothing is disclosed to them in the normal course of the Service.
• For the bot check on public forms (Cloudflare Turnstile, global network), the browser sends technical data (IP address, browser and device characteristics) when the form is filled in, to keep bots out; no form content and no document is sent. This flow is governed by Cloudflare's data processing terms.
• If you have questions about a specific transfer or wish to object to a particular processing activity, contact privacy@condoaide.ca.

10. Cookies, Telemetry and Session Recording

Cookie banner. For unauthenticated visitors on the public site and on sign-in pages, OpenReplay telemetry is only enabled if you accept it via the banner that appears on your first visit. Your choice is stored locally (localStorage) and can be changed at any time via the "Reset cookie preferences" link at the bottom of every page. Refusing telemetry does not affect your use of the service — strictly necessary cookies (session, security, language) remain active. OpenReplay session recording. When authenticated, OpenReplay records a reconstruction of your navigation (clicks, scrolls, page changes) to help our support team reproduce a problem when you report it. Enabled by default, can be disabled at any time via Profile → Session recording for support. Form fields and screens containing sensitive information (PAD, attestation, registry, financial statements, insurance proofs, compliance, syndicate members, payments) are masked automatically. GlitchTip error tracking. Remains active regardless of your choice because it is strictly necessary for service quality. Minimized configuration: pseudonymized user identifier, request bodies (form data, authentication headers, cookies) automatically dropped, IP address not transmitted. Retention: 30 days for all flows — events and session recordings on OpenReplay; application logs and error events on GlitchTip. Resolved GlitchTip issue groups are kept 90 days for regression detection. For more information, see our Cookie Policy.

11. Information Concerning Children

The Service is not intended for persons under 14 years of age. We do not knowingly collect personal information from children. If you believe a child has provided personal information to CondoAide, contact privacy@condoaide.ca so that we can proceed with deletion.

12. Changes

We may modify this policy from time to time. We will notify you of material changes by email or through the platform. The last update date is indicated at the top of this page. Continued use of the Service after a modification constitutes your acceptance of the updated version.

13. Contact Us

For any questions about this policy or to exercise your rights:

Appendix — Change History

Version history of this policy:

• Version 1.0 - February 1, 2025 — Initial version.
• Version 1.1 - May 7, 2026 — Added PAD/ACSS Debit payment method; public designation of the Person Responsible for the Protection of Personal Information; expansion of the sub-processor list; addition of the privacy incident notification section; addition of the international data transfers section; addition of PIPEDA and Office of the Privacy Commissioner of Canada references.
• Version 1.2 - June 2, 2026 — Launch of automatic condo-fee collection by pre-authorized debit (PAD/ACSS): Stripe (Stripe Payments Canada, Ltd.) now also processes co-owner contribution debits to the syndicate's account. Sections 1 and 3 and the sub-processor list updated accordingly.
• Version 1.3 - June 13, 2026 — Clarifications on Stripe's processing of condo fees: added distinct retention periods for the co-owner condo-fee mandate and transactions (section 5), and described the cross-border transfer of co-owners' banking details via Stripe, covered by a privacy impact assessment (section 9).
• Version 1.4 - July 12, 2026 — Added the assembly meeting chat: message retention period (section 5). Messages are hosted in Québec (Supabase, Canadian region) — no new cross-border transfer.
• Version 1.5 - July 13, 2026 — Added the assembly-meeting presence log: retention period for the log of participant connections and disconnections (section 5). The log is hosted in Quebec (Supabase, Canadian region) — no new cross-border transfer.
• Version 1.6 - July 23, 2026 — Removed OpenAI from the sub-processor list: registre document embeddings are now produced by a self-hosted model (bge-m3) in Québec, at OVHcloud (Beauharnois). Anthropic remains our only artificial-intelligence provider, for opt-in features only. Section 3 updated.
• Version 1.7 - July 30, 2026 — Added Amazon Web Services (Amazon SES) to the sub-processor list: transactional and authentication emails are now sent from Québec (ca-central-1 region, Montreal). Brevo is re-scoped to marketing emails, contact-list management and the fallback relay role for transactional emails (European Union). Sections 3 and 4 updated.
• Version 1.8 - July 30, 2026 — Integration of our external legal counsel's review: the statute is named in full (Act respecting the protection of personal information in the private sector), with the Act to establish a legal framework for information technology added and Bill 16 given its official title; the scope of Stripe's PCI DSS certification is clarified (card data); IP address processing and how payment information is collected are disclosed; sharing in a commercial transaction is added (section 3); the automated-decision right (section 6) and the incident steps (section 8) are reworded; and section 9 now states that the transfers concerned are those outside Quebec.
• Version 1.9 - 12 August 2026 — Declaration of three sub-processors that were already operating without appearing on the list: iDrive e2 (Montreal), which holds our off-site backups, OVHcloud (Beauharnois), which holds the secondary copy, and OVHcloud (Beauharnois) for the self-hosted video-conferencing server used by assembly meetings, none of whose streams are recorded. Because a backup contains every category of information entrusted to the Service, both destinations are now named. Correction of two inaccurate security statements: authentication tokens are signed with ECDSA on the P-256 curve (ES256) rather than HMAC-SHA256, and the mention of an automated weekly restore test is removed, that job being disabled. The commitment to an annual third-party penetration test is kept but loses its late-2026 deadline. No new processing, no new category and no transfer outside Quebec.
• Version 1.10 - 12 August 2026 — Automatic collection of condo fees: added the identity of the person who enables it and the time they did (section 1), and their retention period (section 5). This is used to require that a second person authorise a debit above the syndicate's threshold, and to identify the party behind the mandate as Payments Canada Rule H1 requires. No new processor, no new purpose and no flow outside Québec.
• Version 1.11 - 13 August 2026 — Proxy registration log: added its retention period (section 5). For every mandate signed electronically, this log records the time of signature and the IP address and browser used, as section 39 of the Act to establish a legal framework for information technology requires. It was previously destroyed together with the mandate it related to; it now survives until the syndicate's file is destroyed, which lengthens its retention. The reason is that proof a proxy existed matters precisely when that proxy disappears. No new category of information is collected and no new recipient gains access.
• Version 1.12 - 16 August 2026 — Outbound email queue: added its retention period (section 5). The queue carries notices, convocations and reminders; it holds the recipient's address and the data used to compose the message, without keeping the rendered result. It had no period until now. It is set at 90 days after sending, and 30 days after a final failure for a message that never left. The period is operational rather than evidentiary: proof that a notice was sent is recorded in the file it belongs to, not in this queue.
• Version 1.13 - 16 August 2026 — Email sending queue: correction to section 5. Version 1.12 stated that proof of sending did not depend on this queue. That was true for most notices, but not for convocations to an assembly or a board meeting, their updates, agenda additions and reminders: for those, the recipient detail currently exists nowhere else. The period for those rows is raised to 90 days after the assembly or meeting concerned; the rest of the queue stays at 90 days after sending.
• Version 1.14 - 22 August 2026 — Insurance-proof imports: added the temporary processing of the aggregate PDF and its extracted text to sections 1 and 2, and their maximum three-hour retention to section 5. The aggregate file is never added to the syndicate's document registry; only the minimized per-unit proofs are added to it. Processing stays with Supabase in Quebec, with no new sub-processor or transfer outside Quebec.
• Version 1.15 - 22 August 2026 — Email-address suppression state: a line added to section 5. When a transactional email permanently bounces or a complaint is received, the address is placed on a suppression list so the Service stops writing to it. This concerns delivery, not consent: it withdraws no newsletter consent and does not alter the marketing lists, which remain governed separately. The row holds the address, the reason, the provider, the timestamps of the first and most recent events and the technical message identifier; no email content is retained. No new processor and no new flow outside Quebec: Amazon (SES, Montréal) is already listed in section 3.
• Version 1.16 - 24 August 2026 — Email-address suppression state: the line announced in version 1.15 is now actually present in section 5, with its retention period. Version 1.15 announced the line without adding it, and without stating a period; the correction is recorded rather than erased. The retention is a condition rather than a number of days: the entry stays for as long as the address is undeliverable, and is removed once delivery is restored and verified, or following a valid erasure request. No newly collected information, no new processor and no new flow outside Quebec.
• Version 1.17 - 27 August 2026 — A board announcement can now carry a question that the co-owner answers in the app: this category was added to section 1, including the free-text comment and the file the co-owner supplies themselves, and the corresponding retention entry was added to section 5, with its specific period still under review. An answer is attributable by design and is not a vote. No new sub-processor and no new transfer outside Québec.
• Version 1.18 - 28 August 2026 — Professional liability and cyber insurance taken out. The insurer and the providers on its approved response panel become possible recipients of personal information, but only in the event of a confidentiality incident. New recipient category in section 3, clarification in section 8, and a new flow outside Quebec in section 9 (United Kingdom and United States). No new processor in the normal course of the Service.
• Version 1.19 - 1 September 2026 — A syndicate message may once again own its own files, instead of every attachment being filed in the registry. New period in section 5: a message attachment has no period of its own; it is kept with the message and destroyed with it. The file is not filed in the registry and is readable only by the message's recipients — a narrower circle than the registry's access levels can express. An image inserted in a message body follows the same rule and is never sent by email. No new processor, purpose, location, or automated decision.
• Version 1.20 - 10 September 2026 — Added to section 1: the identity of the person who declares what the declaration of co-ownership provides for contributions paid before the budget is adopted, meaning who declared it, when, and the article of the declaration that is cited, along with the recording of every change in the syndicate's audit log with the person's name and email address. Added the corresponding retention period to section 5. No new sub-processor, no new flow outside Quebec and no automated decision.
• Version 1.21 - 15 September 2026 — Service requests filed by a tenant: added to section 1, the tenant capacity recorded at filing time, the private portion concerned, the closing reason "redirected to the co-owner", and the viewing of the request, its attachments and the board's public replies by the co-owners of that private portion, for requests filed since their ownership began. Added to section 2, the notices sent to the co-owner who receives the private portion's notices and to the tenant. No new sub-processor, no new flow outside Quebec, no new retention period and no automated decision.
• Version 1.22 - 15 September 2026 — Added to section 3 the document analysis service self-hosted at OVHcloud in Beauharnois (Quebec), which reads maintenance logs, reserve fund studies and, now, the bank account statements an authorized person imports as PDF. The categories concerned are specified: content of imported documents, including bank transaction dates, amounts and descriptions. No new retention period, no new flow outside Quebec and no automated decision.
• Version 1.23 - 15 September 2026 — Added to section 1 the syndicate's mailbox: what you write to a CondoAide syndicate address is kept in the syndicate's file and read by the entire board. Added to section 5 the retention periods for received mail (36 months from reception, with text copied elsewhere in the file removed at the same moment, unless the email is filed to a record or under a legal hold), for the board's reply sent from that mailbox (36 months from sending), for a quarantined email (30 days) and for the raw copy at the receiving provider (30 days). Clarified in section 3 and on the Security page (sections 1 and 6) that Amazon SES also receives and temporarily stores messages in the ca-central-1 (Montreal) region. No new flow outside Quebec and no automated decision.
• Version 1.24 - 15 September 2026 — Vendor invoice attached to a work order: added to section 1 the invoice content read at an authorized person's request (date, number, vendor name and contact details, GST and QST registration numbers, amounts) and the keeping of those numbers on the vendor record. Added to section 2 the corresponding purpose: suggesting the data to record and filing a copy of the invoice in the syndicate's registry under the Invoices category, reserved to the board of directors. Clarified in section 3 that the self-hosted document analysis service at OVHcloud in Beauharnois also reads invoices, including through optical character recognition when the file is an image. No new sub-processor, no new flow outside Quebec and no exclusively automated decision: every suggested value is kept or discarded by a person.
• Version 1.25 - 16 September 2026 — Added to section 1 the answer a board member records on a unit's behalf: when a co-owner answers a question attached to an announcement by phone or by email, the board may record that answer in the app. It then carries the name of the board member who recorded it, it is shown as board-recorded, and it never replaces the answer the co-owner gives themselves. No new sub-processor, no flow out of Québec and no new retention period.
• Version 1.26 - 16 September 2026 — Added to section 1 the request for a statement of common expenses due for a unit (art. 1069 of the Civil Code of Québec): the name, capacity and email of the person making it, the buyer's name, the notice given to the owner, the sending of the statement as an email link and the log of its viewings (date and time, truncated IP address, browser type). Added to section 2 the disclosure of that statement to the person proposing to acquire the unit, after notice to the owner, and to section 5 their retention periods, including three years for the viewing log. No new sub-processor, no flow out of Québec.
• Version 1.27 - 17 September 2026 — Added to section 1 emails sent to postmaster@ and abuse@ at a syndicate address: they are not added to the syndicate's file but forwarded to CondoAide's operations mailbox, which only the person responsible for the protection of personal information reads. Added to section 2 the corresponding purpose, to section 3 and the Security page their forwarding through Amazon SES within the same region, and to section 5 their 36-month retention period. No new service provider and nothing leaves Quebec.
• Version 1.28 - 17 September 2026 — Section 3: when a syndicate entrusts its management to a property management company and adds it to its account as manager, that manager now has access, to carry out its mandate, to the syndicate's financial information, including co-owners' payment information (debit mandates, payment history, arrears) and vendors' payment details. Adopting a budget, deciding a special assessment and approving a payment above the threshold remain reserved to the board of directors. No new sub-processor, no flow out of Québec and no new retention period.
• Version 1.29 - 17 September 2026 — Clarification, in section 1: when the syndicate's mailbox is in service, the syndicate also sends the notices and announcements it addresses to you from that address, so a reply to one of those messages arrives in that same mailbox, available to the same people and kept for the same period. The email address of an administrator's personal account is no longer sent to co-owners with those notices.
• Version 1.30 - 21 September 2026 — Sections 1 and 3: when a co-owner says a contractor will do the work in a work authorization request, we collect the company's name, its Régie du bâtiment du Québec licence number and, if provided, a contact person's name and email. We check that number with a new sub-processor, VériBât, which consults the Régie's public register from Montreal: only the licence number is sent to it. No flow out of Québec and no new retention period: this information follows the request.
• Version 1.31 - 21 September 2026 — Sections 1 and 5: once work is authorized, the co-owner may send the syndicate's work rules for contractors to their contractor, who signs them through a link without creating an account. We keep the link's openings (truncated network and browser family, three years) and the proof of the signature (typed name, the link's address, signed version, date and time, IP address and browser), as long as the request. No new sub-processor and no flow out of Québec.
• Version 1.32 - 22 September 2026 — Sections 1 and 5: files attached to the support form are now kept in our private storage in Québec (Supabase, Canadian region) instead of being sent by email, and only authorized CondoAide staff can download them. New retention periods: three years after the message is sent, and at most four hours for a file whose message is never sent. No new sub-processor and no transfer outside Québec.
• Version 1.33 - 22 September 2026 — Sections 1 and 5: authorized work now opens your private portion's entry in the syndicate's register of improvements, where you can add before and after photos, the invoice and an approximate value, then report the work as finished for the board to confirm. Those files and that value are read only by the owners of your private portion, the board and, where applicable, the property manager; the approximate value is no longer visible to other co-owners, and an entry whose work is still planned is reserved to them until the work is reported finished. New periods: the entry and its files are kept permanently, including information copied from the request, which remains if the request is deleted; seven days for the identifier carried by an upload request. Email and in-app reminders before the planned start and after the planned end. No new processor and no transfer outside Québec.
• Version 1.34 - 22 September 2026 — Section 3: to find a contractor's licence, you can now type the start of its number or the company name, in a work authorization request as well as in the board's list of vendors. That text is sent to VériBât, which returns at most ten entries from the public register of the Régie du bâtiment du Québec; before, only a full number was sent. A company name may be the name of a person in business. CondoAide does not record these searches in your file: only the licence chosen is, as before. No new sub-processor and no transfer outside Québec.
• Version 1.35 - 22 September 2026 — Sections 1 and 3: for vendors with a Régie du bâtiment du Québec licence number, we now keep the public register's answer with the vendor's record (holder name, presence in the register, restriction, date it left the register and date of the check), to warn the syndicate of a licence that is missing from the register or restricted. The number is checked with VériBât when it is entered or changed, then about every two days. Only the licence number is sent. The answer is removed with the vendor's record and replaced as soon as its number changes. No new sub-processor and no transfer outside Québec.
• Version 1.36 - 23 September 2026 — Section 1: a report sent to CondoAide support from the app also includes the pages where it was opened and from which it was sent, the person's role in the syndicate, the app version and the browser used. This information is used to reproduce the reported problem and follows the retention of support communications. No new sub-processor, no new transfer outside Québec, no new retention period and no automated decision.
• Version 1.37 - 24 September 2026 — Section 1: files attached to a report to CondoAide support, including screenshots pasted into a reply, can also be viewed by the board members of the syndicate that sent the report, in that report's follow-up, like the text that goes with them. Authorized CondoAide staff still download them with two-factor authentication. No new sub-processor, no new transfer outside Québec, no new retention period and no automated decision.
• Version 1.38 - 25 September 2026 — Section 1: the syndicate mailbox also keeps the name and address of the other recipients of a received email ("To" and "Cc"); the board can reply to several people, in copy and in blind copy, and can also write a new email from the mailbox to any address, whose replies arrive in the same mailbox. Section 5: the board reply line also covers the new email, kept as long as a reply received in the same conversation is; recipients are kept and destroyed with the message.
• Version 1.39 - 25 September 2026 — Section 1: the board can attach files to an email sent from the syndicate's mailbox; each file is sent as a link valid for 30 days and revocable, which opens without an account, and each opening is recorded with its date and time only. Section 5: adds the retention of these files, their links and the opening log, which follow the email (36 months). No new sub-processor, no transfer outside Québec and no automated decision.
• Version 1.40 - 26 September 2026 — Section 5: adds the retention of an unconfirmed newsletter subscription request (30 days). Subscribing to the newsletter from the website is now confirmed through a link sent to the address signed up; the address is sent to Brevo only after that confirmation. No new sub-processor, no new flow outside Québec and no automated decision.
• Version 1.41 - 28 September 2026 — Section 1: the syndicate's mailbox is now the sending address for every email CondoAide produces on the syndicate's behalf, including notices meant for the board, the treasurer, the manager and the people doing work for it, and electronic signature requests; the manager mandated by the syndicate is named among the people with access to the mailbox; each email sent is recorded in a send log. Section 5: adds the retention of that log (7 years). No new sub-processor, no transfer outside Québec and no automated decision.
• Version 1.42 - 29 September 2026 — Section 1: adds the reading of the syndicate's declaration of co-ownership, at the request of the board or of our support team, to compare it with the recorded configuration; the page text is kept only while the read runs. Section 3: the document analysis service also reads the declaration of co-ownership. Section 5: adds the retention of the page text, the resulting proposal and the board's decisions.
• Version 1.43 - 29 September 2026 — Sections 1, 2 and 5: the person who sent a report to CondoAide support may, once the report is resolved, give optional feedback on the answer (“Great”, “Okay” or “Not good”) and a comment. Only authorized CondoAide staff read it; it is used to improve our support and follows the retention of support communications. No new subprocessor, no new flow outside Québec and no automated decision.
• Version 1.44 - 29 September 2026 — Sections 1, 3, 4, 5, 6 and 9: correction of the description of Anthropic, presented until now as reserved for artificial intelligence features enabled beforehand ("opt-in"), when no prior enabling exists. Section 3 now names each use: the AI assistant, the automatic reading of insurance proofs and policies, the analysis, drafting and translation of texts, and the fallback reading of the declaration of co-ownership, which sends, with no action by the user, pages from which it removes the names of people it detects. Section 9 states that requests are not used to train models and that Anthropic deletes them within 30 days, with two exceptions; section 5 adds this period. No new subprocessor and no new automated decision.
• Version 1.45 - 29 September 2026 — Sections 1, 3, 5, 6 and 9: adds the identity of the person who authorizes a private portion’s PAD mandate and whether or not they were a co-owner on that date. This information stays in CondoAide and is used to block every new debit when a signer who was a co-owner no longer owns the private portion. Disclosure correction: Stripe already received the private portion’s technical identifier in the mandate metadata, but does not receive the signer’s identifier. This information follows the mandate’s retention period, which is 7 years after it ends. No new subprocessor and no new automated decision.
• Version 1.46 - 30 September 2026 — Sections 3, 4, 5 and 9: co-owners' proofs of insurance are no longer sent to Anthropic to be read. Each proof filed or imported is read in Quebec by our self-hosted document analysis service, which extracts the insurer, the policy number, the coverage dates and the coverage amounts; the file is sent to it without its name, and the text read is not kept. For insurance, Anthropic now only receives the first 10 pages of one of the syndicate's policies, when a person chooses "Analyze a PDF". No new subprocessor and no new automated decision. Section 5: added the retention period for these proofs, three years after the end of the coverage they attest (art. 2925 of the Civil Code of Québec); the product previously applied two years from the filing without publishing that period. Section 9: every button that sends content to Anthropic now says it uses artificial intelligence, and the section no longer lists features that did not say so.
• Version 1.47 - 30 September 2026 — Sections 2 and 5: addition of the demo syndicate. A signed-in person can open a syndicate filled with fictional data to try the Service; the emails it produces do not leave it and no payment is collected in it. Everything entered in it, including about other people, is destroyed on reset, on request, or 30 days after the last activity; the daily usage counters are destroyed 7 days after the day counted. The artificial intelligence features offered in the demo send content to Anthropic as described in sections 3 and 9. No new sub-processor, no new data flow outside Québec and no automated decision.
• Version 1.48 - 30 September 2026 — Sections 1, 2 and 5: addition of the ownership transfer record for a private portion, which records the departing and incoming co-owners, the closing date and receipt of the acquirer’s notice (art. 1065 C.C.Q.), kept with the syndicate’s file. On a transfer, the board may revoke the departing co-owner’s debit mandate, with a notice to the payer and a cancellation request for debits after closing, and invite the new co-owner to authorize the debit of condo fees. Section 5: addition of the retention periods for proof of revocation (seven years after the revocation), invitations (12 months after sending) and PAD mandate authorization attempts (30 days if not completed, seven years after use otherwise). No new subprocessor, no new flow outside Québec and no automated decision.
• Version 1.49 - 1 October 2026 — Section 1: addition of calculators used from an artificial intelligence assistant (CondoAide connector for ChatGPT and Claude). The calculation data is not kept; the IP address of the call is used only to limit the number of requests, in memory only; OpenAI and Anthropic do not act as CondoAide sub-processors for this service. No new sub-processor and no new transfer outside Québec on our part.
• Version 1.50 - 1 October 2026 — Sections 1, 4 and 5: addition of the device key (Touch ID, Face ID, security key or key synced by a password manager) as a second factor, the information kept for it and its retention periods. No biometric data is transmitted. A synced key is also kept by the provider the person chose, possibly outside Québec; CondoAide sends it nothing. No new sub-processor and no new transfer outside Québec on our part.
• Version 1.51 - 1 October 2026 — Sections 1, 2 and 5: addition of welcoming the person who buys a private portion (residence status, postal address, contact email, the syndicate's welcome message and notice of the obligations to fulfil), of the reset of the departing person's proofs, and of the retention periods of this information. No new sub-processor and no new transfer outside Québec.
• Version 1.52 - 1 October 2026 — Section 1: the link to the full calculator, at the end of an answer from the CondoAide connector for ChatGPT and Claude, now contains all the calculation data (amounts, years, rates) in addition to the private portions and their relative values, so the page opens with the answer’s figures. This data is not personal information. No new information collected, no new sub-processor and no new transfer outside Québec.
• Version 1.53 - 1 October 2026 — Sections 1, 2 and 5: addition of express consent to including the email and phone number in the co-ownership register (art. 1070 of the Civil Code of Québec), given separately for each and for each syndicate, of the proof kept of that decision, of who reads it and of its retention period. A co-owner of the same private portion no longer sees another person's email or phone number without that consent. No new sub-processor and no new transfer outside Québec.
• Version 1.54 - 1 October 2026 — Sections 1 and 2: added the claim the syndicate may make against a co-owner responsible for a loss (art. 1074.2 of the Civil Code of Québec). The claim record then names the private portion concerned, the basis of the claim, the facts noted by the board, its status, the amounts claimed and, where applicable, the charge added to the private portion’s account; this information is visible only to directors who manage claims and have access to the syndicate’s finances. New purpose: split the cost of a loss between the syndicate, its insurer and a co-owner, then bill the accepted amount. No new sub-processor, no flow leaving Québec.
• Version 1.55 - 2 October 2026 — Section 1: the current co-owner of a private portion linked to a claim now sees its title, date and status, and the role of their own private portion, even when the board has not made the record visible to co-owners. When their portion was damaged, they only learn that the loss started in another private portion, not which one. No new sub-processor and no new transfer outside Québec.
• Version 1.56 - 2 October 2026 — Sections 1, 2 and 5: addition of the invoice the syndicate issues to a person (a co-owner or someone who does not use the Service): the information recorded about the debtor, delivery through a link valid for 30 days and the log of its openings, its purpose and its retention periods. The invoice is never charged to the unit's account. No new sub-processor and no new transfer outside Québec.
• Version 1.57 - 2 October 2026 — Sections 1, 2 and 5: addition of the delivery of the syndicate’s attestation to the person who requested it, often a broker or notary acting for the selling co-owner: the mandatary’s role and the delivery email recorded on the attestation, delivery of the signed attestation through a link valid 30 days, with the attestation-fee invoice when the building by-laws provide for one, and the log of that link’s openings, kept three years. Payment of the fee never conditions delivery of the attestation.
• Version 1.58 - 2 October 2026 — Sections 1, 2 and 5: addition of the sale file for a unit, kept by the board to follow a sale until the buyer arrives: the names and email addresses of the prospective buyer, the real estate broker and the notary, the dates of the promise to purchase and the expected signing, the prospective buyer's document request (art. 1068.2 of the Civil Code of Québec) with the dates the documents and the owner's copy were provided, and the reason a file was abandoned; its purpose and its retention, with the syndicate's file. No new sub-processor, no disclosure to a third party and nothing leaves Québec.
• Version 1.59 - 2 October 2026 — Section 5: added the retention period of claim records (five years after the loss or three years after its resolution, whichever is later; 90 days after the board deletes a record) and the removal of the claim’s title from billed claim charges when the record is destroyed. No new sub-processor and no new transfer outside Québec.
• Version 1.60 - 3 October 2026 — Sections 1, 4 and 5: added second-factor recovery codes (an irreversible fingerprint per code, the creation date, the time and session of use), the count of wrong attempts and their block, and the date a code was last used; their purpose, the security emails that come with them and their retention. No new sub-processor, no disclosure to a third party and nothing leaves Québec.
• Version 1.61 - 6 October 2026 — Section 2: the newsletter is sent only to people who asked for it. Creating an account no longer subscribes you to the newsletter; the sign-up form offers a box that is never pre-ticked, and the subscription starts only once the address is confirmed. Subscriptions that account creation had recorded automatically are withdrawn, except where the person had also asked for the newsletter through a form. Section 3: for a communication sent with “Notify and track reads”, message translation and AI drafting (Anthropic) are no longer offered, and its content then does not leave Québec; only survey questions and their choices can still be translated, which the writing screen states next to the button. No new sub-processor, category, flow outside Québec or automated decision.
• Version 1.62 - 6 October 2026 — Section 1: added the free declaration of co-ownership reader, a public tool where a person without an account can upload a declaration as a PDF; it reads it with fixed rules, without any artificial intelligence service, and asks for no account, name or email. Section 3: added Cloudflare (Turnstile), which checks that public forms are filled in by a person and not a bot; it has been in use since before this version and was not named. Section 5: the file uploaded to the free reader and its result are deleted 24 hours after the upload, or sooner at the person's request. Section 9: added the flow to Cloudflare, outside Quebec. No other category, purpose or retention period changes.
• Version 1.63 - 6 October 2026 — Sections 1 and 5: a person who read their declaration in the free reader may choose to file it, with the result of the reading, in the registry of the syndicate they then create; the tool’s copy is deleted at the transfer or, at the latest, when the reading expires, and the filed document follows the registry’s retention periods. The link that carries this choice does not contain the person’s token; opened in another browser, it leads to a confirmation by the board.
• Version 1.64 - 7 October 2026 — Section 5: a copy of an email CondoAide sent for the syndicate or in its name that comes back into the syndicate's mailbox (for example through the automatic forwarding of another of its addresses) is not received correspondence; it is destroyed by the daily destruction run that follows its reception, instead of being kept 36 months.
• Version 1.65 - 9 October 2026 — Sections 1 and 5: added the name given by a person who joins a meeting held in CondoAide through the invitation link, the decision to admit them and who made it, and the tie between a signed-in member's account and their participation, collected since August 2026 without appearing in the policy; this information is destroyed 30 days after the meeting ends.