This addendum applies when SpoolStream ("we", the processor) processes personal information on behalf of an organization that uses the service (the customer, the controller). It forms part of the terms of service. To ask for a signed copy, write to contact@spoolstream.ca.
1. What we process, and why
We process the documents and job data the customer sends through the service, and the details of its members, only to run the service for the customer: to store, deliver and print documents, to keep the history of jobs, and to send notices. The documents may contain personal information of any kind, including sensitive information. We do not need to read them, we do not read them, and we do not use them for any other purpose. Our rule is that document bytes, file names and external references never appear in logs, traces, exceptions, diagnostics, webhook delivery logs or the audit trail.
2. The customer's instructions
We process on the customer's documented instructions, which are these terms, the settings the customer chooses and its use of the service. If we think an instruction breaks the law, we tell the customer.
3. Confidentiality and access
Only the people who need it to run the service can reach the data, and they are bound by confidentiality. The service has no operator console, no platform administrator screen and no way for its staff to sign in as a customer. Operator tasks (setting a plan, linking a billing customer) are one-off commands run with the database owner's login, which row-level security does not restrict; each change they make is recorded in the organization's audit trail.
4. Security
We protect the data with measures that fit the risk, including:
- Every table that holds a customer's data carries the organization's identifier, a filter in the application and PostgreSQL row-level security. Our integration tests prove that organization B cannot read or change organization A's data, and receives 404, not 403.
- API keys and agent credentials are stored only as a keyed hash (HMAC-SHA256 under a secret pepper). A lost key is replaced, never recovered.
- Second-factor secrets, recovery codes and webhook signing secrets are stored encrypted (AES-256-GCM) under a key kept in the secret store, not in the database. Passwords are stored only as a hash made by ASP.NET Core Identity.
- A document above 5 MB goes from your system straight to the document store with a short-lived signed link, a smaller one travels inside the API request, and the agent receives a fresh five-minute link only when it prints.
- Each computer's agent has its own identity key, generated when it is enrolled. The private key never leaves the computer, and a stolen credential alone renews nothing.
- Administrative actions and sign-ins are written to an append-only audit trail that the database refuses to alter or delete, except for the scheduled removal of rows older than the retention period.
The security page describes the rest.
5. Subprocessors
The customer agrees that we use the subprocessors listed on the subprocessors page. We bind each of them to protect the data and to use it only for our instructions. We tell the owners of the customer's organization by email at least 30 days before we add or replace one. The customer can object for a good reason within that time; if we cannot meet the objection, the customer can end the agreement and delete its organization.
6. Where data is processed
The application and the database run in Toronto, Canada. The region of the document store is not chosen: the store (Cloudflare R2) gives no guarantee that documents stay in Canada. Some subprocessors are established in the United States or elsewhere. Where personal information leaves Québec or Canada, we make sure it is protected as the law requires, including by the contractual terms of the provider concerned. On request, we give the customer a description of the safeguards.
7. Helping the customer
We help the customer answer requests from the people concerned (access, correction, deletion), carry out an impact assessment and deal with the authorities, as far as our role allows. An organization can export the evidence reports of a period as a zip with a manifest, read its audit trail through the API, and download its monthly usage statement in JSON or CSV.
8. Incidents
We tell the customer without undue delay, and at the latest 48 hours after we become aware, of an incident that affects its personal information. We give what we know at that time and complete it as we learn more.
9. Deletion and return
- By default a document is deleted from storage 24 hours after its job ends, and 168 hours (7 days) after a failed one, and never while the job is in progress or uncertain.
- A job's record and its history outlive the document and are kept for as long as the organization exists; no separate retention period applies to them yet.
- Deleting an organization erases everything, jobs and their history included, 30 days after the owner asks; the owner can restore it during those 30 days. One thing is kept: if the organization was billed through Stripe, its Stripe customer number, with the date of the erasure and nothing else of the customer in our database, so that a late message from Stripe is recognised and ignored. When the erasure is carried out, the organization's subscriptions at Stripe are cancelled, so Stripe stops billing it; that number is never linked to an organization again.
- Only an owner can delete an organization, after signing in again and typing the organization's name; the other members are signed out at once, the owners are reminded 7 days and 1 day before the erasure, and an export of the audit log (CSV and JSON, with a manifest and SHA-256 sums) is prepared for them to download until then.
10. Audits
We answer the customer's reasonable questions about this addendum, and we make our security documentation available. The customer can ask once a year for a security questionnaire to be filled in. If that is not enough, the customer may carry out an audit once a year, at its own cost, with 30 days' notice, during working hours and under confidentiality. Subprocessors are checked through their own reports.
11. Liability and law
The terms of service, including their limit of liability and their governing law, apply to this addendum.
12. Duration
This addendum lasts as long as we process data for the customer. What we keep after that, and for how long, is set out above.