Legal
Data Processing Addendum
Version 1.0.0 · Effective October 5, 2026
This Data Processing Addendum ("DPA") forms part of the Terms of Service between the Customer named below and Viscous Bits Computing Solutions Inc., operating as ReceiveVault ("Viscous Bits", "we"). It applies to the personal information in Customer Content that we process for the Customer through the Service. Capitalized terms not defined here have the meaning in the Terms of Service.
1. Roles
1.1 For Customer Content, which means the files Contacts upload or receive, the Customer's address book, request and delivery records, and the access records attached to them (Annex 1), the Customer is the accountable organization under privacy law. It determines the purpose of collection, chooses the Contacts, and sets retention within the limits of the Service.
1.2 Viscous Bits is the Customer's service provider. We process Customer Content only to provide the Service as the Customer instructs through the Service's controls, this DPA, the Terms and the Privacy Policy. We do not use it for our own purposes.
1.3 For account information about the Customer's users, billing, audit records and support, we are the accountable organization in our own right, as described in the Privacy Policy. This DPA does not cover that information.
2. Instructions
2.1 The Customer instructs us to collect, store, scan, transmit, make available, back up and delete Customer Content as the Service's features provide. Creating a request, setting a retention window, deleting a file, exporting records and closing the account are instructions.
2.2 We will tell the Customer if we believe an instruction breaks the law, and we may pause it until resolved.
2.3 We will not process Customer Content in any other way unless a law requires it, in which case section 8 applies.
3. Confidentiality and access
3.1 Our staff (one person today) are bound to confidentiality and can see account details and file metadata (filenames, sizes, dates, scan results, Contact names and email addresses) to run the Service, provide support, handle abuse reports and meet legal duties.
3.2 Our administrative tools cannot open file contents. We open the contents of a file only at the Customer's written request or when the law requires it, and each such access is recorded in the audit log. End-to-end encrypted files cannot be read by us at all.
3.3 Views of Customer records in our administrative tools are recorded in the audit log.
4. Security
4.1 We maintain the security measures described on our Security page and in section 8 of the Privacy Policy, including TLS in transit, server-side encryption of all stored files, encrypted authentication secrets, multi-factor authentication, rate limiting, virus scanning of every upload we can read within the published size limit, and a per-event audit log.
4.2 We may improve these measures but will not reduce the overall level of protection during the term.
4.3 The Customer is responsible for its own users' credentials, its choice of retention settings, its use of end-to-end encryption where available, and for downloading and keeping copies of anything it must retain.
5. Sub-processors
5.1 The Customer authorizes the sub-processors listed on our sub-processors page at receivevault.com/subprocessors, which is the list of record. Each is bound by written terms that include data-protection commitments. Where a sub-processor's standard terms apply, we have reviewed them against this DPA and record the result in our sub-processor review.
5.2 We email the Customer's account owner at least 30 days before a new or replacement sub-processor handles Customer Content. The Customer may object by closing its account without penalty in that window. An emergency replacement may happen faster, with notice as soon as practicable. Removing a sub-processor needs only a page update.
5.3 We remain responsible for our sub-processors' handling of Customer Content.
6. Location
6.1 Customer Content is stored and processed in Canada (Toronto, Ontario), and backed up, in encrypted form, to backup storage operated by us in Ontario, Canada. We will not move Customer Content outside Canada without 30 days' notice under section 5.2.
6.2 Emails the Service sends at the Customer's request leave through a Canadian relay and are then delivered to each recipient's own email provider, which may be outside Canada. Message bodies never contain file contents.
7. Breach notification
7.1 If we confirm a breach of security safeguards involving Customer Content, we notify the Customer's account owner without undue delay, aiming for 72 hours from confirming it, with what we know: what happened, when, what information and how many Contacts are affected, what we have done, and a contact for questions. We update the Customer as facts arrive.
7.2 The Customer decides whether and how to notify its Contacts and any regulator, and we assist. Where a law requires us to notify Contacts or a regulator directly, we coordinate with the Customer first where the law allows.
7.3 We keep a record of every breach for 24 months.
8. Legal demands
8.1 Other than to the sub-processors in section 5 and as the Customer instructs, we disclose Customer Content to a third party only when a valid legal demand compels it, or in an emergency involving an imminent risk of death or serious bodily harm, as the Privacy Policy describes. We check validity, push back on overbroad demands, and disclose only what the demand compels.
8.2 We tell the Customer before disclosing unless a court order or the law prohibits it, or notice would itself break the law, and we tell the Customer when the prohibition ends or the concern lapses. The Customer decides what to tell its Contacts.
9. Assistance with individuals' requests
9.1 If a Contact asks us for access to, correction of or deletion of their information, we refer them to the Customer and tell the Customer within 5 business days.
9.2 The Service's own controls (download, export, delete, retention settings) are the primary means of meeting a Contact's request. Where they are not enough, we assist on request.
10. Retention, return and deletion
10.1 Files are deleted on the retention schedule the Customer sets, from 7 to 365 days after a request's last activity (90 by default), and 30 days after a delivery expires. One year is the maximum for any file. Request records remain until the Customer deletes them, one year after archiving, or account closure.
10.2 The Customer may export its records at any time and must download file contents before they are deleted. The audit log is kept for 12 months; a Customer needing a longer record exports audit.csv.
10.3 On account closure, Customer Content is removed from the live Service within 31 days and from backups within a further 30 days, except records a law requires us to keep.
10.4 The Customer meets its own record-keeping duties (for example under anti-money-laundering, law society or tax rules) through export or its own copies. The Service is not a records archive.
11. Special categories
11.1 Government identification images collected through the identification feature are a special category of Customer Content. The Customer collects them only with a lawful purpose and any consent the law requires, never collects health cards or social insurance numbers through the feature, never collects identification from a Contact under 16, and acknowledges that we store and transmit the images without verifying them.
11.2 Health information is governed by Schedule A where the Customer is a health information custodian.
12. Verification
12.1 On written request, no more than once a year unless a breach has occurred, we will answer the Customer's reasonable written questions about our compliance with this DPA and provide the relevant parts of the account's audit log.
12.2 We do not offer on-site audits. The Security page, the Sub-processors page and this DPA are our published record.
13. Term and precedence
13.1 This DPA lasts as long as we hold Customer Content for the Customer.
13.2 If this DPA conflicts with the Terms of Service on the handling of Customer Content, this DPA governs. Liability is governed by the Terms.
13.3 Changes to this DPA follow section 15 of the Terms (30 days' notice for material changes).
Annex 1: Customer Content
| What | Detail |
|---|---|
| Address book | Contact name, email address, phone, organization, notes and tags the Customer writes, and where the entry came from (manual, CSV or vCard import) |
| Requests and deliveries | Title, description, the message to the Contact, the Contact's name and email address, expiry and limits, the link token (hashed), and for deliveries any password-protection parameters (we hold a salt and a check value, never the password) |
| Files | The file itself, its original filename, size, type, SHA-256 hash, scan result, and end-to-end encryption parameters where used |
| Government identification images | Where a Customer asks for it, an image of the front or back of an identity document, recorded with the document type and side. Stored like any other file, encrypted at rest, on the Customer's retention schedule, and not openable by our administrative tools. We do not read or verify the document. Text a Contact's browser decodes from a licence barcode to check legibility is never sent to us |
| Access records | For each upload and each download: the IP address and browser identifier of the device that did it, and the time. For email access codes: the address the code went to, the hashed code, IP address and browser identifier |
Contacts: the Customer's clients, patients, applicants, tenants or other individuals the Customer chooses. Purpose: collecting documents from, and delivering documents to, those individuals in the course of the Customer's business.
Schedule A: Health information custodians (Ontario PHIPA)
This Schedule applies where the Customer is a health information custodian under Ontario's Personal Health Information Protection Act, 2004 ("PHIPA"), and where an equivalent law elsewhere in Canada applies, with the equivalent terms read in.
A.1 Our role. We provide the Service to the custodian as an electronic service provider that is not an agent of the custodian and not a health information network provider. We supply the means to collect and deliver documents; we do not provide the Service to enable two or more custodians to share personal health information with each other, and the Terms prohibit that use.
A.2 No use or disclosure. We do not use personal health information except as necessary to provide the Service, and we do not disclose it, except as a valid legal demand compels (section 8) or the custodian instructs.
A.3 No health numbers. Health cards are not offered as an identification document type. The custodian must not collect a health number through the identification feature or ask Contacts to write one in a message field.
A.4 Breach. We notify the custodian at the first reasonable opportunity, aiming for 72 hours from confirming, if personal health information in its Customer Content is stolen, lost, or used or disclosed without authority. The custodian's own PHIPA duties to notify individuals, the Information and Privacy Commissioner of Ontario and, where required, a regulatory college, and its annual statistical reporting, remain the custodian's.
A.5 Audit log. On request we provide the account's audit log entries for the 12 months the log is kept: every action on its Customer Content by its users, every access by us to file contents or to the account's records (sections 3.2 and 3.3), and every disclosure under section 8. The custodian exports the log if it needs a longer record.
A.6 Retention and deletion. Files follow the retention schedule the custodian sets, up to one year, and records follow section 10. The custodian keeps the health record itself; the Service is a means of transfer, not the record of care.
A.7 Location. Personal health information stays in Canada under section 6.
A.8 Custodian's undertakings. The custodian confirms that it has authority to collect the personal health information it requests, that it has told individuals how it collects and uses it, and that it will not use the Service to exchange personal health information with another custodian.
Signature
This DPA is agreed when the Customer's account owner accepts it in the Service or by email to legal@receivevault.com, naming the account.
Customer: ____________________ (account name)
Health information custodian under PHIPA: yes / no (Schedule A applies if yes)
Date: ____________________
Viscous Bits Computing Solutions Inc., operating as ReceiveVault, Ontario, Canada. legal@receivevault.com
What changed
- 1.0.0 (this version). First published version.