Security
Your records stay yours
You are handing us your subcontractors’ insurance paperwork. Here is exactly what keeps it separate from every other contractor using Sealinn, what stops the compliance history being quietly changed, and what you walk away with if you leave.
Last updated: August 30, 2026. If your procurement process wants this as an annex rather than a page, the same measures are set out clause by clause against GDPR Article 32 in Annex B of the data processing addendum.
Signed-in workspaces stay isolated at the database layer.
Tables holding workspace data are locked to one company inside the database itself, not just in the app. Sealinn signs in with an account that has no power to unlock that rule — so a query written wrongly returns nothing rather than someone else's records.
The ordinary application role cannot rewrite your audit history.
Sealinn attempts to record key upload and review actions, including approvals, overrides and rejections. The tenant-facing database role has no permission to update or delete those rows, so an ordinary product request cannot rewrite them. A restricted maintenance role can administer the database, and an audit insert can fail independently of the product action; access controls and monitoring therefore remain part of the boundary.
Cancel and you keep everything.
Canceling moves you back to the free plan — it does not lock you out. You can still download your certificates as a zip, organized by subcontractor, export your compliance ledger to Excel or CSV, and export the full audit log to PDF, Excel or CSV. Plan limits apply to adding new subcontractors, never to reading or exporting what is already yours.
Where your data is held
Two places, both read back from the running 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)
- In transit and at rest
- Encrypted in both cases. The connection to the database and to storage is TLS, and both providers encrypt what they hold on disk.
- Other companies involved
- 10 active companies, each named — hosting, the database, storage, sign-in, email, text messages, the job queue, payment, error monitoring and product analytics. 2 inactive providers remain disclosed for historical context and any future reviewed activation. The list also identifies 1 provider disclosed in advance but not active. The complete list is on service providers we use. A unit test compares provider-specific credentials in the committed production environment template with this list. That catches credentialed integrations; dashboard- and source-control-configured services still require manual review.
Who can reach it
Signed-in access, customer-directed bearer links and raw file storage have different boundaries.
- Sign-in
- Handled by Clerk. Sealinn never sees or stores a password — there is nowhere in our database to put one.
- Inside your workspace
- 4 roles you can assign, from owner down to project manager. Action permissions are enforced on the server. Project managers can read projects assigned to them and the subcontractors, documents, dashboard status, and scoped reports connected to those projects; organization-wide reports and other projects remain hidden.
- The application's own account
- Sealinn connects to the database as a role that cannot bypass row-level security, and cannot update or delete the audit log. Those are two things the database refuses, not two things our code remembers to avoid.
- The files themselves
- Raw object-storage locations are not public browser addresses. Signed-in previews use authenticated, workspace-scoped proxy routes; signed-in downloads and direct views use signed links that expire after 1 hour. An upload link lasts 10 minutes. A certificate cannot be reached by guessing a storage URL.
- Links you send subcontractors
- A subcontractor uploads through a recipient-specific link with no account and no password. The same link can be reused during its 7-day window for the document types requested. The token is stored only as a hash, can be revoked at any time, and is rotated when a replacement link is issued.
- Producer and supplier response workspaces
- A URL under /respond/ is a bearer credential, not an account or identity check. The customer copies and delivers it manually; Sealinn returns the raw token once and stores only its SHA-256 hash. The customer selects a 1-to-30-day lifetime and can revoke it sooner. A supplier link is limited to that supplier within the customer; a producer link is limited to the recorded suppliers and, when chosen, exact project assignments. Anyone possessing the URL can act within that live scope, which is rechecked on every operation.
- Selected evidence rooms
- A URL under /evidence-room/ is also a bearer credential, manually copied by the customer and stored only as a token hash. It exposes only the exact selected manifest, file hashes and customer-decision snapshots. It cannot outlive the 24-hour packet archive, can be revoked, and fails closed if a selected file is no longer clean, available or hash-matched. View, download and acknowledgment events are anonymous link-activity records, not identity verification or an electronic signature.
- Unfinished supplier intake
- Draft form fields are AES-GCM-256 encrypted in that device's local storage with a key derived from the response credential and supplier scope. The draft is not synchronized to Sealinn or another browser, excludes the consent checkbox, and is cleared after successful submission or an explicit clear. An invalid or expired draft is removed when the workspace is next visited.
What happens to a document you upload
The part most security pages leave out, including the awkward half.
- Virus scanning
- Document uploads stay outside the review queue until our background worker records a clean scan. If the scanner or its queue is unavailable, the document is rejected and the signed-link and authenticated-proxy serving paths both refuse it; infected files are handled the same way and deletion is requested. New contract uploads are not currently supported. Authorized historical contract rows take a scan-only path and are never sent for field extraction.
- Automated document reading
- Automated AI field extraction is currently unavailable, so new uploads are not sent to OpenAI for reading. Historical processing and any future reviewed activation remain subject to the provider's published API default: data is not used to train models and abuse-monitoring logs may be retained for up to 30 days. Sealinn has not recorded a project-specific zero-data-retention readback.
- Historical W-9 processing disclosure
- Before Sealinn limited new AI document reading to COIs, an uploaded W-9 page image could be sent to the AI provider. Its taxpayer number was not extracted into Sealinn fields, but it was visible in that transferred image. New W-9 uploads and AI reads are now disabled; this disclosure remains because the current product boundary must not erase what may already have happened.
- A person still decides
- Your authorized reviewer compares the original COI with your requirements and records the customer decision. If automated confidence routing is enabled later, its score will remain review context rather than an approval. How automated reading is designed to work documents that conditional design and its limits.
How long we keep it
Every window below is a number in the code, not an intention.
- Your compliance history
- Kept for the life of the workspace. For a compliance product the record of who approved what is the thing you need years later, so it is deliberately not on a purge schedule.
- If you ask us to delete the workspace
- It stays recoverable for 30 days. The scheduled purge then removes the workspace and its workspace-scoped database rows and requests deletion of every stored object key it can enumerate. Storage failures are logged, but failed keys are not yet kept in a durable retry queue; provider backups roll off on their own schedules.
- Rejected documents
- Recoverable for at least 3 days. After the grace period, a scheduled purge requests deletion of the stored file and removes the row only after that succeeds; failures leave the row for a later retry, while provider backups follow the provider's schedule.
- Generated reports
- 3 days — they are cheap to regenerate, so they do not linger. A failed one goes after 1.
- Response-workspace links
- Active for a customer-selected 1 to 30 days and revocable sooner. The invitation, scope and response history stay with the workspace after link expiry until workspace deletion.
- Evidence packets and rooms
- A generated packet ZIP is available for 24 hours. Its expiry job requests deletion of the transient object; a failed storage deletion keeps the ready record for another daily sweep. The immutable manifest and digest, selected room scope, revocation and anonymous activity records stay with the workspace; the room itself cannot outlive the ZIP availability window and can be revoked sooner.
- The full policy
- Every window, what we collect and why, and how to make a request is in the privacy policy, which renders these same numbers from the same source.
The questions people actually ask
Do you hold any security certifications?
What am I actually storing here?
Something looks wrong. Who do I tell?
See also the Privacy Policy, the Subprocessors list and the Terms of Service.
Looking for a different document? They are all listed on the Legal page.
