Data Processing Addendum
Last updated: August 1, 2026
1. Who is who
For the data in your workspace you are the controller and Sealinn is the processor. You decide which subcontractors to track, which documents to require and what the rules are; we act on your instructions and do not decide those things for you.
Using the product as documented is a documented instruction. Where we would need to process your data for anything outside that, we will ask.
2. Subject matter, duration, nature and purpose
- Subject matter: collecting, reading, checking and storing insurance certificates and related compliance documents.
- Duration: for as long as your workspace exists, plus the deletion windows in section 8.
- Categories of data subject: your team members, your subcontractors’ contacts, and individuals named on the documents those subcontractors upload.
- Categories of personal data: names, business email addresses and phone numbers; and whatever appears on an uploaded document. That last category is broad because the documents are supplied by third parties — a W-9, for instance, carries a taxpayer identification number. Sealinn never extracts that number, but the image containing it is stored.
3. Confidentiality
Everyone with access to your data is bound to keep it confidential. Access is limited to what is needed to run and support the service, and every action taken inside a workspace is written to an audit log that the application has no permission to alter or delete.
4. Security measures
The measures are described concretely, with the mechanism named, on the security page rather than summarized into adjectives here. In outline: each workspace is isolated at the database row level and enforced by the database itself rather than by application code; the application connects as a role that cannot bypass that isolation; documents are stored privately and served only through short-lived signed links; and uploads are scanned for malware before they are read.
5. Subprocessors
We use 12 subprocessors, each named on the subprocessors page together with what it does and which category of data it receives. That list is derived from the credentials the deployment actually requires and is checked against them by a test, so a provider cannot be added without appearing on it. Where your data sits at rest is a separate question, and it is answered in section 10 below.
You give general authorization for those subprocessors. Before we add another one, we will write to your workspace owner at least 30 days beforehand — naming the provider, what it will do and what data reaches it. You do not have to ask to be on that list, and there is nothing to opt into.
If a new provider is a problem for your business, reply to that notice or write to privacy@sealinn.com before the effective date and we will talk it through. We will not pretend an objection is always resolvable — some providers are load-bearing — but you will hear about it in time to raise it rather than afterwards.
Notice sent to an inbox is not a record, so every change is also dated on the subprocessors page, which today holds the single entry recording the first publication of the list — nothing has been added since. That log is checked against the list itself, so a provider cannot appear on one and be missing from the other.
One deserves calling out on its own: certificate images are sent to OpenAI to be read. Their API does not use that data for training, and they retain it for up to 30 days for abuse monitoring before deleting it. Zero-retention processing exists but has to be approved by them and is not enabled for us — so we do not claim it.
6. Helping you answer data-subject requests
Where an individual exercises a right against you — access, correction, deletion, portability — the tools to answer it are in the product: a subcontractor’s record is visible, editable and exportable, contact details included, and a workspace owner can delete a subcontractor and their documents outright.
If a request reaches us directly rather than you, we will not answer it on your behalf; we will pass it to you, except where we are the party being asked to stop contacting somebody. A subcontractor can always opt out of our messages themselves, through the unsubscribe link in any email or by replying STOP to a text — both arrive on the message itself, so neither depends on finding us first — and that takes effect without either of us doing anything.
7. Personal data breaches
If we become aware of a breach affecting your data we will tell you without undue delay, with what we know at the time: what happened, which categories of data and roughly how many records are involved, the likely consequences, and what we are doing. We will keep you updated as we learn more rather than waiting until the picture is complete.
There is a reason that says “without undue delay” and not a number of hours. Under the GDPR the 72-hour clock belongs to the controller — you — and it starts when you become aware. Our job is to inform you promptly enough that you can meet it, and to tell you when we became aware so your clock is measured from the right moment. A processor publishing its own shorter deadline sounds reassuring and answers the wrong question.
What is behind that commitment is a written procedure rather than an intention: how an incident is contained, what evidence is preserved before anything is fixed, how the affected records are counted rather than estimated, and who gets written to in what order. It also names what we do not have — no on-call rotation, no 24/7 response, no incident retainer — because those are the details that decide how fast this actually goes, and you should be able to price them in.
Report anything you think is an incident to security@sealinn.com. If it is a vulnerability rather than a live breach, the same address and the practice on the security page apply.
8. Return and deletion
Everything we hold about your subcontractors comes back out in the product, at any time and including after you cancel: the roster with its contact details, the documents themselves, the compliance ledger and the full audit log. Export is gated on permission and never on plan.
When you ask us to delete a workspace it enters a 30-day grace window during which it keeps working and you can change your mind. After that a scheduled job erases every row and every stored file. One record deliberately survives: if somebody has asked us to stop contacting them, we keep the email address or phone number, and the date of the request — so the opt-out keeps working after the contractor who first messaged you leaves. Erasing it would mean another customer’s reminders reaching them again. Retaining the minimum needed to honor an objection is the recognized carve-out under both GDPR Article 17(3) and CCPA, and the full list of windows is on the privacy page.
9. Information and audits
We will give you the information you reasonably need to show that we are meeting these obligations. Concretely, that means three things you can rely on:
- What is already published. The measures in Annex B, the providers on subprocessors and the architecture on security are written to be checked, not skimmed — every claim names the mechanism behind it.
- A completed questionnaire. Send yours to privacy@sealinn.com and we will answer it in writing within 30 days, once per year without charge. If a question’s honest answer is “we do not do that”, that is the answer you will get.
- Notice of a change that matters. If a measure in Annex B stops being true, we update it — see section 14.
What we do not offer is an on-site inspection or a live audit of the running system, and saying so is more useful than a clause promising one. Sealinn is a small operation; an audit right nobody could service is a term that fails the first time it is exercised.
10. International transfers
Sealinn is operated from Canada. Your data at rest sits in two places, both read back from the running production system rather than taken from a diagram:
- The database: AWS us-east-1 (Northern Virginia, United States)
- Uploaded documents: Cloudflare R2, Eastern North America (the ENAM location hint — a placement preference, not a guarantee)
We do not publish a region for each individual subprocessor, and the subprocessors page says so in as many words. The rest of that list processes data in transit or holds operational records rather than your documents, and we cannot verify where each of them runs from here. A column filled in by assumption would be worth less to you than no column. Where a transfer needs a safeguard, we rely on the standard contractual clauses in each provider’s own data processing addendum.
11. Liability and indemnity
Liability under this addendum is governed by the limits in section 17 of the terms, and those limits apply to the two of us together rather than once each — an addendum that quietly reset the cap would make the number in the terms meaningless.
Each of us is responsible for our own side of the arrangement. You decide which subcontractors to track, what to require and who on your team can see it; we are responsible for handling that data as this addendum describes. Where a regulator or an individual comes after one of us for something the other did, the one who did it carries it.
12. How this fits with the rest
This addendum forms part of the terms of service. Where it and the terms could be read differently about the processing of personal data, this addendum wins; on everything else — payment, plan limits, cancellation — the terms do. Nothing here creates a second agreement, and there is nothing separate to sign.
The published pages this addendum points at are part of it in substance: privacy for what is held and for how long, subprocessors for who receives it, and security for how it is protected. They are separate pages because a reader looking for one of them should not have to read a contract to find it, not because they are less binding.
13. Changes to this addendum
We may update this addendum — to reflect a change in the law, a change in how the product works, or because something here turned out to be wrong. The date at the top of the page changes with it.
If a change materially reduces your rights or our obligations, we will write to your workspace owner before it takes effect rather than relying on you noticing the date. New subprocessors have their own notice period and their own dated log, set out in section 5.
14. Annex B — technical and organizational measures
These are the Article 32 measures, grouped by the sub-paragraph each answers. They are written as mechanisms rather than adjectives on purpose: “enterprise-grade” cannot be checked by anybody, and naming the database role that cannot bypass row-level security can be.
Keeping one customer's data away from another's (Art. 32(1)(b))
- Every table holding customer data has row-level security enabled and FORCED in Postgres, so the isolation is enforced by the database rather than by application code remembering to filter.
- The application connects as a database role that cannot bypass row-level security. A query that escapes its workspace scope returns nothing; it does not return somebody else's rows.
- A build-time lint rule refuses a tenant-scoped query written without a workspace filter, so the first line of defense is checked before the code is merged rather than in review.
Encryption and data minimization (Art. 32(1)(a))
- Everything in transit is TLS, and in production the certificate is verified rather than merely accepted — including on the privileged database connection, where an unverified certificate would let anything on the path read every workspace.
- Data at rest is encrypted by the database and object-storage providers, which is their default and is stated in their own documentation rather than ours.
- Uploaded files are never public. They are served only through signed links that expire, and the raw storage locations are not reachable from a browser.
- Upload links sent to subcontractors are stored only as a hash, so the token in the email cannot be recovered from our database. They expire on a fixed window and can be revoked.
- A W-9's taxpayer identification number is never extracted or stored as data — the instruction to the reader excludes it, and a filter drops it again if it ever came back. The image containing it is stored, and that is said plainly rather than glossed.
Access control and accountability (Art. 32(1)(b))
- Access inside a workspace is role-based, and every mutation checks the permission it needs rather than trusting the screen that called it.
- Every approval, override, rejection and settings change is written to an audit log, and the application's database role has UPDATE and DELETE revoked on that table — so the application cannot alter the record it wrote.
- The audit log is kept for the life of the workspace and is exportable at any time, including after cancellation. Export is gated on permission and never on plan.
Integrity of what comes in (Art. 32(1)(b))
- Uploads are scanned for malware before anything reads them, and the scanner fails closed: if it cannot be reached, the upload is refused rather than waved through.
- Every input crossing the API boundary is schema-validated, and file uploads are bounded by real byte size read back from storage rather than by what the browser claimed.
- Inbound webhooks are signature-verified and de-duplicated against a ledger, so a replayed or forged event cannot change a subscription or a user record.
- Expensive operations are rate limited per workspace and per address, and the AI extraction budget is capped globally so a burst cannot run up a bill or starve other customers.
Availability and restoration (Art. 32(1)(b), 32(1)(c))
- The application and the background worker run on managed platforms with automatic restart, and a health endpoint reports whether the worker is actually consuming its queues rather than merely running.
- Background work is queued with bounded retries and a wall-clock timeout, so a stuck job is retried and then surfaced rather than holding a document indefinitely.
- The database provider retains point-in-time history from which a database can be restored.
Testing that any of this still works (Art. 32(1)(d))
- Every change runs type checking, linting, a dependency vulnerability audit that blocks on a high advisory, and the unit, integration, smoke and end-to-end suites. A failure stops the change, it does not warn about it.
- The tenant-isolation property is covered by tests that read from one workspace while scoped to another and assert nothing comes back — the guarantee is tested, not assumed from the schema.
- An accessibility scan runs on every change with no rules excused, and a build-time check rejects marketing text below the minimum size.
- Published claims are bound to the code that makes them true wherever possible — retention windows, the subprocessor list, signed-link lifetimes and the export capability are all rendered from the constants that enforce them, and a test fails when a page and the software disagree.
People and process (Art. 32(1)(b), 32(1)(d))
- Everyone with access to customer data is bound to confidentiality, and access is limited to what running and supporting the service requires.
- Third parties are disclosed on the subprocessors page, and that list is derived from the credentials the deployment actually needs — so a new provider cannot be wired in without appearing there.
- Vulnerability reports have a published address and a coordinated-disclosure practice, including a machine-readable security.txt.
Two numbers that belong here and are enforced in code rather than described: a download link to a stored document is signed and short-lived, and an upload link sent to a subcontractor expires after 7 days. The audit log is kept for the life of the workspace — deliberately absent from every purge, because for a compliance product the record of who approved what is the thing you need years later.
15. Execution
This addendum applies as part of the terms from the moment you start using the service; nothing needs to be signed for it to be in force.
Looking for a different document? They are all listed on the Legal page.