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
• Acceptance of the terms: when you accept our Terms of Service and this Policy, by creating a syndicate or before you access the Service, we keep the date, the version accepted, the context (syndicate creation or access to the Service) and, where applicable, the syndicate created. We do not collect your IP address or the characteristics of your browser on that occasion. Only you and a CondoAide super-administrator signed in with two-factor authentication can read this information; it serves as proof of the contract between us.
• Condo information: information about your syndicate, buildings, units and equipment
• Space leases recorded by the board of directors: when the board records the lease of a space (parking, garage, storage or locker), we keep the private portion that rents it, the private portion that rents it to another one or the name of a lessor outside the syndicate (for example the horizontal syndicate), the start and end dates, the rent agreed between the parties if it is entered and an optional note. This information is read by the board of directors and, until the lease ends, by the current co-owners of the private portions concerned, never by a tenant. A lease changes neither the allocation of the space nor the sharing of charges; only a lease granted by the syndicate itself gives rise to space fees, for the periods it covers. When the syndicate itself rents a space from a third party, for example the initial syndicate, the board may choose to recharge that rent to the private portion that uses the space: each recharged month is then kept with that private portion, with its amount and status, and read by the board and by the current co-owners of that portion, with the other entries of its account, never by a tenant. The yearly rent owed to the lessor is recorded in the syndicate's name, with no information about the private portion or its co-owners.
• 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.
• Optional sign-up for a list requested by the board of directors: when the board of directors opens an optional sign-up (for example its snow-removal contractor's alert list), it names the person or business it will give the list to, the list's purpose, and an end date no later than two years after the form was created, even if it changes that date later. If you sign up your private portion, we keep the answers you give to the fields the board chose (for example a cell phone number), your name as the author of the answer, its date, and the exact text of the consent you accepted, with its version. Only one answer is kept per private portion: the portion's other co-owners see it and can replace it. We also log each download of the list by the board (the board member, the date and time, the format and the number of private portions, with no answers).
• Usage data: information about your use of the platform, pages viewed and features used
• Ontario waitlist: if you join the CondoAide Ontario waitlist, your email address, the role you choose (board member, condominium manager, unit owner or other) and the range of the number of units in the corporation (under 25, 25 to 100 or over 100)
• 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.
• Condo-fee debits: automatic collection of co-owners' condo fees is processed by Zūm Rails (Zum Rails Inc.). The co-owner reads, in CondoAide, the pre-authorized debit (PAD) mandate filled in for their private portion and accepts it; CondoAide, not Zūm Rails, collects this consent, on the syndicate's behalf, and keeps its proof: the account that accepts, the date and time of acceptance, the version of the mandate text and the fees it states for a refused debit. We record neither the IP address nor the browser. The co-owner then links their bank account in Zūm Connect, Zūm Rails' bank-linking interface: they enter their banking details there themselves, and CondoAide does not receive them. The amounts debited are deposited in the syndicate's wallet at Zūm Rails, then paid into the syndicate's bank account; CondoAide never holds these funds.
• Debit mandate signed on paper: when a co-owner signs their mandate on paper rather than online, the person who manages the syndicate's payments records it in CondoAide: the co-owner who signed it, the date written on the mandate, the institution, transit and account numbers they wrote on it, and the scanned copy of the mandate, with the scanned void cheque or letter from their financial institution that confirms these numbers; we also keep the identity of the person who recorded it. CondoAide sends these numbers to Zūm Rails to set up the debit, with the express consent the co-owner gives on the mandate, without recording them in its systems: CondoAide keeps only the last four digits of the account. The scanned copies of the mandate and of the void cheque or letter, which carry these numbers, are kept together in private storage in Québec, accessible only to the people who manage the syndicate's payments and to the co-owner concerned. To avoid a typing error, the numbers printed at the bottom of the void cheque are read automatically by our self-hosted document analysis service in Québec (section 3) and suggested to the person recording the mandate, who compares them with the cheque and confirms them before they are sent; the result of this reading is not kept. At submission, the server reads the cheque again and refuses an entered number that differs from a readable number, unless the person recording the mandate confirms that the entered numbers are the ones the co-owner wrote on the signed mandate; that confirmation is recorded in the mandate log, without the numbers. If no number is readable, manual entry remains available. The mandate audit log keeps only the verification status (complete, partial or unreadable) and the compared fields, without the numbers read, under the payment audit log retention period.
• Syndicate verification file for Zūm Rails: before pre-authorized debits are activated, the person who manages the syndicate's payments gathers in CondoAide the file Zūm Rails requires to verify the syndicate: confirmation of the syndicate's legal name, NEQ, address, the publication date of its declaration of co-ownership, the name under which it files with the Canada Revenue Agency, its number of employees and, where applicable, its phone number; the contact person and signatory, chosen among the board's officers (name, office and email); the board's answer on whether a politically exposed person sits on the board or runs the syndicate; the expected debit and vendor-payment volumes; the syndicate's void cheque or letter from its financial institution, its bank statements for the last two months, a proof of address and the Registraire des entreprises' état de renseignements; the list of directors (name, office and email) and an attestation of the board's composition, signed in CondoAide by the president and the secretary, which restates that answer. Once the syndicate is approved, the service agreement Zūm Rails enters into with the syndicate is signed in CondoAide by the same officers, and the CondoAide team sends the signed copy to Zūm Rails. The syndicate's bank statements may show co-owners' names and the amounts they paid. These documents are kept in private storage in Québec, accessible only to the people who manage the syndicate's payments, under multi-factor authentication, and to the CondoAide team that prepares the application. Our self-hosted document analysis service in Québec (section 3) reads each statement to check that it is an official statement and which period it covers; a statement it cannot read is reviewed by a person. The contact person and signatory may also upload their own government photo ID in CondoAide, their passport or driver's licence, in one or two files that CondoAide combines into a single PDF. Only they can upload it, and only after expressly consenting, on the upload screen, to CondoAide collecting it and sending it to Zūm Rails, which verifies the identity of the person who signs for the syndicate. Only that person and the CondoAide team that sends the file, under multi-factor authentication, can open it; each download by the team is logged in the file. The other board members see only that it was received. CondoAide extracts no information from it: the document is read neither automatically nor by artificial intelligence, and a photo is only converted to PDF. The document shows the information printed on it, such as the date and place of birth, nationality, sex, the document number and, on a driver's licence, the home address; CondoAide does not extract it and does not collect it in any other way. It is kept in the same private storage space in Québec and is never copied into our backups (section 5). CondoAide does not collect the directors' social insurance number or the other directors' identity documents, and does not accept the health insurance card.
• 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 our Stripe billing references (customer and subscription identifiers) and billing history, not the mandate document. When an administrator changes the plan of a subscription paid by PAD, we also keep the evidence of their authorization: their account identifier, when they authorized it, the plan chosen, the amount and date of the next debit and the amount of the following debits they authorized, their waiver of the 10-day notice provided by Payments Canada Rule H1, the name of the financial institution and the last four digits of the account, and the Stripe identifiers of the payment method and the mandate. 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. The CondoAide team's assistant that prepares support reply drafts (section 3) may also read it, without the person's name or the report's reference, to propose a follow-up to a comment that asks for something else.
• Assisted setup: when a board member asks us to set up the syndicate for them, they drop the syndicate files they choose into a support ticket (for example exports from another software, spreadsheets, budgets, the declaration of co-ownership or the list of co-owners), up to 1,000 files of 100 MB each, with their names and their paths in the dropped folder. These files may contain personal information about co-owners, occupants and other persons. We also keep the person who authorized CondoAide to process these files, the date and the version of the authorization text and, where applicable, the person who withdrew that authorization and the date of the withdrawal. The files are kept in our private storage in Québec. Only authorized CondoAide staff can download them, using two-factor authentication, and each download is recorded in a log (the staff member, the file and the time). Current board members see the list of files sent in the ticket, without being able to download them again. These files are not part of the syndicate’s archives or of their sync to its cloud storage. A board member can delete them at any time, which also withdraws the authorization.
• 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. The board can also import into this mailbox the history of the syndicate's previous address (for example a Gmail address), by uploading an export of that mailbox: the emails people wrote to it, and those the syndicate sent from it, then join this correspondence, open to the same people and kept for the same period, counted from the date the previous mailbox received them; an email older than 36 months is not imported. The uploaded export file is destroyed when the import ends. Before it can be opened, every imported attachment is scanned by our antivirus.
• Mail tags: board members can organise the conversations in the syndicate's mailbox with tags they name themselves. When the mail history is imported, the names of the old mailbox's folders or labels become tags, unless the person importing unticks that option. A tag can name a person. Tags are visible to the people who have access to the syndicate's mailbox; they are not used for any automated decision and trigger no notice.
• Contact form on a syndicate's public page: when a syndicate turns it on, its public page offers a form where a person, with or without an account, enters their name, email address and message; CondoAide's Contact page is our support team's public page and works the same way. The message is placed in the syndicate's mailbox described above and follows the same access and retention rules. The address entered is not verified: it is shown as such to the board of directors, is never matched to a co-owner or a file, and triggers no filing rule. To limit abuse, we count submissions by an irreversible fingerprint of the IP address and by syndicate, without keeping the IP address in clear. The same page can show a phone number and a booking link that the board of directors chooses to publish.
• 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 any payment provider: Zūm Rails receives, in its place, a random technical identifier that ties the payor to the mandate, in addition to the payor's name and email (section 3).
• 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.
• Artificial intelligence assistant you connect to your account (MCP connector): if you sit on a syndicate's board of directors or are its manager, you can connect the assistant of your choice (for example Claude, ChatGPT, Cursor or Claude Code) to the syndicates where you hold that role, with a personal access token you create in “Profile & signatures › AI connections” or with an authorization you give from the assistant. Co-owners and tenants do not have access to it. The assistant only reads what you can read in the app, under the same permissions: the syndicate's record, the units, the members (name, email address and role), the cotisations, the financial statements, the budget, the status of obligations, and the list and journal of the registry's documents, with a link that requires you to sign in; it never receives the content of the files. If you tick the imports option, it can also create units, buildings, spaces and occupants in bulk and update the syndicate's identification, without any email being sent. Every call the assistant makes is written to a journal: the person, the tool, the syndicate, the date and time, and the simple values passed to the tool, cut to 200 characters; the rows of a bulk import are never copied into it. With each token we keep its name, its first characters, its scope and its creation, last use and expiry dates; the token itself is only kept as a hash and cannot be read back. You can revoke a token or a connected application on the same screen: access stops with the next request. You can get a copy of the journal of your calls by writing to privacy@condoaide.ca. Your assistant's provider receives what the assistant asks for and what our tools answer: you chose it, it is not our processor, and it handles this information under its own privacy policy, possibly outside Québec (sections 3 and 9). CondoAide's team also uses this connector with an internal “support drafts” token, reserved to its staff and requiring two-step verification: its assistant reads the reports sent to support and proposes reply drafts. This token cannot send any message: a team member reads each draft, edits it if needed and sends it themselves. With a separate permission, checked when the token is created, this assistant can also mark a report in progress, answered or resolved, and leave an internal note on it that only the team reads; it can neither reopen a report nor send any text to the person who made it.
• 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.
• Household members: the occupant of a unit (a resident co-owner or one whose residence is not recorded, a tenant, or an occupant) can record, in “My property”, the people who live with them in the unit, with their category (spouse, child or other), their age bracket (adult or child under 18) and, if they wish, their first name; the board of directors can also record them, saying which occupant they live with, and may give an optional last name only to a person it links to no one. These people have no CondoAide account. The household members of a co-owner, whether the co-owner records them or the board of directors links them to the co-owner, belong to the unit: every current co-owner of the unit sees them, those not recorded as living elsewhere can also change them, remove them and add to them, and their syndicate's board of directors sees them. The household members of a tenant or an occupant are visible only to them and to the board of directors; tenants and occupants do not see other people's household members. Members a co-owner recorded before version 1.98 of this policy, under the notice that only they and the board of directors could see them, stay private until that co-owner shares them with the unit's co-owners, and the board of directors cannot do it in their place; those the board of directors itself recorded and linked to a co-owner are visible only to that co-owner and to the board, until the board shares them. This sharing cannot be undone later. A person the board of directors records without linking them to anyone is visible only to the board. This information does not appear in the co-ownership register that co-owners consult. It is used solely to locate the people present during an emergency and appears in the book the syndicate makes available to the fire department. We send nothing to these people.
• 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.
• Photos of a water heater's rating plate: when a board member authorized to manage co-owners' proofs imports the building's water heaters, they upload a photo of each appliance's rating plate. A co-owner registering the water heater of their private portion, or a board member registering it for them, may also attach a photo of its plate: it is then read as soon as it is chosen, to fill in the fields the person has not already typed. The browser shrinks the photo and removes its metadata (location, camera) before sending it. The photo is read by artificial intelligence (section 3) to suggest the brand, model, serial number, manufacture date, capacity and energy source; nothing is kept at that stage. When importing, the board member checks, corrects and matches each photo to its private portion before saving; for a single private portion, the person checks and corrects the filled-in fields before sending. Only on saving or sending are the retained characteristics recorded on the private portion's water heater, and the photo filed in the syndicate's registry under the “Water heater proofs” category, restricted to the board of directors, like any water heater photo uploaded for a private portion. A plate normally shows no person, but the photo is tied to a private portion and may show part of its interior.
• 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). If the table of fractions remains unreadable despite these rules, an authorized board member may, from the screen where they enter the table, ask an Anthropic model to read the image of one page of that table. Our analysis service, in Quebec, crops the page to keep only the region of the table, in grayscale, reduced and without metadata; the person sees the exact image before sending it, one page at a time and at most four pages per read. The request is cancelled if our reading of the image finds a person's name in it, but an image can show what that reading did not recognize: a name printed in the table, initials or a signature. The image is kept neither by CondoAide nor by our analysis service; the proposed values only prefill the table, and the board confirms each of them (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. We also keep there what VériBât links to that licence in three public registries of Données Québec: a listing in the Registre des entreprises non admissibles aux contrats publics (RENA) of the Autorité des marchés publics, with its date and the end of the ineligibility period, a possible match in the Registre des sanctions administratives pécuniaires of the ministère de l’Environnement, and the number and published amount of public contracts awarded on the Système électronique d’appel d’offres (SEAO), with each source’s date; never the name recorded in those registries nor the content of an entry. 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.
• Status certificate request of an Ontario condominium corporation: when a person asks an Ontario condominium corporation for a status certificate on a unit (Ontario Condominium Act, 1998, s. 76), for example a purchaser, a mortgagee or their lawyer, the board records that person's name, capacity, email address when they provide it, the date of the request, the fee charged and the date it was paid, then the date and means by which the certificate was given. The certificate, a PDF on the Condominium Authority of Ontario's form, states among other things the unit's common expenses in default and the names and addresses for service of the directors and officers; it does not name the owner or the person who asked for it.
• Information certificates of an Ontario condominium corporation: Ontario law requires a condominium corporation to send its owners a periodic information certificate twice a year, an update when certain information changes, and a certificate to each new owner who gives written notice of their name and unit (Ontario Condominium Act, 1998, s. 26.3; O. Reg. 48/01, ss. 11.1 to 11.3). For an Ontario corporation, the board prepares these certificates in CondoAide on the Condominium Authority of Ontario's forms, prefilled from the corporation's records. A certificate names the directors and officers with their address for service and states, as the law requires, whether any of them is a party to a legal action against the corporation, has common expenses in arrears for 60 days or more, or has not completed the prescribed training; it also describes the legal actions and judgments involving the corporation. The periodic certificate and the update are filed in the corporation's documents, where all its owners (not tenants) can open them; the new owner certificate is kept for the board, and the new owner's name and the date of their notice are recorded for the board only, without being printed on the certificate. CondoAide sends none of these certificates: the board records the date and means of sending.
• Mandatory director training of an Ontario condominium corporation: Ontario law requires each director to complete the Condominium Authority of Ontario's training within six months of being elected or appointed, with some exceptions (Ontario Condominium Act, 1998, s. 29 (2) (e); O. Reg. 48/01, ss. 11.7 and 11.8). For an Ontario corporation, the board records, for each director on its board, the day they were elected or appointed, the day they left the board if they did, the day they completed the training, and the certificate of completion the director forwarded to the corporation. CondoAide shows the resulting deadline; it does not certify training and does not remove anyone from the board. This information and the certificate are available to the board only.
• Reserve fund studies of an Ontario condominium corporation: Ontario law requires a condominium corporation to obtain a reserve fund study at least every three years and, after each study, to propose a funding plan and give its owners notice of it (Ontario Condominium Act, 1998, s. 94; O. Reg. 48/01, ss. 27-33). For an Ontario corporation, the board records, for each study, its class, the name of the person or firm that conducted it and the prescribed professional class they belong to, its dates, the date of the proposed plan and the dates the notice was sent to the owners and to the auditor, and attaches the study, the plan and the notice. CondoAide shows the dates the Act sets; it does not conduct any study, send any notice or monitor any deadline. The study is available to the board; the dates, the plan and the notice are also available to the owners.
• Records requests of an Ontario condominium corporation: Ontario law allows the owner of a unit to examine or obtain copies of the corporation's records (Ontario Condominium Act, 1998, s. 55 (3); O. Reg. 48/01, s. 13.3). For an Ontario corporation, the owner files the request in CondoAide on the Condominium Authority of Ontario's form: their name, their unit, their mailing address in Ontario, their email address and phone number if they provide them, how they prefer to be contacted, and the records requested. The board records its response for each record (access and estimated fee, or a refusal with its reason, which may relate to a specific unit or owner), the date the fee was received and each delivery with its actual cost. Only the owner who made the request and the board can see it. CondoAide tells the board of a new request or a confirmation, and the owner of a response, through an in-app notification that contains only a link; it sends no email. The board's response PDF is produced each time it is opened and is not kept as a document.
• Proxies and ballots of an Ontario condominium corporation: for a meeting of an Ontario corporation, the prescribed proxy form, signed by a majority of the owners of the unit (Ontario Condominium Act, 1998, s. 52), with the signers' names and signatures, the date and time of signing, the proxy holder and the substitute, the voting instructions, the candidate preferences, the scanned copy of a form signed by hand and the board member who checked it; and the ballots. The authorized board, the owner who gave the proxy and the named holders can read the form; the substitute holder can read its details before exercising the proxy. This information is collected only once CondoAide opens to Ontario condominium corporations.
• Owner obligations in an Ontario condominium corporation: to follow the obligations that the law, the declaration or the corporation's by-laws place on owners, the board can receive and keep the notices of a lease, its renewal and its end that the law requires the owner to give it (Ontario Condominium Act, 1998, s. 83), with the tenants' names, the owner's address and a copy of the lease or the lease summary; insurance certificates (insurer, policy number, coverage); pets and vehicles; contact details of people to reach in an emergency; and, as proof of an obligation only, photos taken inside a unit. When a photo is requested, the upload screen states its purpose, and only the board can see it. This information is collected only once CondoAide opens to Ontario condominium corporations.
• Evacuation and special needs (Ontario): with the express consent of the occupant or their authorized representative (a legal guardian, a person holding a power of attorney, or another authorized representative), the corporation may record whether the occupant needs help to evacuate, their special needs (for example reduced mobility, hearing or vision), and an optional short note. This information is used only to plan help in an emergency and to give it to firefighters and other emergency responders. In CondoAide, only the occupant and the board, including anyone the board authorizes to manage occupant records, can see it. Providing it is optional, and saying no changes nothing else. Consent can be withdrawn at any time, in the app or by asking the board; the information is then deleted right away. CondoAide keeps a record of the consent and its withdrawal (who consented, in what capacity, who recorded it, when, and the version of the text shown), with no health information in it. This information is collected only once CondoAide opens to Ontario condominium corporations.
• 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 also shows, when the board picked it from the syndicate's vendors or typed it in, the name of the syndicate's insurance broker and, when they are on its vendor record, its business phone number and email address, as they stood when the attestation was saved. 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, as well as what VériBât links to that licence in three public registries of Données Québec, namely a listing in the RENA of the Autorité des marchés publics, a possible match in the ministère de l’Environnement’s registry of administrative monetary penalties, and the history of public contracts published on the SEAO, without the name recorded in those registries). 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. That entry is read only by the owners of the private portion, by the board of directors and, where applicable, by the property manager, before and after the work is finished; it is not visible to other co-owners. 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.
• Syndicate email delivery preferences: for each syndicate you are a member of, you choose in your profile which optional reminders you receive by email (assembly and vote reminders, obligation, work and payment reminders, new documents in the register); a « Stop receiving this type of reminder » link at the bottom of each optional reminder also lets you turn one off after a confirmation, and your email software may offer the same button. We keep the list of reminders you have turned off, and the date and author of each change. The board of directors does not see that list, nor that a reminder was not sent to you because you turned it off. If you agree to receive the syndicate's notices at your email address, we keep the date of your agreement and the address it applies to. If you are a co-owner, you may also ask to receive the syndicate's official notices (convocations, contribution notices, minutes) by mail instead of email: those notices are then no longer emailed to you, and the board members who manage the syndicate's settings see your name in the list of people who made that choice, and in the list of co-owners who cannot be reached digitally when a notice is sent, so that they can send them to you by mail. This choice is included in the syndicate's archive. Notices related to a pre-authorized debit agreement are still sent by email. The turn-off link carries a signed code that identifies your account, the syndicate and the type of reminder, without your email address, and stops being valid after 90 days; opening the link changes nothing until you confirm.
• Video conferencing for a meeting: when you take part online in an assembly meeting, a board meeting or a meeting held in CondoAide, your camera image, your voice and the screen you share are transmitted in real time, with your display name, to the people admitted to the same meeting. Your microphone is off when you arrive, you can join without your camera, and you choose at any time what you broadcast. This stream runs through our own video-conferencing server, in Quebec (section 3), and is not kept, except what is shared by the people who consent to a recording the board of directors decided on (see “Recording of a meeting held online” below). For an assembly meeting, we log the times you connect and disconnect (attendance log) and keep the chat messages (section 5).
• 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. When a board member invites someone by email from the meeting, the address they enter is used only to send the link, in the syndicate's name, with the board's optional message; we do not keep it, except in the sending journal when the email leaves from the syndicate's address. When the board allows it, a person admitted to the meeting can also copy their own invitation link or email it to up to three addresses at a time; that email leaves from CondoAide's address, with only the link, the name they gave and the syndicate's name, and we do not keep those addresses. A person who joins through that link waits to be admitted like anyone else, and the board sees on their request the name of the person who invited them. Participants' image and voice are relayed in real time by our video-conferencing server (section 3).
• Name entered on an invitation: when a board member or a manager invites a person to join the syndicate (co-owner, occupant, director, supplier, professional or mandatary), they may enter that person’s first and last name along with the email address. This name is used only to prefill the form in which the person confirms their own name the first time they sign; it never becomes their account name unless they save it. The name of a supplier’s contact person, of a mandatary and of a record created by the board is used for the same prefill. It is read only by CondoAide’s internal processing and by the invited person; members of the syndicate do not see it.
• Booking a meeting with the board of directors: a board member can set their available hours each week and their rules (lengths, break, notice, horizon, daily maximum) and get a booking link that they pass on to whomever they choose. The outside person who opens the link sees only open times, never the title or details of the member’s events. To book, they give their name, their email and, if they wish, their phone number and the reason for the meeting; we also keep the meeting time and the member expected. The booking creates a planned meeting in CondoAide and a “Rendez-vous” event on the board calendar, without the name, phone number or reason, and the invitation is sent to their email by the email service described in section 3. The form asks them not to enter sensitive information in the reason. The hours and rules a member sets are changed only by that member; they serve only to compute the open times shown to the person who opens a link where the member is expected, and to the board when it moves a meeting where the member is expected. If the person who booked declines the invitation from their calendar before the meeting starts, their calendar sends an email to the board’s address; we read that refusal there, it cancels the meeting as if they had cancelled it themselves, and the member expected is notified. The refusal is only taken into account if the sender’s domain is authenticated and the sender is the person who booked; once the meeting has started, it is only recorded with their invitation.
• CondoAide demonstration booked with the CondoAide team: a person who books a demonstration through a booking link of the CondoAide team gives their name, their email and, if they wish, their phone number and the reason for the meeting; we also keep the time of the meeting. CondoAide then collects this information on its own behalf, not for a syndicate. If the CondoAide team records the demonstration, each participant is asked, before joining, whether they consent to the recording of their voice and, separately, to the summary produced by artificial intelligence; refusing does not prevent them from taking part. For each person who consents, we record their voice on a separate track, the displayed name, the time of their consent and the version of the notice they read, then the transcript of what they said.
• Recording of a meeting held online: when the board of directors decides to record an assembly meeting, a board meeting or a meeting held in CondoAide, each participant is asked, before joining, whether they consent to being recorded. Refusing does not prevent anyone from attending, speaking or voting. For each person who consents, we record their voice on a separate track, their display name, the time of their consent and the version of the notice they read, then the transcript of what they said. For an assembly meeting, a board meeting or a meeting held in CondoAide, when the syndicate’s plan includes it and the notice the person read names it, we also record, on separate tracks under their name, their camera image while it is on and the screen they share; keeping the camera off is enough not to be filmed, and their voice is then recorded alone. A person who consented under the earlier notice, which covered the voice only, is filmed only after accepting the new notice. A shared screen is never recorded during a secret vote: the track stops two seconds before the vote opens, and an image or a screen can be watched only once that cut is made. No face analysis is done (no recognition, no faceprint, no use by the artificial intelligence summary). When the syndicate has chosen artificial intelligence summaries, each recorded person also chooses, separately, whether their words may be used for them, and we log that choice. In an assembly held both in a room and online, the room microphone, which picks up everyone present on a single track called « Salle » (room), is recorded only if the chair attests, after reading them a notice, that each of them consents; we log that attestation and the chair’s name. A person who refuses tells the chair, who does not start the room microphone, or steps out of the room. We also log the main steps of the meeting (start of each agenda item, opening and closing of a vote with its totals only, pauses), which serve as chapters, and each time a recording is listened to. You can withdraw your consent at any time during the meeting; recording of your voice, your image and your screen then stops, and what was recorded before the withdrawal is kept for the period in section 5. When a person signed in to CondoAide joins a meeting through the invitation link and is a member of the syndicate (co-owner, tenant, director or manager), we tie their account to their participation, so they can listen again to the meeting their voice was recorded in. The board of directors can tie a meeting’s recording to the vendor, private portion, work or request it was about; doing so changes neither who can listen to it nor how long it is kept. The board can file the transcript and the summary of a meeting with the work or request it was about; they are then kept until three years after that file is closed, while the audio recording is not. The recordings a person can listen to are gathered under « Enregistrements » (Recordings) in the application; when a recording is ready, the board of directors and, for a meeting, the syndicate members whose voice was recorded are notified in the application.
• CondoAide mobile app: the app for iPhone and Android shows the information the website already shows you, with the same access rights. Your session is kept on the phone encrypted, and its key in the phone's protected keychain; the app also keeps on the phone your choice of a Face ID or fingerprint lock, the last syndicate and unit you opened, the language and the theme. It keeps no copy of the information it displays on the phone, except the temporary copy of a document you open, deleted when you close the screen, and everything is erased when you sign out. Face or fingerprint recognition is done by the phone: we receive no biometric data. A photo you take or choose for a request or for a proof of insurance is sent as it is from the website. App errors are sent to our GlitchTip installation (section 3), with the phone's model and operating system and a random installation identifier, not linked to your account. The app contains no analytics or advertising tool.
• Mobile app notifications: if you allow the mobile app's notifications, we receive the notification token that Expo assigns to your phone, a random installation identifier, the platform (iOS or Android) and the app version, linked to your account and to the sign-in session that registered the phone. We also keep your notification preferences by category and, for each notice, the technical identifier of the delivery receipt that Expo returns to us. We do not collect the device's phone number or location.
• Connected calendars: a board member or a member of a management company’s staff may, if they wish, connect one or more of their own Google or Microsoft calendars from their profile; nothing is connected by default. We then collect the email address and identifier of the connected account, the names of the calendars in that account (so they can choose which ones count) and their choices, the connection’s status and the time of the last check, an authorization token stored encrypted, and the times they are busy over the next 90 days (start and end and, for a Microsoft calendar, whether the event is tentative or all-day). We receive neither the title, the location, the description nor the attendees of their events, and nothing about anyone else.
• Syndicate calendar: the board of directors and the staff of the syndicate’s management company enter events in it (title, description, place, optional video-call link, time and recurrence), and we keep the author of each. Each event has a level that decides who reads it: “Whole building” (anyone linked to a unit of the syndicate, as well as the board and the management company’s staff), “Co-owners” (co-owners, the board and the management company’s staff), “Board” (board members and the management company’s staff) or “Only me” (the board member who created it; other board members see a “Busy” block at those times, with no title or details, and the management company’s staff sees nothing of it). An event may target certain units: it is then shown only to those of their occupants who already read that level, as well as to the board and the management company’s staff. At the “Whole building” and “Co-owners” levels, an event cannot contain a unit number or the full name of a person on the member list. The calendar also shows, without copying them, the dates of the syndicate’s meetings, work, maintenance, contribution due dates, insurance, compliance and documents; at those two levels, a title or place that contains a unit number or the full name of a person on the member list is not shown, and contribution due dates carry no amount.
• Calendar subscription and the board calendar on a device: if you create a subscription link to your syndicate’s calendar, we keep only a fingerprint of that link, with your identifier and its creation date. The calendar app you choose (Apple, Google, Microsoft or another) then downloads by itself, under the terms of the company that offers it, the “Whole building” and “Co-owners” events meant for you, including those that target your own unit; each is reduced to its title, time, place and a link to the calendar. Their content does not name you, but the presence of such an event tells that company that a notice concerns you. The link never carries board events or “Only me” events. If you are a board member and add the board calendar to an iPhone or iPad, we create an access for that device whose password we keep only as a fingerprint, with a random identifier, the name you give it, the device type, its creation and last-sync dates and a fingerprint of that sync’s network. We also keep a log of at most one line per hour: the time, the device type, the number of syncs and a fingerprint of the originating network, never the IP address itself, to warn you if the access seems to be used in two places. We write to you when a device first syncs, and if an access seems to be used in two places; these notices contain only a link. The device downloads the calendar from CondoAide itself, without going through iCloud.
• Planning board meetings: if you are a board member and answer a poll to set the date of a meeting, your answer for each time slot is visible to the other board members and to the staff of the syndicate’s management company; members who have not answered receive a single reminder, which contains only a link. If the board invites an outside person to a meeting, we keep their email address and, if the board provides it, their name, to send them the invitation, its updates and its cancellation, from the syndicate board’s address or CondoAide’s, through the email service described in section 3. Each invited person receives their own invitation, without the list of the other invited people or the meeting’s description. When the invited person answers from their calendar (accept, maybe, decline), their calendar sends an email to the board’s address; we read their answer from it, keep it with its date in the invitation, and the board sees it in the list of invited people. That email is filed in the board’s mail without notifying the board, and grouped with the other answers to the same meeting.
• Connecting a syndicate storage space (archive copy): when the syndicate’s account owner connects a OneDrive account to receive the weekly copy of the archives, we keep the email address and the type (personal or organization) of the connected Microsoft account, the technical identifier Microsoft assigns it, the encrypted access token Microsoft gives us, the date of the board of directors’ decision, the name of the person who attests it, the date of the attestation and the version of the text they read, as well as their choices to include email and recordings or not. Each copy, successful or not, and each change of these choices are recorded in the syndicate’s audit log.
• Importing the syndicate’s mail history from a Microsoft account: instead of uploading an export, a board member can connect the Outlook.com, Hotmail or Microsoft 365 account of the syndicate’s previous address, then choose the folders to import. With the permission that person gives Microsoft (read-only access to mail), CondoAide reads the account’s list of folders, so they can choose, then the emails of the last 36 months in the checked folders; they join the syndicate’s mailbox like those of an uploaded export, available to the same people and kept for the same period, counted from the date of receipt that Microsoft reports. CondoAide reads no email from a folder that was not checked, and changes, moves or deletes nothing in the connected account. We keep, with the import summary, the email address and type (personal or organization) of the connected Microsoft account, and the names of the imported folders as Microsoft displays them, for 36 months after the import ends (section 5). The authorization token Microsoft gives us, kept encrypted, the identifiers of the chosen folders and the list of emails to import are kept only for the duration of the import (section 5).

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
• Read, at an authorized person's request, the syndicate's bank account statement imported as a PDF in order to record its transactions and reconcile each bank account with its statement, and file a copy of it in the syndicate's registry under the Bank statements category, accessible to the board of directors only
• Process your payments and manage your subscription
• Prepare, on the syndicate's behalf, the file Zūm Rails requires to verify the syndicate before activating the collection of fees by pre-authorized debit, and send it to Zūm Rails; receive, for the syndicate and at an email address CondoAide manages, Zūm Rails' correspondence about that file and pass it on to the designated board member
• 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
• Honour your delivery choices: email you only the optional reminders you keep turned on, have the syndicate's official notices sent to you by mail, through the board of directors, if you ask for it, and keep proof of your agreement to receive the syndicate's notices by email
• 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
• Write to you about CondoAide in Ontario if you joined the Ontario waitlist, and use the role and number of units you gave us to decide what to build first for Ontario. You are added only once you confirm your address through the link we send you; these emails are separate from the newsletter, and each one has an unsubscribe link
• 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, for a service request, by a mobile app notification if you allowed it; 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.
• Alert you on your phone, if you allowed it in the mobile app, that an action is waiting for you or that activity concerns you in your syndicate: a payment to approve, a new message from the board of directors, a new request to handle, a reply or a mention in a request, a new email in the syndicate mailbox. These notices add to the emails and in-platform notices without replacing them. You can turn off each category in the app's Profile > Notifications, or withdraw the permission in your phone's settings. The phone's information is used for no other purpose.
• Notify the co-owners of a private portion who already owned it on the day of filing when that portion's tenant files a service request, and notify the tenant and those co-owners 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 and publish on our website an overall satisfaction rate, computed over at least 20 ratings, that neither names nor allows anyone to recognize a person or a syndicate
• Set up the syndicate in the Service from the files the board entrusts to us for an assisted setup, solely for that purpose and with its express authorization, which a board member can withdraw at any time
• Co-owner preview: let a board member who manages members display the app, read only, as a co-owner sees it, to help them find their way. No action can be taken on the co-owner’s behalf, nothing is shown that the board cannot already read, and each opening of the preview is recorded in the syndicate’s journal, read by the board only.
• 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
• Produce, at the request of the person who asks an Ontario condominium corporation for it, the status certificate that Ontario law requires the corporation to give (Ontario Condominium Act, 1998, s. 76), show the statutory dates computed from the dates recorded, and file the certificate in the corporation's documents, accessible to its board
• Prepare, for an Ontario condominium corporation, the information certificates Ontario law requires it to send its owners (Ontario Condominium Act, 1998, s. 26.3), show their due dates, make them available to the owners in the corporation's documents and record their sending
• Let the board of an Ontario condominium corporation record its directors' mandatory training (Ontario Condominium Act, 1998, s. 29 (2) (e)), show its deadline and keep the certificate of completion among its documents
• Let the board of an Ontario condominium corporation record each reserve fund study, the proposed funding plan and the notice to owners (Ontario Condominium Act, 1998, s. 94 (8)-(10)), show the dates the Act sets, and keep these documents with its own
• Let the owner of a unit of an Ontario condominium corporation request to examine or obtain copies of the corporation's records, and let the board answer on the prescribed forms, compute the fees and statutory deadlines and record the deliveries (Ontario Condominium Act, 1998, s. 55; O. Reg. 48/01, ss. 13.3 to 13.10)
• Allow the board of an Ontario condominium corporation to receive and check proxies on the prescribed form, establish quorum, count the votes and give the owner and the holders a copy of the form (Ontario Condominium Act, 1998, s. 52)
• Allow the board of an Ontario condominium corporation to follow the obligations that the law, the declaration or the by-laws place on owners, and to receive the notices that section 83 of the Ontario Condominium Act, 1998 requires the owner to give it
• Plan help to evacuate the occupants of an Ontario condominium corporation who expressly consent to it, and give that information to firefighters and other emergency responders
• 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
• Optional sign-up: let the board of directors build, with the consent of each co-owner who signs up their private portion, the list it gives itself to the recipient it named (for example its snow-removal contractor), for the sole purpose stated in the consent text. Signing up is optional, and the person can change or withdraw their answer at any time; withdrawing deletes the answer. CondoAide transmits nothing to that recipient and sends no text message: the list is disclosed by the syndicate, which is responsible for it.
• Prepare, for the syndicate, the firefighter book it makes available to the fire department, and let the board of directors know whom to look for in each unit during an emergency, from occupancy records, emergency contacts and household members; household members are used for no other purpose
• 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
• Keep the syndicate’s register of spaces (who uses a space, on what basis and until when) and, when the board of directors chooses to, recharge to the private portion that uses a space the rent the syndicate itself pays for that space
• Hold assembly meetings remotely or in hybrid form, as article 1088.1 of the Civil Code of Québec allows, as well as board meetings and meetings held in CondoAide, by letting participants see and hear each other and communicate immediately.
• Help the secretary of an assembly meeting or a board meeting write accurate minutes, and let the people the board of directors authorizes listen to it again while its decisions can still be challenged; when the syndicate has chosen it, offer the board of directors and, if there is one, the syndicate’s manager a summary of each agenda item, which they review before using it in the minutes. For a meeting held in CondoAide, let the board of directors and the recorded people find it again, including from the record of the vendor, work or request it was about; when the syndicate has chosen it, give a summary of the meeting to the board of directors and, if there is one, the syndicate’s manager, and to no one else. These recordings are used for nothing else: not to train a model, not for profiling, not to recognize voices or faces.
• Connected calendars: avoid proposing a meeting to a board member at a time when they are busy. The other board members of the syndicates where they sit on the board see “Busy” blocks on the board calendar, with no title or detail; co-owners, other syndicates and the management company’s staff see none of it. These times are used for no other purpose.
• Booking a meeting: to arrange the meeting that an outside person books with a board member, send them its invitation and let the board prepare for it. The name, email, phone number and reason are read by the syndicate’s board of directors, and are used for no other purpose.
• CondoAide demonstration: to arrange the demonstration a person books with the CondoAide team, send them the invitation, and contact them afterwards about CondoAide, which they can stop at any time by writing to us. When the demonstration is recorded with their consent, to let the CondoAide team review their questions and needs so it can answer them accurately; the recording serves no other purpose and is never published. Only the CondoAide team reads this information.
• Syndicate calendar: inform each person of the life of the building that concerns them (interruptions, work, meetings, due dates), at their own level; let the board of directors plan its meetings, set their date through a poll and invite outside people to them. The subscription link and a device’s access serve only to carry these events into the calendar app the person chooses; the sync log serves only to show the last sync and to warn the person when an access seems to be used in two places. This information is used for no other purpose.
• Deliver to the syndicate, at the request of its account owner, the complete archive of its data (register and documents, co-owners and occupants, finances and payments, requests and work, meetings and votes, the syndicate’s email and files), in open formats; each download is recorded in the syndicate’s register journal, with the date and the person
• Copy every week, on the syndicate’s behalf and on its board of directors’ instruction, the complete archive of its data into the storage space it connected (section 3); the syndicate’s email and the recordings are copied there only if the board chose to, and bank account numbers appear there only in part

3. Sharing of Information

We do not sell your personal information. We share certain information with the following providers. Those who act on our behalf are sub-processors bound by a data processing agreement; the description of a provider that does not act on our behalf says so:

• 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 and PAD/ACSS Debit bank withdrawals from the syndicate to CondoAide). Stripe also keeps, on the syndicates' behalf, the mandates and condo-fee debit history set up with Stripe before condo-fee collection moved to Zūm Rails. Categories: payer name, email, billing address, payment method, subscription transaction history; for those earlier condo-fee debits, co-owners' banking information, the technical account identifier of the person who authorized the mandate, the private portion’s identifier and transaction history. Location: Canada and United States.
• Zūm Rails — Condo-fee collection by pre-authorized debit (PAD): debit from the co-owner's account, deposit in the syndicate's wallet at Zūm Rails and payout into the syndicate's bank account, handling of refused or returned debits and disputes, and transaction reconciliation. Categories: the paying co-owner's name and email, the building's address, a random technical identifier that ties them to the mandate; the syndicate's name and address, the email of the person who links the syndicate's bank account; amounts, dates, statuses, refusal reasons, transaction identifiers, the debit's descriptor on the bank statement (the syndicate's name) and the description of fees entered by the board of directors. To verify the syndicate, CondoAide sends Zūm Rails, on the syndicate's behalf, the file gathered in CondoAide (section 1): the syndicate's legal name, NEQ, address, the publication date of its declaration of co-ownership, the name it files under with the Canada Revenue Agency, its number of employees and phone number, expected volumes, the names, offices and emails of the directors and of the contact person (that email may be an address CondoAide manages for the syndicate: CondoAide's team then receives Zūm Rails' correspondence about the file, keeps it in its mail like any message received, and may pass it on, with its attachments, to the designated board member, through Amazon SES in Montréal), the board's answer on politically exposed persons, the service agreement signed by the officers, the signatory's photo ID, when they uploaded it in CondoAide, and the file's documents, including the syndicate's bank statements, which may show co-owners' names and the amounts they paid; the person who signs for the syndicate provides their other personal information directly to Zūm Rails, in its form, and their identity document if they did not upload it in CondoAide. The co-owner enters their banking details directly in Zūm Connect; CondoAide does not receive them. For these banking details, Zūm Rails does not act on our behalf: it collects them in its capacity as a payment service provider, is responsible for them and keeps them, with the payment records, in accordance with its own legal obligations, notably on anti-money laundering, and with the rules of Payments Canada, under its own privacy policy. Consent to the mandate is collected and kept by CondoAide (section 1). Location: Québec (Montréal); our written agreement prohibits any transfer, storage or processing outside Québec of the information we send it, without our prior written approval.
• Zūm Rails, mandate signed on paper: for a mandate signed on paper, the co-owner does not go through Zūm Connect: CondoAide sends Zūm Rails the institution, transit and account numbers they wrote on the mandate, without recording them in its systems (section 1). Neither the scanned mandate nor the scanned void cheque or letter from the financial institution is sent to Zūm Rails.
• 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, Ontario waitlist, 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; the company we contract with is SIB Inc., in the United States.
• Cloudflare (Turnstile bot check) — Bot check on public forms: signing in, signing up, password reset, CondoAide's contact form and the one on syndicates' public pages, requests to a professional, testimonials, newsletter and Ontario waitlist 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 pages of the file that carry the particular conditions and the insured locations (at most 40, chosen from their text; failing that, the first 15 pages) and its name are sent to extract the form's fields and each building's insured amount, 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. Reading the image of the table of fractions, when our rules cannot read it: at the request of an authorized board member, who sees the exact image before sending it, the image of one page of the table, cropped in Quebec to the region of the table only, in grayscale, reduced and without metadata (one page per request, at most 4 per read); the request is cancelled if our reading of the image finds a person's name in it, but the image may show a name, initials or a signature that this reading did not recognize. This request always requires that person's action: neither a read asked for by our support team nor the free public tool makes it. The log of each request holds only the page, the cropped region, the image size and the model used, never the image, which CondoAide keeps nowhere. Categories: text of declaration pages, names of people removed from that text; cropped image of one page of the table of fractions, which may show a name, initials or a signature. Location: United States; terms in section 9.
• Anthropic (support reply drafts) — When CondoAide's team prepares the answer to a report sent to support, its assistant (Claude, by Anthropic) may read the report's subject and text and the messages of its thread, including the team's internal notes, as well as the opinion the person gave of the answer and its comment, to propose a draft. It receives neither the syndicate's name, nor the identity of the messages' authors, nor the technical information attached to the report (pages, browser, session recording); the text may still name people. The draft is kept in CondoAide, and a team member reads it and sends it themselves. Categories: text of the report and messages, which may name people; opinion of the answer and comment. Location: United States; conditions in section 9.
• Anthropic (reading a water heater's plate) — When a board member imports the building's water heaters from photos of their rating plates, or a person attaches a photo of the plate of a private portion's water heater (section 1), each photo, shrunk and stripped of its metadata, is sent on its own, without the file name, the private portion's number, the syndicate's name or any person's name, to read its brand, model, serial number, manufacture date, capacity and energy source. The result is kept only if the person saves it after checking it. The log of each read holds only the model used, the duration, the token count and, on failure, the kind of error, never the image or the values read. Categories: photo of the plate of an appliance located in a private portion, which may show part of its interior. 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). For a debit mandate signed on paper, it also reads the institution, transit and account numbers printed at the bottom of the void cheque and suggests them to the person recording the mandate, who compares them with the cheque and confirms them; the file is sent to it without its name, and the numbers read are not kept. 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, and, for a void cheque, the name and address printed on it and the institution, transit and account numbers. Location: Canada (Beauharnois, Québec). Self-hosted software; the operational sub-processor is OVHcloud.
• OVHcloud (self-hosted antivirus) — Hosts our self-hosted antivirus (ClamAV), which scans every attachment of an email imported into the syndicate's mailbox from its previous address before it can be opened. The file is read during the scan and then discarded by this service; only the result (clean, infected with the name of the detected signature, or impossible to scan) is recorded in the application. Categories: content of the attachments of imported emails, which can hold any information a correspondent put in them. Location: Canada (Beauharnois, Quebec). Self-hosted software; the operating 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, board meetings and meetings held online in CondoAide. A meeting is recorded only if the board of directors decided so for that meeting, and only the people who consent are recorded, each on their own tracks: their voice and, when the syndicate’s plan includes it, their image and shared screen; a person who refuses is in no file (section 1). In a meeting held online, it also relays the meeting's chat messages, in real time and without keeping them. Categories: participants’ image and voice during the meeting, display name, connection timestamps, chat messages of a meeting, while in transit; for a recorded meeting, the voice and, where applicable, the image and shared screen of the people who consented. Location: Canada (Beauharnois, Quebec). Self-hosted software - LiveKit Inc. is not a sub-processor; the operational sub-processor is OVHcloud.
• OVHcloud (self-hosted meeting recording, transcription and summary) — Hosting, on the same server as the video conference, of meeting recording, transcription and the optional summary. After the meeting, the tracks of the people who consented are combined into one listening file, then transcribed by a speech recognition model (Whisper) that we run ourselves; each passage is attributed to the signed-in person it comes from, never by recognizing their voice. No voiceprint is computed or kept. Image and screen tracks are never analyzed (no recognition, no detection, no extraction of their content): they are only re-encoded, that is decoded and compressed again, so that the replay can move to any moment, and cut before a secret vote or after a consent withdrawal. When the syndicate has chosen artificial intelligence summaries, an open-weight language model we run on the same server drafts a summary of each agenda item of an assembly meeting or a board of directors meeting, or a summary of a meeting held in CondoAide, using only the words of the people who agreed to it separately; a room microphone is never used, and only a vote’s totals are given to it. Only the board of directors and, if there is one, the syndicate’s manager read these summaries; they review an assembly or board meeting’s summary before using it in the minutes. Categories: voice and, where applicable, image and shared screen of the people who consented, text of what they said, display name, summary. Location: Canada (Beauharnois, Quebec). Self-hosted software - no data leaves Quebec.
• OVHcloud Object Storage (recording files) — Storage of the audio and, where applicable, video (image and shared screen) files of recorded meetings, in private storage spaces. A file is read only through a short-lived link, issued after checking that the person may listen to it, and each listening is logged (one line each time a person starts playback from the page, even if playback restarts several times). Files are destroyed on the periods in section 5 and are not copied into our backups. Categories: voice and, where applicable, image and shared screen of the people who consented to the recording. Location: Canada (Beauharnois, Quebec).
• Expo, with Apple and Google (mobile app notifications) — Delivery of the mobile app's notifications, if you allowed them. Expo (650 Industries, Inc.) receives your phone's token and the notice, then hands it to Apple's (Apple Push Notification service) or Google's (Firebase Cloud Messaging) notification service, depending on the phone; Apple and Google act as Expo's subprocessors for that delivery. The notice is not end-to-end encrypted: Expo, Apple and Google can read it. That is why it contains only a generic text (for example “New message in your syndicate”) and three technical identifiers: the notice category, the syndicate identifier and the identifier of the item concerned. It never contains a name, an email address, an amount, a vote, a request subject or message content, and a personal-information access or correction request is designated like any other request. Categories: phone token, generic notice and technical identifiers. Location: United States; terms in section 9.
• Google (connected Google calendars) — Only if a board member or a member of a management company’s staff connects their own Google calendar (section 1): CondoAide asks Google, on that person’s behalf and with their authorization, for the times they are busy. Google receives the authorization token, the identifiers of the calendars the person chose and the period to check (at most the next 90 days); it receives nothing about anyone else. The permissions requested are limited to reading busy times and the list of calendars. Google does not act on our behalf: it is the provider the person chose for their own calendar, and it handles this information as an independent controller, under its own terms and privacy policy; no data processing agreement binds it to CondoAide. Its API terms govern what CondoAide does with the information it receives from Google. Categories: Google account email address, calendar identifiers, busy times. Location: United States. Company based in the United States.
• Microsoft (connected Outlook and Microsoft 365 calendars) — Only if a board member or a member of a management company’s staff connects their own Microsoft calendar (section 1): CondoAide asks Microsoft, on that person’s behalf and with their authorization, for the times they are busy. Microsoft offers no permission limited to busy times: the permission requested allows reading events without their description or attachments, and each request asks only for each event’s start, end and status (busy, tentative, all-day); the title, location and attendees are never sent to CondoAide. Microsoft receives the authorization token, the identifiers of the calendars chosen and the period to check (at most the next 90 days); it receives nothing about anyone else. Microsoft does not act on our behalf: it is the provider the person chose for their own calendar, and it handles this information as an independent controller, under its own terms and privacy policy; no data processing agreement binds it to CondoAide. Its API terms govern what CondoAide does with the information it receives from Microsoft. Categories: Microsoft account email address, calendar identifiers, busy times. Location: outside Québec, in the United States or another Microsoft region depending on the person’s account. Company based in the United States.
• Provider of the assistant you connect (MCP connector) — Only if a board member or a manager connects their own artificial intelligence assistant to CondoAide (section 1): the assistant receives, at that person's request, what they can already read in the app, under the same permissions, and what they have it import. This provider (for example Anthropic for Claude or OpenAI for ChatGPT) does not act on our behalf: the person chose it, and it handles this information as an independent controller, under its own terms and privacy policy; no data processing agreement binds it to CondoAide for this connector. Categories: depending on the tools used, information about the syndicate, the units, the members (name, email address, role), the finances and the registry. Location: that of the chosen provider, often the United States.
• 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. For a licence, it also returns what three public registries of Données Québec publish about its holder (RENA, environmental administrative monetary penalties, SEAO public contracts); CondoAide keeps only the status, the dates and the totals, never the names. 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.
• Microsoft (OneDrive connected by a syndicate for the copy of its archives) — Only if a syndicate’s board of directors decides to receive every week, in a OneDrive account it connects itself, the complete copy of the syndicate’s archives (section 1): CondoAide then writes into that account, on the syndicate’s behalf and with the authorization the account owner gave Microsoft, and only in a folder reserved for the application (“Files.ReadWrite.AppFolder” permission); it neither reads nor changes any other file in the account. Categories: everything the syndicate’s archive holds (register and documents, co-owners and occupants with their contact details, finances and payments with bank account numbers masked, requests and work, meetings and votes), plus the syndicate’s email and the recordings if the board included them. Microsoft does not act on our behalf: it is the provider the syndicate chose to keep its own copy, and that copy is under the syndicate’s responsibility. Location: decided by Microsoft according to the connected account, possibly outside Quebec (section 9). This flow takes place only while the account is connected; copies already sent remain in the account after disconnection.
• Microsoft (account connected to import the syndicate’s mail history) — Only if a board member connects the Microsoft account of the syndicate’s previous address to import its mail (section 1): CondoAide then queries Microsoft, with the permission that person gives Microsoft (“Mail.Read”, read-only access to mail, and “User.Read”, read access to the account’s basic profile), to list the account’s folders and download the emails of the last 36 months in the chosen folders. Microsoft offers no permission limited to certain folders: “Mail.Read” allows reading all of the account’s mail, but CondoAide requests only the list of folders and the emails in the chosen folders. Microsoft receives the authorization token, the identifiers of the folders and emails requested and the date from which to search; CondoAide sends it nothing else. Microsoft does not act on our behalf: it is the provider the syndicate chose for its previous address, and which already holds these emails, under the terms that bind it to the syndicate; no data processing agreement binds it to CondoAide. Categories: email address and type of the Microsoft account, identifiers of folders and emails. Location: decided by Microsoft depending on the connected account, possibly outside Quebec (section 9). Company established in the United States. This flow takes place only during the import.

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. Video conferencing for meetings runs through our own server, at OVHcloud in Beauharnois (Quebec), not through an outside video-conferencing service.
• Access controls: strict role-based permissions, logging of all sensitive actions
• Backups in Quebec: daily Supabase snapshots of the database; additional encrypted backups, including a copy of the database every 4 hours, kept at two distinct Quebec providers (Montreal and Beauharnois), 30-day retention
• Tokenization: credit card and bank account numbers are never recorded in plain text in our databases. Those for the subscription are tokenized by Stripe (PCI DSS Level 1 certified for card data); co-owners' are entered directly in Zūm Connect, at Zūm Rails. The one exception is the scanned copy of a mandate signed on paper, which carries these numbers in the co-owner's hand; it is kept in private storage in Québec (section 1).
• 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 data of a personal account and of a syndicate account — A personal account (sign-in and profile) is deleted as soon as you delete it, unless otherwise required by law; a syndicate’s account, 90 days after it is closed. Encrypted copies may remain in our backups for up to 30 days. The steps, and what is kept, are on the Account deletion page.
• Proof of acceptance of the terms — Kept as long as your personal account exists and deleted with it. Deleting a syndicate removes only the link to that syndicate; the date, version and context of your acceptance are kept with your account.
• 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. The cropped image of one page of the table of fractions, sent to Anthropic at the board's request, is kept neither by CondoAide nor by our analysis service: it is produced for the request and destroyed as soon as the request ends, and the request log keeps only its page, region, size and the model used. 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, including the evidence of the authorization of a plan change and of the notice waiver that comes with it, for tax, accounting and legal-compliance purposes, including Payments Canada Rule H1.
• Subscription transaction data (payments to CondoAide) — 7 years for tax, accounting and regulatory compliance purposes.
• Co-owner condo-fee collection PAD mandate (Payment Service: proof of the mandate's acceptance and metadata held by us; for a mandate set up with Stripe before the move to Zūm Rails, 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. Zūm Rails keeps the banking details and payment records it collects itself, as a separate controller, for as long as its own legal obligations require (notably anti-money laundering and Payments Canada Rule H1), under its own privacy policy.
• Scanned copies of the mandate signed on paper and of the void cheque or letter from the financial institution, and the account's last four digits — 7 years after the mandate ends, like the mandate itself. The full numbers entered from the mandate are not recorded in our systems; only the scanned copies of the mandate and of the void cheque or letter carry them. They are sent to Zūm Rails and recorded nowhere else. If entering a paper mandate does not complete, these scanned copies are destroyed automatically within two days, and the user created at Zūm Rails with those numbers is deleted there.
• Syndicate verification file for Zūm Rails — The void cheque or letter from the financial institution, the bank statements and the proof of address are destroyed 90 days after Zūm Rails decides to approve or refuse the syndicate, or 90 days after the last activity on the file when Zūm Rails has made no decision; no document is destroyed while Zūm Rails is reviewing the file. Any replaced document, of any kind, is destroyed 30 days after it is replaced, and an unfinished upload after 24 hours. Of these destroyed documents, we keep only their type, dates, digital fingerprint and verification result. As an exception, the signatory's photo ID is destroyed 24 hours after it is sent to Zūm Rails and 30 days after upload at the latest; it is also destroyed as soon as it is replaced, or as soon as that person is no longer the syndicate's contact person and signatory. It is never copied into our backups. We keep only its page count, dates, the version of the consent given and its digital fingerprint. The list of directors, the attestation of the board's composition and the Registraire des entreprises' état de renseignements are kept as long as the syndicate's account exists, and deleted with it. Zūm Rails keeps what it receives according to its own legal obligations, including anti-money-laundering obligations.
• Authorization attempts for a private portion’s PAD mandate (person who opens the authorization and their co-owner status; on Zūm Rails, the account that accepts the mandate and the time of acceptance) — 30 days when the authorization is not completed; on Zūm Rails, the identity of the person who accepted and the time of acceptance are then deleted. Seven years after its use when it is, that is the retention period of the mandate it served to establish. A scheduled task removes abandoned attempts older than 30 days every night.
• 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) - Quebec — 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) - Quebec — 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.
• Board composition approvals (directors and their offices, the signer and their office, date, fingerprint of the signed document) — Kept as long as the syndicate's file exists, and destroyed with it, including approvals a change of composition replaced, because they form the board's history. The signed document is filed in the syndicate's registry, under “Board composition”, where it is kept permanently, like the board's minutes: nobody can delete it from there. Only the board of directors and the person who signed can read them, on the Members page and in the registry; nobody can change them.
• Audit logs (sensitive actions) — 7 years for compliance purposes. The edit history of an entry in the syndicate’s ledger (fields changed, previous values, author and time) is kept as long as the entry and destroyed with it.
• 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.
• Assisted setup files — 60 days after the setup ends, that is, when the ticket is resolved; if the ticket is reopened, the period starts again at its next resolution. When a board member deletes the files, they are removed from the ticket at once, then destroyed, normally within the hour. A document our team files in the syndicate’s registry during the setup becomes a syndicate document and follows the retention of its registry. The proof of authorization and withdrawal follows the retention of support communications; the log of staff downloads follows that of audit logs.
• 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, with one exception: for a convocation to an assembly or a board meeting and for an addition to the agenda, CondoAide keeps an exact copy of each document attached to the email in its private storage in Québec, and records its name, size and digital fingerprint (SHA-256), so that the syndicate can establish what each recipient received. The fingerprint is deleted with the last row of the sending; the copy is deleted after a seven-day grace period, once no sending refers to it. A document sent to several recipients is kept only once. 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, or 30 days after a board member deletes the conversation if that comes first; during those 30 days the conversation is in the board's trash and can be restored. 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, and cannot be deleted.
• Message sent through the contact form on a syndicate's public page (name, unverified email address, message) — Same rules as emails received in the syndicate's mailbox: 36 months from receipt, or 30 days after a board member deletes the conversation if that happens first. The anti-abuse counter for submissions (an irreversible fingerprint of the IP address, computed with a server key, and the syndicate's identifier) expires after one hour.
• Emails imported from the syndicate's previous address (message, attachments, sender address and other named recipients, antivirus result) — 36 months from the date the previous mailbox received the email, as recorded in the export, and never more than 36 months after the import; an email already older is not imported. The rules for received emails then apply: 30-day trash, filing to a record and legal hold. The export file uploaded for the import is destroyed when the import ends, or 7 days after it was uploaded if the import does not complete.
• Import from a Microsoft account (authorization token, chosen folders, list of emails to import; email address and type of the connected account, names of the imported folders) — The authorization token, the chosen folders and the list of emails to import are destroyed as soon as the import ends, fails or is cancelled, 24 hours after connecting if no folder was chosen, after 7 days without progress, or as soon as the person who connected the account no longer has access to the syndicate’s mailbox. The email address and type of the connected account, and the names of the imported folders, are kept with the import summary for 36 months after the import ends, then erased; the summary itself (number of emails imported and result) remains for as long as the syndicate’s file exists. Imported emails follow the row “Emails imported from the syndicate’s previous address”, counted from the date of receipt that Microsoft reports.
• Mail tags (name and colour of the tag, the conversations carrying it, the person who created or applied it) — The link between a tag and a conversation is destroyed when the board removes it or deletes the tag, and with the conversation's last email and last reply. The tag itself stays in the syndicate's file until the board deletes it, and at the latest until that file is destroyed.
• Board reply or new email sent from the syndicate's mailbox — 36 months from sending, or 30 days after a board member deletes the conversation if that comes first, 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.
• Confirmed Ontario waitlist signup (email address, role, number of units, confirmation date) — Kept until you unsubscribe, through the link in every email or by writing to privacy@condoaide.ca. When you unsubscribe, we stop writing to you at once; the signup stays in our database, marked as withdrawn, until its destruction is in place, which will keep only the address and the date of withdrawal. Because our email provider unsubscribes an address rather than a list, unsubscribing from the Ontario emails also ends the newsletter, if you receive it. An unconfirmed signup is deleted 30 days after the confirmation email is sent, together with the role and number of units given. The address is sent to Brevo only once the signup is confirmed; the role and number of units are not sent to it.
• 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, sign-in and password-reset 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. Password sign-in attempts and password-reset requests are limited the same way, by a keyed hash of the IP address that expires after 15 minutes.
• Invitation and link code abuse counters (keyed hash of the IP address, internal user and account identifiers) — To limit attempts at QR invitation codes and at gestionnaire or phase link codes, we count attempts without keeping the IP address in clear or the code tried: the irreversible hash of an IP address that tried a wrong code, computed with a server key (for an IPv6 address, its /64 prefix), expires after 10 minutes; the internal identifier of the user accepting an invitation, after 10 minutes; the internal identifiers of the user and of the account entering a wrong link code, after 24 hours.
• Record of an accepted invitation (irreversible fingerprint of the invitation link, syndicate joined, person who accepted it, date) — When a person accepts an invitation to join a syndicate, the invitation is deleted; we keep only an irreversible fingerprint of its link, never the link itself, with the syndicate joined, the person’s internal identifier and the date. It is used only to tell the person who opens that link again that the invitation was already accepted and to take them to their syndicate. Destroyed 90 days after acceptance by a daily scheduled job, and earlier with the person’s account or the syndicate’s.
• 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.
• Members of a unit's household (category, age bracket, optional first name) — Destroyed 30 days after the end of the occupancy they are linked to (sale or end of lease), and immediately if that occupancy is removed from the syndicate's register. A person removed from the household is destroyed immediately. A household member of a co-owner stays with the unit as long as a co-owner occupies it: when a co-owner leaves, it is linked to another current co-owner, and it is destroyed 30 days after the last one leaves. A person the board of directors recorded without linking them to an occupancy is kept for as long as the board keeps them; at a change of owner, CondoAide offers to remove them.
• 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.
• Syndicate email delivery preferences (reminders turned off, agreement to receive notices by email and the address concerned, choice of mail delivery for official notices) — 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 copy of the mail-delivery choice included in an archive the syndicate downloads follows that archive's period. In the outbound email queue, the reason an email was not sent (reminder turned off by the board, reminder turned off by you, mail delivery requested) and the link to your account follow the queue's period; the link to your account is erased together with the recipient's address.
• Space leases recorded by the board of directors — Kept until the board of directors deletes them, and destroyed with the space, with the private portion concerned or with the syndicate's account. An ended lease stays visible to the board for 12 months after it ends, then is no longer shown. Months recharged to a private portion are accounting entries of the syndicate and are kept with its books.
• 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.
• Reply drafts on a service request — Visible only to the person writing them. Deleted as soon as the reply is sent, with the request or with that person’s account, and at the latest 90 days after they were last changed.
• 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.
• Access tokens of a connected assistant (MCP connector) and the journal of its calls — The token's name, first characters, scope and dates, and the journal of calls (person, tool, syndicate, date and simple values passed), are kept as long as your account exists and deleted with it; a journal line about a syndicate is also deleted with that syndicate's account. A revoked or expired token stays listed as such, with its journal, but no longer gives any access. The token itself is never kept, only its hash. No shorter period applies for now.
• Record of sending a reply written from a draft proposed by CondoAide's team assistant — The identifiers of the message, of the token and of the person who sent the reply, the draft's dates and whether it was edited before sending are kept with the message, and destroyed with it or with the syndicate's account. This record holds no text.
• 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.
• Answers to an optional sign-up and log of the list's downloads — An answer is deleted as soon as the person withdraws it or the board of directors deletes the form, and all of a form's answers are deleted the day after its end date, which cannot be more than two years away. When a private portion is sold, the answer of a person who leaves the portion is deleted; that of a co-owner who stays is kept. The log of the list's downloads is destroyed one year after the form's end date, or one year after its deletion when the board deletes it. Destroyed answers remain in backups and in syndicate archives already produced, for those copies' own retention periods. The list the board gave its recipient is outside CondoAide: its retention is up to the syndicate and that recipient.
• 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. Notices of meeting are the only exception: the email convening an assembly or a board meeting attaches the notice as a PDF and, for an assembly of co-owners, the documents that must accompany it under article 1087 of the Civil Code of Québec; the updated notice sent after a question is added to the agenda is attached the same way.
• 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.
• Ontario status certificate request and issued certificate — The request (identity, capacity and email of the person who makes it, fee and dates) is kept as long as the corporation's account exists and destroyed with it; a withdrawn request is not deleted. The issued certificate is kept at least seven years from issue, as O. Reg. 48/01 (s. 13.1 (2), para. 5) requires.
• Information certificates (Ontario) — An issued certificate (periodic, update or new owner) is kept at least seven years from issue; O. Reg. 48/01 sets no period for these certificates (s. 13.1 (2), para. 23), and a certificate that relates to one owner is kept seven years (para. 8). The new owner's name recorded for the board is kept with the corporation's account and destroyed with it.
• Director training (Ontario) — The certificate of completion forwarded to the corporation is kept at least seven years from receipt (O. Reg. 48/01, s. 13.1 (1), para. 3, and (2), para. 7). The dates recorded for each term are kept with the corporation's account and destroyed with it; the board may delete a term recorded by mistake.
• Reserve fund studies (Ontario) — Studies, proposed plans and notices, with their dates and the name of the person or firm that conducted each study, are kept at all times, as O. Reg. 48/01 requires (s. 13.1 (2), para. 2), for as long as the corporation's file exists, and destroyed with it. The board can delete a study recorded by mistake; its documents then stay in the corporation's documents.
• Records requests (Ontario) — The request, the board's response, the fees and the deliveries are kept as long as the corporation's account exists and destroyed with it; neither the owner nor the board can delete them, since O. Reg. 48/01 requires records relating to a specific owner to be kept at least seven years (s. 13.1 (1), para. 7, and (2), para. 8). If the owner's login account is deleted, the request remains, with the name and address copied into it.
• 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.
• Bank account statement imported by the syndicate — The statement (each account's transactions, including descriptions that may name a co-owner or a supplier, and balances) 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. It is filed in the registry under the Bank statements category, accessible to the board of directors only. When the period ends, nothing is destroyed automatically: a member of the board of directors may then delete it from the registry. The reconciliation report PDF is produced on request and is not kept anywhere.
• 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, water heater characteristics read from its plate) follows the periods that apply to it in this section.
• Image, voice and shared screen during an online meeting — Not kept: relayed in real time to the participants, then discarded by our server. Only what is shared by the people who consent to the recording of a meeting is kept, for the periods below: their voice and, when the syndicate’s plan includes it, their image and shared screen, for the same periods as the voice.
• Recording and transcript of an assembly meeting — Destroyed 90 days after the meeting, the period to ask the court to annul an assembly decision (art. 1103 of the Civil Code of Québec), or when the minutes are sent if that is later, and no later than 180 days after the meeting. If the board of directors chose it when deciding to record the meeting, and said so in the notice of meeting, they are kept until the minutes are adopted at the next assembly, to settle a dispute about their accuracy, and no later than 13 months after the meeting. A hold the board of directors places because of a dispute suspends destruction.
• Recording and transcript of a board meeting — Destroyed 90 days after the meeting, the period to ask the court to annul a board decision (art. 1086.2 of the Civil Code of Québec), unless held because of a dispute.
• Recording, transcript and summary of a meeting held in CondoAide — Destroyed 30 days after the meeting, unless held because of a dispute. If the board of directors files the transcript and the summary with the work or request the meeting was about, they are kept until three years after that file is closed; the audio and, where applicable, video recording is still destroyed 30 days after the meeting. Merely tying the meeting to a vendor, private portion, work or request does not extend this period.
• Summary of an assembly meeting or a board meeting produced by artificial intelligence — Destroyed as soon as the minutes it helps draft are sent, and never after the recording; produced again without the words of a track the board deletes at the person’s request, or of a person who withdraws their consent to the summary. Text the secretary copies into the minutes becomes part of the minutes and follows their period; it stays as the secretary left it. The summary of a meeting held in CondoAide follows its recording’s period instead, set out above.
• Consent to recording and listening log — Kept while the recording exists, then one year after it is destroyed, to prove who consented and who listened.
• Meeting steps (chapters) — Kept with the assembly record, like the attendance log. They hold only vote totals.
• Registration of a phone for mobile app notifications (notification token, installation identifier, platform, app version, session that registered the phone, last use) — Deleted when the app removes the phone, when the session that registered it signs out, when Expo reports the phone as unregistered, when the same person registers an eleventh device (the least recently used one is removed), and with the account.
• Delivery receipt of a mobile app notification — Deleted once processed, at the latest 24 hours after sending.
• Mobile app notification preferences — Kept until they are changed or the account is deleted.
• 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 (a member’s consent to the recording follows its own period), unless a recording of that meeting is held because of a dispute.
• A meeting booked by an outside person (name, email, optional phone number, reason, time and member expected) — Destroyed 12 months after the meeting ends, with its copy of the invitation, by a daily scheduled task. The invitation message follows the retention of the email sending queue; when it is sent from the syndicate’s address, the sending log keeps its trace (recipient address, date and time) for 7 years.
• Demonstration booked with the CondoAide team (booking, recording, transcript and summary) — The booking (name, email, optional phone number, reason and time) is destroyed 12 months after the end of the meeting, like every booking. The recording, its transcript and the summary are destroyed 30 days after the meeting, unless they are kept because of a dispute; they are never added to a file.
• Busy times from a connected calendar — Kept about 5 minutes, long enough to display the calendar, then deleted; a job purges them every 15 minutes. Only the next 90 days are read, and no past availability is kept.
• Connection of a Google or Microsoft calendar (account address and identifier, calendar names and choices, status, encrypted authorization token) — Deleted as soon as the person chooses “Disconnect”, as soon as they are no longer a board member of any syndicate nor on the staff of any management company, and with their account. The connection is personal: it is never passed on to their successor nor kept by the syndicate.
• Syndicate calendar events and the units they target — Destroyed 36 months after the event ends or, for a series, after its last occurrence, at every level, including “Only me”, by a daily scheduled job. The dates the calendar shows from meetings, work and the syndicate’s other records are not copied: they disappear with their source.
• Invitation of an outside person to a planned board meeting (email address, optional name, status, answer and its date) — Destroyed with the meeting, 36 months after it ends. The invitation message follows the retention of the email sending queue; when it is sent from the syndicate’s address, the sending log keeps its trace (recipient address, date and time) for 7 years.
• Name entered on an invitation to join the syndicate (optional first and last name) — Deleted with the invitation: when it is accepted, cancelled or deleted by the syndicate, and at the latest with the syndicate’s account. An expired invitation that has not been deleted keeps the name until then. When an outside person accepts their invitation before entering their full name, and their role requires an access agreement, the name is carried to their account to prefill the access agreement, then deleted as soon as they sign it, and at the latest with their account.
• Calendar subscription link (fingerprint of the link, person, creation date) — Deleted as soon as you reset or delete it, or lose access to the calendar (leaving the syndicate, end of your last occupancy without a board role, end of your attachment to the management company’s staff); a daily job also deletes any link that no longer grants anything. No fixed period.
• A device’s access to the board calendar (name given to the device, password fingerprint, device type, creation and last-sync dates, fingerprint of the last sync’s network) — Deleted as soon as you remove it, at the latest the day after you leave the board, and with your account or the syndicate; an access never used is deleted at the latest two days after its creation. The download link for the installation profile expires after five minutes.
• A device’s sync log (time, device type, fingerprint of the originating network, number of syncs and network changes in the hour) — Kept 30 days, and deleted with the access. No IP address is kept in it.
• Board date poll and its members’ answers — Destroyed each night once the chosen slot has ended or the linked meeting is closed, or 7 days after the last slot if no date was chosen; destroyed immediately if the poll is withdrawn. The chosen date stays in the event or meeting it set.
• A board member’s availability and booking links (offered hours, time zone, booking rules, links) — Kept until the member or the board changes or deletes them, and at the latest until the member leaves the board: they are then deleted at once. If a booking already made through their link has not yet taken place, they are kept until the last such booking ends, so the guest can still cancel it, then deleted the following night. They are also deleted with the member’s account or the syndicate. The bookings themselves follow their own period.
• Archive downloaded by the syndicate — The copy the account owner downloads is under the syndicate’s responsibility and outside this schedule; CondoAide keeps no copy of it. Only the record of the download (date, person, size) is kept in the register journal, with the register.
• Storage space connected by the syndicate (account, token, attestation and choices) — Kept while the account is connected. On disconnection, the access token is destroyed at once; the account, the attestation and the choices stay recorded, marked as disconnected, for as long as the syndicate’s file exists, so the board can establish who connected what and when. Residual encrypted copies may persist in backups for an additional period of at most 30 days before their rotation and destruction.
• History of copies to the syndicate’s storage space (date, outcome, number of files, cause of a failure) — Kept 36 months after each copy, then deleted. The syndicate’s audit log keeps its own record for its own period.
• Copies of the archives in the syndicate’s storage space — Outside this schedule: they are in the syndicate’s account, under its responsibility, and CondoAide deletes nothing there. Each copy includes the list of documents that have reached the end of their retention period at CondoAide, so the syndicate can destroy them.
• Ontario meeting proxy forms and ballots (signatories, instructions, candidate preferences, scans and superseded ballots) — Kept for at least 90 days after the meeting was actually held or closed, then until the board confirms deletion. Nothing is deleted automatically. Written notice of actual or contemplated litigation about these records, or a request to examine or copy them, including a condominium manager’s request, extends retention under O. Reg. 48/01, s. 13.1 (2), paras. 3 and 4, and s. 13.1 (3) and (4): at least six months after the request or contemplated-litigation notice if no written notice of actual litigation follows and, for actual litigation, until the final order of a court, arbitrator or tribunal or the settlement agreement, plus any longer period the order or agreement requires. The board records coverage, evidence and resolutions. CondoAide also enforces a seven-day wait after a litigation order or settlement is recorded. Deleting a login account detaches its identity links while keeping each ballot’s unit, choices and weight and the names recorded on the forms. A unit with retained proxy or ballot records cannot be deleted until the board has completed their eligible destruction. Minutes, certified results, evidence retained for another purpose and the deletion audit (actor, time and counts) remain with the corporation file. Destroyed individual ballot proofs can no longer be recalculated. Quebec permanent-retention rules remain unchanged.
• Evacuation and special needs (Ontario), and the record of consent — Evacuation and special needs are kept as long as the occupant's record, and deleted as soon as consent is withdrawn or the person leaves the corporation. The record of the consent and its withdrawal is kept as long as the occupant's record in the corporation.
• Lease, renewal and lease-end notices (Ontario) — Kept permanently, as long as the corporation's records exist, and destroyed with them, as required by the Ontario Condominium Act, 1998 (s. 55 (1), para. 6) and O. Reg. 48/01 (s. 13.1 (2), para. 2); neither the owner nor the board can delete them.

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)
• Paper mandate cheque verification: a difference between an entered number and a number automatically read from the cheque prevents the mandate from being recorded, unless the person who manages the syndicate’s payments confirms the numbers written on the signed mandate. The message identifies the field concerned. You can have the cheque checked and the information corrected with the person who manages your syndicate’s payments, or request a review by our privacy officer (section 7).
• Revoke your PAD mandate for the subscription at any time, free of charge, in accordance with Payments Canada Rule H1
• Recording of a meeting: withdraw your consent to being recorded, or only to the artificial intelligence summary, at any time during the meeting, without affecting your participation; obtain, while the recording exists, a copy of the recording of your voice, your image or your screen, or its written transcript, by contacting the syndicate (other people’s words are removed when disclosing them could seriously harm them); and ask the board of directors to delete all your tracks (voice, image and screen), with their transcript and your words in the summary (a single passage cannot be cut on its own).
• 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
• Response time: we answer a request for access or correction in writing within 30 days of receiving it.
• 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. This person is also accountable for our compliance with PIPEDA (Schedule 1, principle 4.1).

• 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.
• Report to the Office of the Privacy Commissioner of Canada, as soon as feasible, any breach of security safeguards involving the personal information of a person outside Quebec when it is reasonable to believe that it creates a real risk of significant harm, and notify the people affected directly (PIPEDA, s. 10.1). We record every breach, and keep that record for at least 24 months.
• 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. When the table of fractions remains unreadable, an authorized board member may send, after previewing it, the image of one page of that table, cropped in Quebec to the region of the table, in grayscale, reduced and without metadata; this image may show a name, initials or a signature, and the declaration file itself is never transmitted. Importing water heaters, or attaching a photo to a private portion's water heater, sends the photo of each rating plate, without its metadata or any name. 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 subscription payment (Stripe, Canada and United States), the cross-border transfer serves the performance of the subscription, which you expressly authorize. The mandates and condo-fee debit history set up with Stripe before condo-fee collection moved to Zūm Rails remain there on the syndicates' behalf; they include the banking details of the co-owners concerned (financial information) and the private portion’s technical identifier. This flow is framed by Stripe's data processing agreement (DPA); the account numbers of these mandates 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. Condo-fee collection by Zūm Rails, for its part, is processed in Québec (section 3).
• 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.
• For connected calendars (Google or Microsoft, companies based in the United States), CondoAide sends the provider the person chose themselves the authorization token, the identifiers of their calendars and the period to check, and receives back only the times they are busy; nothing about anyone else is sent. This flow happens only if the person connects their calendar, and stops as soon as they disconnect it.
• For an artificial intelligence assistant you connect to CondoAide yourself (MCP connector, section 1), the provider you chose receives what the assistant asks for and what our tools answer, often outside Canada; CondoAide does not choose that provider and sends it nothing else. For support reply drafts, CondoAide's team assistant (Anthropic, United States) receives the text of the report and its thread, as well as the opinion given of the answer and its comment, without the syndicate's name or the identity of the messages' authors.
• For the copy of the archives into a storage space the syndicate connects (Microsoft OneDrive, section 3), the communication is the syndicate’s: it chooses the account and entrusts Microsoft with keeping its copy, and CondoAide writes there on its instruction. Microsoft decides the hosting location, which may be outside Quebec, and CondoAide does not control it. The privacy impact assessment and the written agreement required by section 17 of the Act respecting the protection of personal information in the private sector are then the syndicate’s, which the connection screen says; the person who connects the account attests the board of directors’ decision and what they read, and that attestation is kept (section 1). The syndicate’s email and the recordings, which often concern people outside the syndicate, are copied only if the board expressly chose to.
• For importing the syndicate’s mail history from a Microsoft account (section 3), the emails are already at Microsoft, which the syndicate chose for its previous address; CondoAide brings them into the syndicate’s mailbox, hosted in Quebec. Only the authorization token, the identifiers of the folders and emails requested and the date from which to search are sent to Microsoft, where it hosts the account, possibly outside Quebec, for the duration of the import.
• If you allow mobile app notifications, each notice passes through Expo, in the United States, then through Apple's or Google's notification service, outside Québec. It contains only a generic text and three technical identifiers (category, syndicate, item concerned), never a name or message content. No other information displayed in the app leaves Québec through this flow.
• Information processed outside Canada is subject to the laws of the country where it is held: that country's courts, law enforcement and national security authorities may access it under those laws. Our contracts cannot override those laws; they limit what the provider may do with the information and require it to protect it.
• 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, and we do not knowingly collect personal information from children. A parent, or another occupant with the parent's agreement, may however record a child of their household among the household members described in section 1 (category, age bracket and, optionally, first name), solely to locate the people present during an emergency; for a child under 14, consent is given by the person having parental authority or by the tutor (section 14 of the Act respecting the protection of personal information in the private sector). If you believe a child has themselves 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:

14. If you are in Ontario

This section summarizes what applies to a person in Ontario.

• PIPEDA applies to the personal information we collect about you; you can complain to the Office of the Privacy Commissioner of Canada (priv.gc.ca).
• Ontario waitlist: section 1 (what we collect), section 2 (why), section 5 (how long).
• Ontario condominium corporations: when a corporation uses CondoAide, it decides what its records contain and who may see them, under Ontario's Condominium Act, 1998. We process the personal information in its records on its behalf, only to provide the Service to it, under the Ontario schedule to section 7 of our Terms of Service. To see or correct information in your corporation's records, ask its board first; we help it answer you. If a breach affects its records, we notify it without delay and help it notify you.
• Ontario proxies, owner obligations and evacuation needs are described in sections 1, 2 and 5.
• In this policy, for an Ontario corporation, "syndicate" means the condominium corporation and "co-owner" means the owner of a unit.

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.
• Version 1.66 - 12 October 2026 — Sections 1 and 5: when an administrator changes the plan of a subscription paid by pre-authorized debit, added the evidence of their authorization (account identifier, time, plan chosen, amounts and date of the authorized debits, waiver of the 10-day notice provided by Payments Canada Rule H1, financial institution name, last four digits of the account, and Stripe identifiers of the payment method and the mandate), kept 7 years after the mandate ends like the mandate itself. No new sub-processor, no new flow outside Québec and no automated decision.
• Version 1.69 - 13 October 2026 — Sections 1, 2, 3, 5 and 9: connected calendars added. A board member or a member of a management company’s staff may, if they wish, connect their own Google or Microsoft calendars from their profile, so that the other board members see “Busy” blocks on the board calendar, with no title or detail, at the times they are busy. We keep the connected account’s address and identifier, the calendar names and the person’s choices, and an encrypted authorization token, until they disconnect or their board or management role ends; busy times are kept only about 5 minutes. Google and Microsoft added as sub-processors for this feature, with a flow outside Québec, to the United States. No automated decision.
• Version 1.70 - 13 October 2026 — Sections 1, 2, 3 and 5: added the syndicate verification file for Zūm Rails. Before pre-authorized debits are activated, the person who manages the syndicate's payments gathers in CondoAide the documents Zūm Rails requires (void cheque or letter from the financial institution, bank statements for the last two months, proof of address, the Registraire des entreprises' état de renseignements), the list of directors and an attestation of the board's composition signed in CondoAide; CondoAide sends this file to Zūm Rails on the syndicate's behalf. The syndicate's statements may show co-owners' names and the amounts they paid. Financial documents are destroyed 90 days after Zūm Rails' decision, or 90 days after the last activity on the file without a decision; any replaced document is destroyed 30 days after it is replaced. CondoAide does not collect the directors' date of birth, home address, social insurance number or identity document. No new sub-processor: Zūm Rails and our document analysis service were already listed in section 3.
• Version 1.71 - 14 October 2026 — Sections 1, 2, 3, 5 and 6: recording of meetings held online added. The board of directors decides to record a meeting; each participant consents or not to their voice being recorded, and refusing does not affect their participation; only the voice of the people who consent is recorded, each on their own track, and transcribed in Quebec. A syndicate member who joins a meeting through the invitation link while signed in is tied to their participation so they can listen again; the board can tie a meeting to the vendor, private portion, work or request it was about, without changing who can listen or how long it is kept. Section 3: the sentence saying no meeting is kept is replaced; OVHcloud Object Storage (Beauharnois) is added for the files, and recording, transcription and the optional summary on our Beauharnois server; nothing from a meeting leaves Quebec. Section 5: retention periods for recordings, transcripts, summaries, consents and the listening log, and for the name of a guest at a meeting held in CondoAide. Section 6: the right to a copy of the recording of one's voice or its transcript, and to have one's track deleted.
• Version 1.72 - 14 October 2026 — Sections 1, 3, 4 and 5: added the debit mandate signed on paper, which the person who manages the syndicate's payments records in CondoAide when a co-owner signs their mandate on paper rather than online: the co-owner who signed it, the date of the mandate, the scanned copy of the mandate and of the void cheque or letter from the financial institution, the identity of the person who records it and the account's last four digits. The institution, transit and account numbers are sent to Zūm Rails, with the express consent the co-owner gives on the mandate, without being recorded in our systems; only the scanned copies carry them. They are kept in private storage in Québec, accessible only to the people who manage the syndicate's payments and to the co-owner concerned, for 7 years after the mandate ends, and destroyed within two days if recording the mandate does not complete. Our self-hosted document analysis service in Québec reads the numbers printed at the bottom of the void cheque to suggest them to the person recording the mandate, who compares them with the cheque and confirms them; the result of this reading is not kept. No new sub-processor: Zūm Rails and our document analysis service were already listed in section 3.
• Version 1.73 - 14 October 2026 — Sections 1, 2 and 5: added booking a meeting with a board member through a link they pass on. The outside person gives their name, their email and, if they wish, their phone number and the reason for the meeting; the board of directors reads them to prepare the meeting, and they are destroyed 12 months after it. The booking page shows only open times. No new sub-processor.
• Version 1.74 - 15 October 2026 — Sections 1 and 6: when a mandate signed on paper is recorded, the server reads the void cheque again and refuses an entered number that differs from a readable number, unless the person who manages payments confirms the numbers written on the signed mandate. The mandate log keeps the verification result and the compared fields, without the numbers read; you can ask for a review of a refusal.
• Version 1.75 - 15 October 2026 — Sections 1, 2 and 5: added the syndicate calendar, offered to every syndicate except demo ones. Each event has a level (“Whole building”, “Co-owners”, “Board” or “Only me”) that decides who reads it, may target certain units, and is destroyed 36 months after it ends. Added the subscription link, whose calendar app chosen by the person receives the events meant for them, including those that target their own unit; a board calendar access for an iPhone or iPad and its sync log, kept 30 days; the board date poll and invitations to planned meetings, kept with the meeting. The hours a board member offers for booking serve only to compute open times. Clarification to section 5: the invitation message of a booked meeting follows the retention of the email sending queue, and the trace of its sending from the syndicate’s address follows that of the sending log (7 years). No new sub-processor.
• Version 1.76 - 16 October 2026 — Sections 1, 2, 3, 4, 5 and 9: condo fee collection by pre-authorized debit goes live, and Zūm Rails is added to the list of service providers. The co-owner reads and accepts the debit mandate for their unit in CondoAide: CondoAide collects this consent on the syndicate's behalf and keeps the proof for 7 years after the mandate ends. The co-owner then links their bank account in Zūm Connect, Zūm Rails' interface, and CondoAide does not receive their account numbers. Our agreement with Zūm Rails provides that the information we send it is processed in Québec (AWS region ca-central-1, Montréal). Mandates and debit history set up with Stripe before this change remain stored there on the syndicates' behalf. The Zūm Rails passages announced in earlier versions apply from this date. Clarification made to this version before it went live: sections 1 and 3 also describe the items added to the verification file gathered for Zūm Rails, namely the name the syndicate files under with the Canada Revenue Agency, its number of employees and, if any, its phone number, the contact person and signatory chosen among the board's officers, the board's answer on politically exposed persons, the expected vendor-payment volumes, and the Zūm Rails service agreement signed in CondoAide.
• Version 1.77 - 16 October 2026 — Sections 1, 3 and 5: added the photo ID of the syndicate's signatory, uploaded in CondoAide by that person alone with their express consent and sent to Zūm Rails to verify their identity. CondoAide extracts no information from it and never copies it into its backups; it is destroyed 24 hours after it is sent, and 30 days after upload at the latest. No new sub-processor.
• Version 1.79 - 20 October 2026 — Sections 2 and 5: added the download, by the account owner, of the complete archive of the syndicate’s data, recorded in the register journal. No new sub-processor and no flow outside Québec.
• Version 1.80 - 21 October 2026 — Sections 1, 2, 3, 5 and 9: added the weekly copy of the syndicate’s archives into a OneDrive account its board of directors connects itself. Microsoft is not a CondoAide sub-processor: it is the provider the syndicate chooses for its own copy, possibly hosted outside Quebec, and the assessment required by section 17 is the syndicate’s. Email and recordings are copied there only on the board’s express choice; bank account numbers are masked there. The terms of service (sections 2 and 14) name this copy in the mandate the syndicate gives us.
• Version 1.81 - 22 October 2026 — Sections 1 and 3: with the RBQ register's answer about a contractor's or vendor's licence, we now keep what VériBât links to that licence in three public registries of Données Québec: a listing in the Registre des entreprises non admissibles aux contrats publics (RENA), a possible match in the registry of environmental administrative monetary penalties, and the history of public contracts published on the SEAO. Only the status, the dates and the totals are kept, never the name recorded in those registries nor the content of an entry. The board reads them before deciding. Still only the licence number is sent to VériBât; no new sub-processor, no transfer outside Québec and no new retention period.
• Version 1.82 - 24 October 2026 — Ontario waitlist (condoaide.ca/ontario): section 1, a new category (email address, role and range of the number of units in the corporation); section 2, a new purpose (writing to you about CondoAide in Ontario and planning its launch), separate from the newsletter and confirmed through a link sent to the address; section 3, Cloudflare's bot check and Brevo's lists cover this form; section 5, how long a confirmed signup is kept, and deletion after 30 days of an unconfirmed one. No new sub-processor, no new flow outside Quebec and no automated decision.
• Version 1.83 - 26 October 2026 — Sections 1, 3 and 5: the board of directors can import into the syndicate's mailbox the history of its previous address (for example a Gmail address), by uploading an export of that mailbox; these emails are kept 36 months from the date the previous mailbox received them, an older email is not imported, and the uploaded file is destroyed when the import ends. Section 3 adds the self-hosted antivirus at OVHcloud in Beauharnois (Quebec), which scans every imported attachment before it can be opened, without keeping it. Offered first to one pilot syndicate.
• Version 1.84 - 26 October 2026 — Sections 1, 2, 5 and 11: the occupant of a unit (a resident co-owner or one whose residence is not recorded, a tenant, or an occupant) can record their own household members in “My property” (category, age bracket and, optionally, first name); the board of directors can also link the people it records to the occupant they live with; this information is visible only to the occupant it is linked to and to the board of directors, and appear in the book the syndicate makes available to the fire department. Section 2 names this emergency purpose, the only one. Section 5 sets their retention: destroyed 30 days after the end of the occupancy they are linked to. Section 11 states that a child of the household may be recorded by their parent or with the parent's agreement. No new subprocessor, cross-border flow or automated decision.
• Version 1.85 - 27 October 2026 — Sections 1, 2, 4 and 5: description of video conferencing for assembly meetings, board meetings and meetings held in CondoAide, which until now was described only for a meeting's guests and, in section 3, for the server: what is transmitted (image, voice, shared screen and display name) and to whom, the microphone off on arrival and the choice to join without a camera, the purpose (holding a meeting remotely, art. 1088.1 of the Civil Code of Québec), our self-hosted server at OVHcloud in Beauharnois (Quebec), and that the stream is not kept, except the voice of the people who consent to a recording. No new processing, no new sub-processor and no transfer outside Quebec.
• Version 1.86 - 27 October 2026 — Sections 1, 2 and 5: addition of the CondoAide demonstration booked through a booking link of the CondoAide team, which replaces an outside booking service. CondoAide then collects, on its own behalf, the person's name, email and, optionally, phone number and reason, to arrange the demonstration and contact them afterwards about CondoAide, which they can stop at any time. A demonstration is recorded only with each participant's consent, serves only to answer them accurately, and its recording, transcript and summary are destroyed 30 days after the meeting.
• Version 1.87 - 27 October 2026 — Sections 1, 2, 3, 5 and 6: for a recorded assembly meeting or board meeting, when the syndicate’s plan includes it (Pro, Fondateur and Gestionnaire), we also record, for each person who consents, their camera image while it is on and the screen they share, on separate tracks under their name. The consent notice now names the voice, the image and the screen; a person who consented under the earlier notice is filmed only after accepting the new one. A shared screen is never recorded during a secret vote, no face analysis is done, and these tracks follow the retention periods, the access and deletion rights and the destruction of the audio recording. A meeting held in CondoAide still records only voices. No new sub-processor and no new flow outside Quebec.
• Version 1.88 - 28 October 2026 — Sections 2 and 5: the bank account statement an authorized person imports as a PDF, until now read and then discarded, is now also used to reconcile each of the syndicate's bank accounts with its statement, and a copy of it is filed in the syndicate's registry under the new Bank statements category, accessible to the board of directors only. It follows the syndicate's retention rule for supporting documents: six years after the end of the fiscal year it relates to. No new sub-processor, no new transfer outside Québec and no exclusively automated decision.
• Version 1.89 - 29 October 2026 — Sections 1, 2 and 5: addition of the optional sign-up the board of directors can open in CondoAide (for example its snow-removal contractor's alert list). The board names the list's recipient, its purpose, and an end date no later than two years after the form was created, even if it changes that date later; each current co-owner can sign up their private portion by giving a consent whose text names that recipient and that purpose, then change or withdraw their answer at any time. The board downloads the list and gives it to the recipient itself: CondoAide transmits nothing to it, and each download is logged. Answers are destroyed on withdrawal, on the form's deletion or the day after its end date, and the download log one year after the end date. No new sub-processor, no transfer outside Québec and no exclusively automated decision.
• Version 1.90 - 29 October 2026 — Section 3: the image and screen tracks of a recording are now re-encoded (decoded and compressed again, with a keyframe every two seconds) so that the replay can move to any moment without waiting; they are still never analyzed, and their cut before a secret vote or after a consent withdrawal is unchanged.
• Version 1.91 - 30 October 2026 — Section 5: a personal account is deleted as soon as the person deletes it, not 90 days after it is closed, which is how the Service actually works; the 90-day period applies to a closed syndicate account. Link to the new Account deletion page.
• Version 1.92 - 30 October 2026 — Sections 2, 3 and 5: the passages on the summary produced by artificial intelligence now name each case in which the syndicate may choose it: the assembly meeting and the board meeting, for which the board of directors and, if there is one, the syndicate’s manager receive a summary of each agenda item for the minutes, and the meeting held in CondoAide, whose summary only the board of directors and, if there is one, the syndicate’s manager receive, and is kept like the meeting’s transcript (30 days after the meeting, or up to three years after the closing of the work or request file the board files it with). These passages previously named only the assembly or board meeting; the processing itself is unchanged. No new subprocessor, no data leaving Québec and no exclusively automated decision.
• Version 1.93 - 30 October 2026 — Sections 2 and 3: the contact person email sent to Zūm Rails may be an address CondoAide manages for the syndicate. CondoAide's team then receives Zūm Rails' correspondence about the verification file, keeps it in its mail like any message received, and may pass it on, with its attachments, to the designated board member, through Amazon SES in Montréal. No new subprocessor and no transfer outside Québec.
• Version 1.95 - 4 November 2026 — Sections 1, 3, 5 and 9: added importing the syndicate’s mail history from a Microsoft account (Outlook.com, Hotmail or Microsoft 365). A board member connects the account of the syndicate’s previous address and chooses the folders; CondoAide reads, read-only, the emails of the last 36 months in those folders and adds them to the syndicate’s mailbox, with the same access and the same retention period as emails imported from an export. Microsoft is not a sub-processor: it is the provider the syndicate chose for its previous address. The authorization token is destroyed as soon as the import ends or at one of the deadlines described in section 5. The email address and type of the connected account, and the names of the imported folders, are kept for 36 months after the import ends.
• Version 1.96 - 2 November 2026 — Sections 1 and 5: added mail tags. The board can organise the conversations in the syndicate's mailbox with its own tags, and the old mailbox's folders or labels become tags during an import, unless declined. A tag can name a person. The link to a conversation disappears with its last email; the tag stays until the board deletes it. No new sub-processor.
• Version 1.97 - 5 November 2026 — Sections 1 and 5: added the space leases the board of directors records (renting private portion, lessor, dates, rent agreed for information only and optional note), read by the board and, until they end, by the current co-owners of the private portions concerned, never by a tenant. A lease changes neither the allocation of the space nor the sharing of charges; only a lease granted by the syndicate gives rise to space fees. No new sub-processor.
• Version 1.98 - 5 November 2026 — Sections 1, 2 and 5: added syndicate email delivery preferences. For each syndicate, a member chooses the optional reminders they receive by email and can turn one off from the reminder itself; the board of directors does not see these choices. They can agree to receive the syndicate's notices by email (date and address kept) or ask for official notices by mail, a choice seen by the board members who manage the syndicate's settings. Kept for as long as the membership lasts. No new sub-processor.
• Version 1.99 - 5 November 2026 — Sections 1, 2 and 5: recharging the rent of a space rented from a third party. When the syndicate itself rents a space, for example from the initial syndicate, the board of directors may recharge that rent each month to the private portion that uses it; the agreed rent is therefore no longer always recorded for information only. Recharged months are read by the board and by the current co-owners of that portion, never by a tenant, and are kept with the syndicate's books. No new sub-processor.
• Version 1.100 - 5 November 2026 — Sections 1 and 5: the household members of a co-owner, whether the co-owner records them or the board of directors links them to the co-owner, now belong to the unit. All its current co-owners see them, those not recorded as living elsewhere can change them, remove them and add to them, and the board of directors still sees them. When a co-owner leaves, they are linked to another current co-owner, and they are destroyed 30 days after the last one leaves. Members recorded before this version stay visible only to the person who recorded them and to the board, until that person shares them; those the board had linked to a co-owner, only to that co-owner and to the board, until the board shares them. This sharing cannot be undone. The household members of a tenant or an occupant stay visible only to them and to the board. No new category of information and no new processor.
• Version 1.101 - 6 November 2026 — Sections 1, 2, 3, 5 and 9: added the CondoAide mobile app for iPhone and Android (what it keeps on the phone, the Face ID or fingerprint lock with no biometric data, errors sent to GlitchTip) and its notifications (payment to approve, board message, new request, reply or mention in a request, new email in the syndicate mailbox), the phone's information and its retention periods, and Expo, with Apple and Google, as new subprocessors in the United States. The notice contains only a generic text and three technical identifiers; each category can be turned off in the app.
• Version 1.102 - 7 November 2026 — Sections 1, 3, 5 and 9: addition of the reading of the image of the table of fractions of the declaration of co-ownership. When our rules cannot read that table, an authorized board member may send Anthropic, in the United States, the image of one page of the table, after previewing it. Our analysis service, in Quebec, crops the page to the region of the table, in grayscale, reduced and without metadata; one page per request, at most four per read; the request is cancelled if our reading of the image finds a person's name in it. The image may nevertheless show a name, initials or a signature. It is kept neither by CondoAide nor by our analysis service, and the declaration file itself is never transmitted. No new sub-processor.
• Version 1.103 - 7 November 2026 — Sections 1 and 5: added the proof of acceptance of the Terms of Service and of this Policy (date, version, context and, where applicable, the syndicate created), collected when a syndicate is created or before the first access to the Service, with no IP address or browser data, and its retention period. The confidentiality commitments for the syndicate’s data are now in section 7 of the Terms of Service. No new subprocessor.
• Version 1.104 - 7 November 2026 — Sections 1, 2 and 5: added assisted setup, that is, the files the board entrusts to our team to set up the syndicate, the proof of its authorization and withdrawal, the log of staff downloads, the purpose of this processing and the retention of the files (60 days after the setup ends). No new subprocessor; the files stay in Québec.
• Version 1.105 - 9 November 2026 — Section 1: corrected the description of backups. Supabase keeps daily snapshots of the database, without point-in-time recovery; the encrypted copy of the database every 4 hours, kept in Quebec, is unchanged. No new subprocessor and no new data.
• Version 1.106 - 10 November 2026 — Section 3: the description of the hosting of our video-conferencing server (OVHcloud) now names the chat messages of a meeting held online in CondoAide. These messages are relayed in real time between the people present and are not kept: neither CondoAide nor the server keeps a copy, and they disappear when the person leaves the meeting. No new subprocessor and no new retention period.
• Version 1.107 - 10 November 2026 — Section 5: the two permanent retention lines for proxies filed in the syndicate's registry and for their registration log now state that they apply to Quebec; their period is unchanged. A new line describes the retention of proxy forms and ballots for the meetings of an Ontario condominium corporation: at least 90 days after the meeting was actually held or closed, extended by a records request or litigation under O. Reg. 48/01, then until the board confirms deletion, never automatically. These forms are collected only once CondoAide opens to Ontario condominium corporations. No new subprocessor and no new data for Quebec syndicates.
• Version 1.108 - 10 November 2026 — Sections 1, 3 and 5: a meeting held in CondoAide may now, when the syndicate’s plan includes it (Pro, Fondateur and Gestionnaire), also record, for each person who consents, their camera image while it is on and the screen they share, on separate tracks under their name, like an assembly meeting or a board meeting. The meeting’s consent notice then names the voice, the image and the screen; keeping the camera off is enough not to be filmed, and a person who consented under the notice that named only the voice is not filmed. No face analysis is done, and these tracks follow the period of the meeting’s audio recording: destroyed 30 days after the meeting, even when the transcript and the summary are filed. A CondoAide demo still records only voices. No new sub-processor and no new flow outside Quebec.
• Version 1.109 - 10 November 2026 — Section 1 ("Board meeting scheduling"): when a person invited to a scheduled board meeting replies to the invitation by email, CondoAide reads their answer (accepted, maybe or declined) and its date from the email they send to the syndicate, and keeps them with the invitation. Section 5: the line for an external person's invitation now names this answer and its date, destroyed with the invitation 36 months after the meeting ends; the period is unchanged. No new purpose, reader, subprocessor or retention period.
• Version 1.110 - 10 November 2026 — Introduction: the policy states that where both Quebec law and PIPEDA apply, we follow both. Sections 1 and 2: proxies and ballots, owner obligations (including section 83 notices and photos taken inside a unit, as proof only and seen by the board alone) and, with express consent, the evacuation needs of occupants of an Ontario condominium corporation; this information is collected only once CondoAide opens to Ontario condominium corporations. Section 3: the company we contract with for Brevo, SIB Inc., in the United States. Section 5: the retention of evacuation needs, of the record of consent and of section 83 notices (permanently), and what happens when you unsubscribe from the Ontario waitlist while its destruction is not yet in place. Section 6: the 30-day response time. Section 7: the accountable person also answers for PIPEDA. Section 8: reporting to the Office of the Privacy Commissioner of Canada. Section 9: possible access by the authorities of a country where information is processed. New section 14: what applies to a person in Ontario. No new subprocessor and no new data for Quebec syndicates.