Privacy Policy
Effective Date: 2026-08-31 Last Updated: 2026-08-31
BidSafe, operated by Xavier Bourgeois ("BidSafe", "we", "us", "our") operates the BidSafe RFP and tender analysis service (the "Service"). We are based in New Brunswick, Canada.
This Privacy Policy explains what personal information we collect, why we collect it, how we use, disclose, transfer, secure and retain it, how long we keep it, and how you can access, correct or delete it. It is written to meet the openness and individual-access requirements of Canada's Personal Information Protection and Electronic Documents Act ("PIPEDA"), which requires organizations to disclose the purposes of collection and transfer, their retention practices, and the security measures they apply.
Accountability. Xavier Bourgeois, Operator is the individual accountable for our compliance with this Policy and may be reached at contact@bidsafe.net.
A note on scope. BidSafe is a business service. Most information we handle is business-contact and business-account information. However, documents you upload may incidentally contain personal information about identifiable individuals (for example, a named procurement officer or a contact person in a tender document), so this Policy covers that too.
1. Summary — the four things people most want to know
| Question | Answer |
|---|---|
| Do you keep my uploaded RFP file? | No. The document you upload is processed and then discarded — it is not added to any repository or database. (During processing a large file may sit briefly in a temporary system file, which is released as soon as your analysis finishes.) What we keep is the analysis result derived from it, plus short text excerpts. See Section 3. |
| Does my document text get sent to an AI company? | No — not in our current production configuration. The analysis itself is produced by a deterministic rules engine that uses no AI. The Service also has optional language-model features that would send derived text to OpenAI (United States), and all of them are switched off in production today, so no part of your document — neither its extracted text nor any summary derived from it — is sent to OpenAI. If we switch any of them on, we will update Section 4 before the change takes effect. See Section 4. |
| Do you use my documents to train AI models? | No. We do not use your documents or their contents to train, fine-tune or improve any model, ours or a third party's. We have not opted in to any data-sharing-for-training programme, and our language-model provider does not use data submitted through its API to train its models by default. See Section 4.4. |
| How long do you keep it? | See Section 10. Analysis records and their stored excerpts are kept for up to 24 months, or less if you delete them sooner. In our application database that window is enforced by an automated daily purge; in the analysis engine's own store it is enforced by a purge we run rather than a scheduled one. Section 3.5 states exactly which is which. You can request deletion at any time. |
2. Personal Information We Collect
2.1 Account and identity information
Collected when you register and when you sign in. Authentication is handled by our identity provider (Clerk).
- Name and business email address
- A user identifier assigned by our identity provider
- Organization or company name, and job title if you provide it
- Password credentials or third-party sign-in identifiers — passwords are held by our identity provider; we never see or store your password
- Authentication events (sign-in times, method)
2.2 Billing and subscription information
- Subscription plan, plan status, quota and entitlement records
- A customer identifier assigned by our payment processor (Stripe)
- Billing email and billing contact details
- Invoice and transaction history, amounts, currency, and payment status
- We do not collect, receive or store your full payment card number, expiry date or card security code. Those are collected directly by Stripe. We may receive limited non-sensitive descriptors from Stripe such as the card brand and last four digits.
2.3 Documents you upload, and what is derived from them
When you upload a solicitation document, we process:
- The file name you gave the document
- The text content extracted from the document, including via OCR fallback for scanned documents
- Derived analysis data: a cryptographic hash of the document; page count; counts of mandatory requirements, disqualifiers and evaluation criteria; internal risk values; the internal engine code (
BID,PROCEED_WITH_CAUTION,DO_NOT_BID), which is engine state rather than a recommendation to you; the engine version; parse status and any parse error - Extracted clause excerpts: short text snippets from the document with their classification, the keyword that triggered the classification, the page number and the section heading
- Extracted document metadata: issuing authority name, location, industry, language, and estimated contract value where these appear in the document
- Any personal information incidentally contained in those excerpts or metadata — for example, the name, title, email or phone number of a procurement contact named in a tender
2.4 Usage and technical information
- Analyses run, timestamps, feature usage, and quota consumption
- Application and server logs, including request events, error events and performance data
- IP address, for abuse prevention and rate-limiting. Our application stores only a salted SHA-256 hash of your IP address — it does not write the raw address to our own database. That is a statement about our application, and we are careful not to overstate it: our hosting and infrastructure providers operate standard request logging, and those logs ordinarily contain IP addresses. Those provider logs are governed by the providers' own retention practices and are not something we can switch off. We therefore do not claim that your IP address is never recorded anywhere in the stack — only that we do not store it ourselves.
- Browser type, device type and general technical characteristics
- Cookies and similar technologies (Section 12)
2.5 Support and correspondence
- Emails, support tickets and their contents, including any document or screenshot you choose to attach
- Feedback, survey responses and bug reports
2.6 What we do not collect
We do not knowingly collect, and you must not upload: health information, government-issued identification numbers, biometric data, financial account credentials, or personal information about individuals that is not necessary for analyzing a solicitation document. We do not collect sensitive personal information as a matter of course, and we do not build advertising or behavioural profiles.
3. How Uploaded Documents Are Handled — Storage, Retention and Deletion
This section is the one most customers care about, so it is stated plainly.
3.1 The uploaded file itself is not retained. When you upload a document, our analysis engine reads it, computes a hash, and extracts its text. The original document file is not added to any repository, is not stored in a database, and is not kept after your analysis completes. While a request is being processed, a large file may be held briefly in a temporary system file — this is the ordinary mechanism by which web uploads are handled — and that temporary file is closed and released as soon as processing finishes. We are not a document repository, and you should keep your own copy of every document you upload. Important: although we do not keep the original file, we do store short excerpts of the text extracted from it as part of the analysis record. Those excerpts are described in 3.2–3.3 and are subject to the retention schedule in Section 10.
3.2 What is stored. Two records persist after an analysis:
| Store | What it contains | Where |
|---|---|---|
| Application database | Your account record (identity provider id, email, payment-processor customer id, plan); the analysis record, which contains the full structured analysis result including the human-readable summary derived from your document, plus the document file name, the internal engine code and internal risk values; hashed-IP rate-limit records | Neon (managed PostgreSQL) |
| Analysis engine store | Document hash, page/requirement/disqualifier counts, risk score, engine version, parse status; extracted clause text excerpts with their classification and section heading; extracted authority, location, industry, language and estimated value; quality flags | The engine's own database on our hosting provider |
3.3 Excerpts contain document text. The clause excerpts we store are verbatim short passages from your document. Where a passage names an individual, that individual's personal information is stored with it. Where a solicitation document is confidential or restricted, do not upload it — see Section 5.3 of the Terms of Service.
3.4 Deletion. You may request deletion of any analysis, or of your entire account and all associated records, at any time by emailing contact@bidsafe.net. We will action deletion requests within 30 days and confirm in writing when complete. Deletion removes the analysis record, the derived data and the stored excerpts. See Section 10 for the retention schedule and for the limited categories we must retain.
3.5 How the retention schedule is enforced — and the one place it is not yet automatic. Your data lives in two stores, and we enforce the Section 10 retention windows differently in each. We set both out plainly rather than describing one control and letting you assume it covers both:
| Store | What the purge removes | How it runs |
|---|---|---|
| Application database | Analysis records, including the derived summary, the document file name and the derived values; expiring hashed-IP rate-limit rows | Automatic. A scheduled job runs daily and deletes everything past the window. |
| Analysis-engine store | The stored clause excerpts, engine metadata, extracted document metadata and quality flags | Manual, for now. The purge exists and is tested, and it applies the same 24-month window — but it is a job we run, not one that runs on a timer. We are wiring it to a schedule. |
Where the purge does run, deletion of a parent analysis cascades to everything derived from it, so no stored excerpt outlives the analysis it belongs to. Until the engine-side purge is scheduled, you should assume that excerpts in that store are removed when we run the job or when you ask us to delete them — not on the day the window expires. You do not need to wait for either purge: you may exercise your deletion right at any time under 3.4, and we action such requests within the window stated there.
4. Artificial Intelligence and Language Models — What Leaves Our Systems
4.1 The analysis is not AI-generated. The extraction, the mandatory-requirement and disqualifier classification, and the internal engine code (BID / PROCEED_WITH_CAUTION / DO_NOT_BID) and internal risk values are produced by a deterministic, rules-based engine running on our own infrastructure. No language model determines, influences, alters or overrides any of them.
4.2 Optional language-model processing. The Service includes optional features that call OpenAI's API (OpenAI, United States). These features are controlled by configuration settings, and when they are switched off no document-derived content is sent to OpenAI at all. The features are:
We deliberately do not name the specific model here. Model versions are retired and replaced on the provider's schedule, and a policy that names one becomes false the day we upgrade — which is worse than saying less. What we commit to instead, and what actually determines your exposure, is the four things stated in this Section: who receives the data (OpenAI, in the United States), what data is sent (the table below), what it is used for (producing your own output, nothing else), and how long they keep it (Section 4.4). If we change providers, we will name the new one here before the change takes effect.
| Feature | What is sent to OpenAI | Default state |
|---|---|---|
| Summary readability rewrite | The derived structured summary (overview, obligations, special conditions) produced by our own engine, together with the internal engine code and internal risk values, so the wording can be made more readable. The engine's values are never changed by this step. | Enabled when language-model helpers are enabled |
| OCR text cleanup | The raw extracted text of your document, so that OCR artifacts can be cleaned before analysis. This is the broadest exposure of your document content. | Disabled by default |
| Requirement adjudication assist | Extracted requirement and date candidates for classification assistance | Disabled by default |
4.3 Current production configuration. In our production deployment today:
- Summary readability rewrite — DISABLED. The derived structured summary produced by our own engine is not sent to OpenAI. The summary you see is the one our own engine computed.
- OCR text cleanup — DISABLED. The extracted text of your document is not sent to OpenAI.
- Requirement adjudication assist — DISABLED. No extracted requirement or date candidates are sent to OpenAI.
In plain terms: all three features are off, so no document-derived content leaves our systems for OpenAI at all — neither the extracted text of your document nor any summary derived from it. If we change this configuration, we will update this section before the change takes effect.
4.4 Limits on that processing, and how long OpenAI keeps it. Where language-model processing occurs, it is used solely to produce your own analysis output.
Training. We do not use your documents, their contents, or anything derived from them to train, fine-tune, evaluate or improve any machine-learning model, whether ours or a third party's, and we do not permit our processors to do so. OpenAI offers a setting by which a customer may opt in to share API data for model training; we have not opted in. OpenAI's own documentation states that data sent to the OpenAI API "is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)."
Retention at OpenAI. Not-used-for-training is not the same as not-retained, and the difference matters, so we state it: OpenAI generates abuse-monitoring logs for API usage and documents that these are "retained for up to 30 days, unless longer retention is required by law," after which they are deleted. Because the Section 4.3 features are all switched off today, we send OpenAI nothing and there is nothing of yours in those logs. Were we to switch a feature on, content we then sent could persist in OpenAI's abuse-monitoring logs for up to 30 days, independently of our own retention schedule in Section 10.
Zero Data Retention. OpenAI makes a Zero Data Retention control available to customers who apply for and are approved for it, which excludes their content from those abuse-monitoring logs. This Policy does not claim we have it. If we obtain it, we will state so in this Section.
Sources for the two quotations above: OpenAI, "Your data" (developers.openai.com/api/docs/guides/your-data), checked 24 August 2026. Provider terms change; we re-check this Section when we review the Policy.
4.5 Cross-border effect. OpenAI processes data in the United States. Where any of the features in Section 4.2 is enabled, document-derived content leaves Canada. See Section 7.
4.6 Your control — stated as it actually is. The features in 4.2 are controlled by a single service-wide configuration, not a per-customer setting. We therefore cannot today switch language-model processing off for one account while leaving it on for others, and we are not going to imply otherwise. If you require that no document-derived content leaves our infrastructure, the honest options are: do not upload the document, or contact us at contact@bidsafe.net to discuss whether a dedicated configuration is workable for your organization. If we later build a per-account control, we will describe it here.
4.7 A note on data-residency claims. If we advertise Canadian data residency for any plan, that claim will accurately reflect the configuration applied to that plan. Where a plan is configured so that no content is sent outside Canada, we will say so; where it is not, we will not claim it.
5. Why We Collect It — Purposes and Consent
5.1 Purposes. We collect, use and disclose personal information only for the following purposes:
| Purpose | Information used |
|---|---|
| Creating and administering your account, authenticating you, and providing access | Sections 2.1, 2.4 |
| Performing the analysis you request and returning your report | Sections 2.3, 2.4 |
| Processing payments, managing subscriptions, invoicing, tax and accounting | Section 2.2 |
| Enforcing usage quotas and preventing abuse, fraud and unauthorized access | Sections 2.2, 2.4 |
| Providing customer support and responding to your enquiries | Sections 2.1, 2.5 |
| Maintaining, securing, debugging, monitoring and improving the Service, including measuring extraction and classification accuracy in aggregate | Sections 2.3, 2.4 |
| Sending service and transactional communications (security notices, billing notices, material changes to terms) | Section 2.1 |
| Sending marketing communications, where you have consented | Section 2.1 |
| Complying with legal, regulatory, tax and audit obligations, and establishing or defending legal claims | As required |
5.2 We will not use your information for a new purpose that is materially different from those listed above without first identifying that purpose to you and obtaining your consent, unless the use is permitted or required by law.
5.3 Consent. We rely on your consent to collect, use and disclose personal information for the purposes above.
- Express consent is obtained when you create an account and accept these documents, when you submit a document for analysis, and when you opt in to marketing.
- Implied consent applies to uses that are obvious from the circumstances and to which you would reasonably expect to consent — for example, using your email address to send you your analysis result or a receipt.
- We do not rely on consent where a use or disclosure is permitted or required by law without it, such as responding to a lawful court order or preventing fraud.
5.4 Withdrawing consent. You may withdraw your consent at any time, subject to legal and contractual restrictions and reasonable notice, by emailing contact@bidsafe.net. Withdrawing consent to the core processing described in Section 5.1 will mean we can no longer provide the Service to you, and your subscription will be terminated. Withdrawing consent to marketing has no effect on your subscription. Withdrawal is not retroactive and does not affect processing already carried out.
5.5 No sale of personal information. We do not sell, rent, trade or licence personal information, and we do not disclose it to third parties for their own marketing purposes.
5.6 Marketing. We send commercial electronic messages only in accordance with Canada's anti-spam legislation. Every marketing email includes an unsubscribe mechanism and our identifying and contact information. Unsubscribing does not stop transactional and service messages, which are necessary to operate your account.
6. Service Providers and Sub-Processors
We use the third-party service providers below. Each processes personal information only on our instructions and only to provide services to us, under contractual confidentiality and security obligations. PIPEDA requires that we disclose these transfers and their purposes.
| Sub-processor | Role | What it receives | Receives your document content? | Processing location |
|---|---|---|---|---|
| Clerk | Identity and authentication | Name, email, user id, authentication events, credentials | No | United States. Clerk hosts on US infrastructure and does not offer a region selection |
| Stripe (incl. Stripe Payments Canada, Ltd.) | Payment processing, subscription billing, invoicing | Billing name and email, customer id, payment card data (collected directly by Stripe), transaction records | No | Canada and United States. Stripe Payments Canada, Ltd. is a Stripe affiliate that processes personal data in Canada; affiliate and sub-processor details are published by Stripe |
| Neon | Managed PostgreSQL database for account, subscription and analysis records | Account data, subscription data, analysis results including document-derived summary text and file names, hashed-IP records | Yes — derived content | United States — AWS us-east-1 (Northern Virginia) |
| Vercel | Web application hosting, edge delivery, serverless functions, function logs | Requests, application logs, technical data; uploaded files transit through it | Transits; logs may contain file names and analysis identifiers | Global edge network, with server-side processing in the United States. Static content is served from the edge location nearest you (a request from Eastern Canada is served from Vercel's Montreal edge); the code that handles your upload runs in our configured function region — see the note below |
| Railway | Hosting for the analysis engine | Uploaded file content in transit and in memory; the engine's stored derived data and clause excerpts; service logs | Yes — document text in processing, excerpts at rest | United States — see the note below |
| OpenAI | Optional language-model features (see Section 4) | Nothing today — all Section 4 features are switched off. If enabled: derived summary text; extracted document text if OCR cleanup is enabled; requirement candidates if adjudication is enabled | None today; yes when enabled | United States |
| Formspree | Waitlist and contact-form submissions on the marketing site (before you have an account) | The email address and any message you enter into the form | No | United States |
A note on how we state regions. Some providers publish a single processing location; others make it a deployment setting. Where the location is published or determinable, we name it above. Where it is a setting, we state the country conservatively — that is, we tell you the broadest place your data may be processed rather than the narrowest we could argue for. Being served from a Canadian edge location does not mean your data is processed in Canada, and we do not present it that way. We do not claim Canadian data residency for any plan (see 4.7 and 7.5).
Keeping this table true. We will update this table when we add, remove or change a sub-processor. A sub-processor list that omits a processor which actually receives customer content is the most damaging error a privacy policy can contain, so this table is re-verified against the production environment at each review.
Other disclosures. We may also disclose personal information: to our professional advisors (lawyers, accountants, auditors) under confidentiality; to a purchaser or successor in connection with a merger, acquisition, financing or sale of assets, subject to this Policy continuing to apply; where required by law, court order, subpoena or lawful government request; and where necessary to establish, exercise or defend legal claims, or to protect the rights, safety or property of any person. Where we are legally compelled to disclose your information, we will notify you unless we are prohibited from doing so.
7. Data Location and Cross-Border Transfers
7.1 Your information is processed outside Canada. Our hosting, identity, payment and language-model providers operate in whole or in part in the United States and potentially other jurisdictions. This means personal information — including, where the features in Section 4.2 are enabled, content derived from your uploaded documents — is transferred to, stored in and processed in countries other than Canada.
7.2 Legal effect of that transfer. While personal information is in another country, it is subject to the laws of that country, and may be accessible to that country's courts, law enforcement, national-security authorities and regulatory bodies under that country's laws. We disclose this so you can make an informed decision about using the Service.
7.3 Our obligation does not transfer. We remain accountable for personal information we transfer to a service provider for processing. We use contractual and other means to require each provider to give it a comparable level of protection to that required in Canada.
7.4 Documents containing third-party confidential information. Government solicitation documents may contain information belonging to procurement authorities and third parties. You are responsible for confirming that uploading a given document — and its consequent processing outside Canada — is permitted by your own obligations to the issuing authority and to any third party. If you are subject to a data-residency requirement, contact us at contact@bidsafe.net before uploading.
7.5 We do not offer Canadian data residency, and we do not advertise it. Canadian-region infrastructure exists and we are aware of it. We have not built on it, so no plan we sell today keeps your data in Canada, and nothing on our site or in this Policy should be read as promising that it does. If that changes, the claim will appear here only after the architecture behind it is real.
8. How We Protect It — Safeguards
PIPEDA requires us to protect personal information with safeguards appropriate to its sensitivity, and to be open about what those safeguards are. Every control listed below was verified against our actual configuration or our provider's published documentation before it was written here. We have deliberately kept this list short. A long list of security-sounding claims is easy to write and impossible for you to check; a short list of things that are actually true is worth more.
8.1 Encryption in transit.
- Our site is served over HTTPS only. A plain
http://request is redirected tohttps://before any content is returned. - We send a
Strict-Transport-Securityheader with a two-year lifetime, which instructs your browser to refuse to connect to us over an unencrypted connection at all, even if a link tries to. - Connections between our application and our database are encrypted. Our database provider requires that all connections use SSL/TLS, so an unencrypted connection is refused by the database itself rather than silently downgraded — this does not depend on us configuring it correctly. Our connection string additionally requests channel binding.
8.2 Encryption at rest. Our database provider encrypts stored data with AES-256, and encrypts its backups in storage. This is the provider's documented behaviour, not a configuration we set.
8.3 Authentication. Sign-in, session management and credential storage are handled by a specialist identity provider (Clerk). We never see, receive or store your password. Administrative areas of the application require an authenticated session; signing out or having no session leaves you with no access to another customer's data.
8.4 Secrets management. Credentials for our database, payment processor, identity provider and analysis engine are held as environment variables in our hosting provider's encrypted configuration store. They are not committed to our source code, and our repository is configured to exclude environment files from version control.
8.5 Abuse and rate limiting. Unauthenticated use is rate-limited per client, keyed on a salted hash of the IP address rather than the address itself (Section 2.4). Our scheduled deletion job is protected by a shared secret and cannot be triggered by a member of the public.
8.6 Access control. Administrative access to production systems, the databases and the provider dashboards is limited to the personnel who require it for their role.
8.7 Backups. Backups are managed by our providers and are encrypted in storage. See Section 10.1 for how long deleted data can persist in them.
8.8 What we do not claim. This is the part most policies leave out, and it is the part that tells you how far to trust the rest:
- We do not hold a SOC 2 report, an ISO 27001 certification, or any equivalent third-party security certification.
- We have not undergone an independent penetration test, and we do not operate a bug-bounty programme.
- We have not had our Content-Security-Policy reviewed by a third party, and it still permits inline scripts (
'unsafe-inline'inscript-src), which limits how much cross-site-scripting protection it provides. We set one, and we set clickjacking protection (frame-ancestors 'none',X-Frame-Options: DENY), on our HTML responses — but we would rather describe the limit than let the presence of a header imply more than it delivers. - We do not offer Canadian data residency, single-sign-on, or a customer-specific encryption key.
BidSafe is an early-stage service operated by a small team. If your organization's procurement or security review requires any of the above, tell us before you buy rather than after, so we can tell you honestly whether we can meet it. When any item in 8.8 becomes true, it moves up into the list above it and this Section says so.
8.9 The limit of any safeguard. No method of transmission or storage is completely secure, and we cannot guarantee absolute security. What we can tell you is what we actually do, which is what this Section is for. Do not upload a document whose disclosure you could not tolerate — see 3.3 and Section 5.3 of the Terms of Service.
9. If Something Goes Wrong — Breach Response
9.1 Our legal duties. PIPEDA imposes specific obligations on us if there is a breach of the security safeguards protecting personal information under our control. We set them out here so you know what we owe you, and can hold us to it.
- Reporting to the regulator. Where it is reasonable in the circumstances to believe that a breach creates a real risk of significant harm to an individual, we must report it to the Privacy Commissioner of Canada as soon as feasible after determining that the breach occurred.
- Notifying you. In the same circumstances we must notify each affected individual as soon as feasible, with enough information for you to understand the significance of the breach and to take any steps that might reduce or mitigate the harm.
- Notifying others. We must also notify any other organization or government institution that we believe can reduce or mitigate the risk of harm — for example a payment processor or law enforcement.
- Keeping records. We must keep a record of every breach of security safeguards involving personal information under our control — including breaches we assess as not creating a real risk of significant harm — for at least 24 months after the day we determine the breach occurred, and provide those records to the Commissioner on request.
(PIPEDA ss. 10.1–10.3 and the Breach of Security Safeguards Regulations, SOR/2018-64.)
9.2 "Significant harm" is broad. It includes bodily harm, humiliation, damage to reputation or relationships, loss of employment or business or professional opportunities, financial loss, identity theft, negative effects on a credit record, and damage to or loss of property. Assessing the risk means weighing both the sensitivity of the information and the probability that it will be misused.
9.3 What that means for the information you give us. The material sensitivity here is concentrated in two places: the derived summary and clause excerpts taken from your documents, which may quote a named individual (2.3, 3.3), and your account identity and billing descriptors. We do not hold payment card numbers, passwords, government identifiers or health information, which limits — but does not eliminate — the harm a breach of our systems could do.
9.4 We keep the register regardless. We maintain the breach register described above for all incidents, not only reportable ones. Keeping a record only of the breaches you have already decided are serious defeats the purpose of the record, which is partly to let a regulator test that judgment. Our internal procedure for containing, assessing, reporting and recording an incident is documented and maintained separately from this Policy.
9.5 Quebec and Law 25 — our posture, stated plainly. Quebec's Law 25 imposes its own privacy and confidentiality-incident obligations, and it can reach organizations outside Quebec that handle the personal information of people in Quebec. Our current position is that we operate under PIPEDA, and whether and to what extent Law 25 applies to us is a question we have flagged for legal review rather than one we have concluded. We are not going to claim compliance with a regime we have not been advised on. In the meantime we keep the incident register described in 9.4 for every incident regardless of which statute turns out to govern it, because that obligation exists under both and is the one that is impossible to satisfy retroactively. If legal review concludes that Law 25 applies to us, we will say so here and describe what changes.
9.6 Telling us. If you believe you have found a security vulnerability in the Service, or that a breach has occurred, please contact contact@bidsafe.net. We would rather hear it from you early than read about it later.
10. Retention
10.1 Retention schedule. We retain personal information only as long as necessary for the purposes in Section 5 or as required by law.
| Category | Retention |
|---|---|
| Uploaded document file (the PDF itself) | Not retained — processed in memory and discarded |
| Analysis results, derived summaries, clause excerpts, document metadata | 24 months from creation, or until you delete the analysis or your account, whichever is first |
| Account and profile information | For the life of your account, then 90 days after account closure |
| Billing, invoice and transaction records | 7 years from the end of the tax year to which they relate. The legal floor is six years from the end of the last tax year the records relate to, which is the period the Canada Revenue Agency requires businesses to keep books and records; the seventh year is our own margin, not a legal requirement, and we state it that way rather than dressing a choice up as an obligation. — this category is retained even after account deletion and is not deletable on request |
| Support correspondence | 24 months from last contact |
| Security, audit and application logs | 12 months |
| Hashed-IP rate-limiting records | 30 days |
| Marketing consent and unsubscribe records | Retained as long as necessary to honour your unsubscribe request |
| Backups | Deleted data may persist in our providers' encrypted backups for a limited period before being overwritten in the ordinary backup cycle. Our database provider documents 30-day retention for its encrypted backup storage. This window is set by the provider and by our plan with them, not by us, so we describe it as an upper bound we have verified rather than a guarantee we control |
10.2 Deletion requests override the schedule for every category except those we are legally required to retain (principally billing and tax records) and except for the backup window in Section 10.1.
10.3 De-identified data. Aggregated and de-identified statistics that cannot be linked back to you or to any identifiable individual may be retained and used indefinitely to operate, secure and improve the Service.
11. Your Privacy Rights
Canada's Personal Information Protection and Electronic Documents Act (PIPEDA) gives you the following rights over the personal information we hold about you. We do not charge a fee to exercise any of them.
11.1 Access. You may ask us for confirmation that we hold personal information about you, a copy of that information, and an account of how it has been used and to whom it has been disclosed. We will respond with due diligence and in any case no later than 30 days after we receive your request.
PIPEDA allows that period to be extended, and we would rather you knew the rule than discovered it: we may extend by up to a further 30 days where meeting the original deadline would unreasonably interfere with our activities, or where the consultations necessary to answer you make it impracticable — and by such further period as is necessary where the information must be converted into an alternative format. If we extend, we will tell you within the original 30 days, give you the reason, and tell you that you may complain to the Privacy Commissioner of Canada about the extension itself. If we fail to respond within the applicable limit, the law treats that as a refusal of your request, and you may complain on that basis. (PIPEDA ss. 8(3)–(5).)
11.2 Correction. If any personal information we hold is inaccurate or incomplete, you may ask us to correct it. Where we agree, we will amend it and, where practical, notify anyone to whom we disclosed the earlier version. Where we disagree, we will record your requested correction alongside the information and note the disagreement.
11.3 Withdrawing consent. You may withdraw your consent to our processing at any time, subject to legal and contractual limits and reasonable notice — see Section 5.4. Withdrawing consent to the core processing needed to run the Service means we can no longer provide it to you.
11.4 Deletion. You may request deletion of any analysis, or of your entire account and all associated records, at any time — see Section 3.4 for how, and Section 10 for the limited categories (principally billing and tax records) we are legally required to keep and cannot delete on request.
11.5 Export of your data — something we offer, not a right you hold. You will see "data portability" listed as a right in many privacy policies. Under Canadian federal law today it is not one: PIPEDA contains no data-portability or data-mobility right. A mobility framework appeared in proposed federal reform legislation, but that has not come into force, and we are not going to describe a right that does not exist and then take credit for honouring it.
What we do offer, voluntarily and free of charge, is this: on request we will provide the personal information you gave us, and the analysis results tied to your account, in a common machine-readable format so you can move it to another service. It is a commitment we are making to you in this Policy — enforceable as such — rather than one the statute imposes.
11.6 How to exercise a right, and how we verify you. Email contact@bidsafe.net describing the right you wish to exercise. To protect your information we will confirm your identity before acting — normally by verifying control of the account email; we may ask for additional confirmation for a broad access or deletion request. We will not use verification information for any other purpose.
11.7 If we refuse. In the limited cases where PIPEDA permits us to refuse a request (for example, where granting access would reveal another person's personal information, or the information is subject to legal privilege), we will tell you in writing, give the reason and the relevant provision, and explain how to complain — see Section 15.
12. Cookies, Analytics and Similar Technologies
12.1 What we use. We use a small number of strictly necessary cookies that are required to run the Service — principally to keep you signed in (session/authentication) and to protect against fraud and abuse. These cannot be switched off without breaking the Service, and PIPEDA does not require opt-in consent for them.
12.2 Analytics. We do not use third-party advertising or cross-site tracking cookies, and we do not use a product-analytics or behavioural-tracking tool. We do not sell or share behavioural data. (If we later add a product-analytics or error-monitoring tool, we will name it here, describe what it collects and whether it sets cookies, and add it to the sub-processor table in Section 6.)
12.3 Your controls. You can block or delete cookies in your browser settings; blocking the strictly necessary cookies will prevent you from signing in. We do not respond to browser "Do Not Track" signals because there is no common standard for them; we simply do not do the tracking those signals are meant to limit.
13. Children
The Service is a business-to-business tool and is not directed to, or intended for use by, individuals under the age of majority in their province or territory. We do not knowingly collect personal information from children. If you believe a child has provided us personal information, contact contact@bidsafe.net and we will delete it.
14. Changes to This Policy
We may update this Policy from time to time. When we do, we will change the "Last Updated" date at the top and, for any change that materially affects how we handle your personal information, give you advance notice by email or an in-product notice before the change takes effect. Your continued use of the Service after a change takes effect means you accept the updated Policy; if you do not agree, you may withdraw consent and close your account (Sections 5.4 and 11.3).
15. How to Contact Us; Complaints
15.1 Contact. For any privacy question or to exercise a right, contact our privacy contact, Xavier Bourgeois, Operator, at contact@bidsafe.net (postal address: 720 Main Street, Moncton, New Brunswick E1C 1E4).
15.2 Complaints to us. If you have a concern about how we handle your personal information, tell us first at contact@bidsafe.net. We will acknowledge your complaint within 10 business days, investigate, and give you a written response.
15.3 Complaint to the regulator. If you are not satisfied with our response, you have the right to complain to the Office of the Privacy Commissioner of Canada (priv.gc.ca, 1-800-282-1376).
Quebec, Alberta and British Columbia each have their own privacy authority, and if you are in one of those provinces you may be able to complain to it instead of, or as well as, the federal Commissioner:
- Quebec — Commission d'accès à l'information du Québec (cai.gouv.qc.ca)
- Alberta — Office of the Information and Privacy Commissioner of Alberta (oipc.ab.ca)
- British Columbia — Office of the Information and Privacy Commissioner for British Columbia (oipc.bc.ca)