Privacy Policy
How Sigill AS collects, uses, and protects personal data when you use Sigill.ai. This notice is written to match what the platform actually does, not the marketing version. If a claim here does not match what Sigill.ai does, write to contact@sigill.ai and we will correct it.
Summary
- We do not keep copies of your files or documents. Sigill is not a document store. For timestamping and verification, only a SHA hash crosses the network and your file never leaves your machine. For sealing, the file bytes are processed in memory inside the EU and the sealed output is streamed straight back in the HTTP response — neither the unsigned input nor the sealed output is persisted.
- What we do store, per request, is the hash, your label, and a small set of metadata (algorithm, TSA name, certificate validity window, success or failure). Optionally — under a per-tenant setting — we also store the RFC 3161 timestamp token (TSR) and, for CAdES seals only, the detached
.p7ssignature. You can turn both off and the row will hold the hash and metadata only. - The one narrow exception is our MCP server. Because the Model Context Protocol cannot return binary blobs in a tool response, file uploads and sealed downloads transit through a server-side slot with a hard 1-hour expiry, after which the row is deleted. This is the only place Sigill temporarily holds file bytes, and only for MCP-mediated requests.
- Evidence metadata, signing keys, audit logs, and database backups reside in AWS
eu-north-1(Stockholm). Sub-processors are listed at /trust-center/sub-processors. - We do not sell personal data. We do not run advertising trackers. We do not profile users for any purpose other than billing entitlement and security.
- You have rights under the EU General Data Protection Regulation (GDPR) and the Norwegian Personal Data Act. They are set out below and you can exercise them by writing to
contact@sigill.ai.
Who we are
The data controller is Sigill AS, a private limited company (aksjeselskap) established in Norway, with its registered office in Trondheim. Throughout this notice, "Sigill", "we", "us" and "our" mean Sigill AS. Where Sigill.ai processes personal data on behalf of a paying tenant — for example, when a tenant uses the platform to seal documents that contain personal data of their own end users — we act as a processor for that tenant under Article 28 of the GDPR. Those terms are set out in our Data Processing Agreement.
Sigill AS is established in Norway, an EEA state, and is supervised by the Norwegian Data Protection Authority (Datatilsynet).
What we collect and why
The categories below describe data that Sigill collects when you use the platform. Each row states the legal basis under Article 6 of the GDPR and how long the data is kept.
| Category | Purpose | Legal basis | Retention |
|---|---|---|---|
| Account data — email, display name, password hash, federated-identity claims (Google, Microsoft Entra ID) | Creating and maintaining your Sigill.ai account; authentication | Performance of a contract (Art. 6(1)(b)) | Lifetime of the account; deleted within 30 days of account closure |
| Tenant data — organisation name, plan, billing email, role assignments | Operating your tenant workspace, applying plan entitlements | Performance of a contract (Art. 6(1)(b)) | Lifetime of the tenant; deleted within 30 days of tenant closure |
| Evidence metadata — file hash, optional label, algorithm, TSA name, certificate validity window, signature type, success or failure | So that you can recognise your own past stamps and seals and prove on demand that a given hash was processed by Sigill at a given moment | Performance of a contract (Art. 6(1)(b)) | Retained while your tenant is active; you may delete individual records via the API at any time |
RFC 3161 timestamp token (TSR), base64 — only when the tenant's StoreTsr setting is on (default on) | Returning the upstream-signed token to you on later retrieval so you can verify a stamp without re-fetching from the TSA | Performance of a contract (Art. 6(1)(b)) | Retained while your tenant is active; you may delete the record or disable storage tenant-wide at any time |
CAdES detached signature (.p7s), base64 — only when the tenant's StoreCadesP7s setting is on (default on); never the sealed PDF | Returning the detached signature on later retrieval. PAdES sealed PDFs are never persisted — the seal is embedded in the PDF that is streamed back in the response. | Performance of a contract (Art. 6(1)(b)) | Retained while your tenant is active; you may delete the record or disable storage tenant-wide at any time |
| Unsigned input bytes (PAdES / CAdES sealing) | Processed in memory only to produce the signature, then discarded with the response. Not persisted. | Performance of a contract (Art. 6(1)(b)) | Not retained — the bytes do not outlive the HTTP request |
Sealed output bytes (PAdES PDF or CAdES .p7s) returned to you | Streamed back in the HTTP response. Not persisted — Sigill does not keep a copy of the sealed file. | Performance of a contract (Art. 6(1)(b)) | Not retained — the bytes do not outlive the HTTP request |
| MCP temporary upload / download slots (file bytes, BYTEA) — only when the MCP server is used | The Model Context Protocol cannot stream binary content in a tool response, so MCP uploads land in seal_mcp_upload and sealed outputs are placed in seal_mcp_download for the client to fetch via a one-time URL. Used only via the MCP integration. | Performance of a contract (Art. 6(1)(b)) | 1 hour hard expiry. Rows are deleted on the next MCP upload request and are unreadable after expiry. Max upload size 50 MB. |
Verification (PAdES, CAdES, or RFC 3161 TSR) — files you submit to /seal/verify | Stateless cryptographic verification. Sigill writes nothing to the database during a verify call — no hash, no row, not even an audit entry. | Performance of a contract (Art. 6(1)(b)) | Not retained — the verify endpoint is fully stateless |
| Audit log — security-relevant actions (login, role change, API-key creation, seal, stamp, verify) | Security investigations, fraud detection, support, and the integrity of your own audit trail | Legitimate interest (Art. 6(1)(f)) and, for security obligations, legal obligation (Art. 6(1)(c)) | Per plan — Free: 7 days · Starter: 30 days · Business: 90 days · Scale: 365 days. Pruned automatically. |
| Billing metadata — plan, Stripe customer ID, invoice records (no card data ever reaches Sigill) | Charging the subscription you bought; issuing invoices required by Norwegian and EU tax law | Performance of a contract (Art. 6(1)(b)) and legal obligation (Art. 6(1)(c)) | 10 years from the end of the financial year, per the Norwegian Bookkeeping Act (Bokføringsloven § 13) |
| Operational telemetry — request logs, error traces, IP at the edge | Service availability, abuse prevention, debugging | Legitimate interest (Art. 6(1)(f)) | 30 days, then aggregated or deleted |
| Contact form submissions — name, email, optional company, message, IP at submit time | Answering your enquiry; Cloudflare Turnstile bot screening | Legitimate interest (Art. 6(1)(f)); consent for Turnstile cookie (Art. 6(1)(a)) | 12 months from last correspondence |
What Sigill does not collect
- Your file, when you timestamp. RFC 3161 timestamping operates on a SHA hash. Your file never leaves your machine. Sigill cannot reconstruct the file from the hash and never tries to.
- Your file, when you seal it. Both the unsigned input and the sealed output are handled in memory and streamed back in the response. Sigill does not write either to durable storage — we are not a document store. What persists is the file's hash and a small metadata row; optionally, the RFC 3161 timestamp token and (for CAdES only) the detached
.p7ssignature, governed by per-tenant settings. PAdES sealed PDFs are never persisted. - Your file, when you verify it. The verify endpoint is fully stateless. Nothing is written to the database — no hash, no row, no audit entry.
- Payment card data. Card details are entered directly into Stripe's hosted checkout and tokenised before Sigill sees anything. We only ever receive the Stripe customer ID, plan, and invoice metadata.
- Cross-site tracking. Sigill.ai does not run advertising trackers, marketing-attribution pixels, or third-party analytics that profile visitors across sites.
- Sensitive categories of personal data. The service is not designed to process Article 9 special categories (health, biometric, religious, political, sexual-orientation data). Customers should not upload such data unless their use case warrants it and they have an appropriate lawful basis themselves — Sigill processes the bytes regardless of content.
MCP — narrow exception. Customers who use the Model Context Protocol integration upload file bytes to a temporary slot and retrieve sealed output from a temporary slot, because MCP tool responses cannot carry binary content. Those slots live in the seal_mcp_upload and seal_mcp_download tables in eu-north-1, with a hard one-hour expiry and a 50 MB upload cap. The MCP integration is opt-in by nature — if you use the HTTP API or web UI directly, no MCP slot is ever created.
Sub-processors and international transfers
The third parties that process customer data on our behalf are listed at /trust-center/sub-processors. Each entry states the purpose, the categories of data they receive, and the region in which they operate. Sigill's primary application data plane runs in AWS eu-north-1.
Where a sub-processor operates outside the European Economic Area, the transfer relies on the EU Commission's Standard Contractual Clauses and — where the counterparty is established in the United States — the EU-US Data Privacy Framework. Customers on a paid plan with an executed Data Processing Agreement are notified by email at least 30 days before a materially new sub-processor is introduced, so that they have a reasonable window to object.
Security
Signing keys are held in AWS KMS as non-extractable material — private key bytes never appear in memory or on disk outside the KMS HSM boundary. Tenant isolation is enforced at three layers: application-level authorisation that re-reads role from the database on each request, ORM-level tenant filters, and DTO-level capability boundaries that prevent mass-assignment of billing or entitlement fields. Security-relevant actions are recorded in a transactional audit log. The full architecture is documented at /trust-center/security-architecture.
No platform is perfectly secure. If you suspect a vulnerability, key compromise, or cross-tenant access, write to security@sigill.ai — see responsible disclosure for scope and response targets.
Cookies and similar technologies
Sigill.ai uses a small number of strictly necessary cookies and one third-party challenge cookie:
- Session cookie — set on login to keep you signed in. First-party, HTTP-only, SameSite=Lax. No tracking.
- Language preference (
i18n_lang) — remembers your chosen interface language (English or Norwegian). First-party. No tracking. - Cloudflare Turnstile — loaded on the public contact form only, to distinguish humans from bots. Cloudflare's challenge may set short-lived cookies and read browser characteristics; data flows to Cloudflare as the challenge provider. Turnstile is not loaded on the application itself.
Sigill.ai does not deploy advertising cookies, marketing-attribution pixels, or third-party analytics that profile visitors.
Your rights under the GDPR
As a data subject in the EU or EEA, you have the following rights with respect to personal data Sigill holds about you. You can exercise any of them by writing to contact@sigill.ai from the email address on your account. We respond within 30 days, extendable by a further two months for complex requests (Article 12(3)).
- Access (Art. 15) — a copy of the personal data we hold about you.
- Rectification (Art. 16) — correction of inaccurate data.
- Erasure (Art. 17) — deletion, subject to overriding legal-retention obligations such as the 10-year invoice-retention rule under Norwegian bookkeeping law.
- Restriction of processing (Art. 18).
- Data portability (Art. 20) — your evidence records and audit log, exported in a machine-readable form.
- Object (Art. 21) — to processing based on legitimate interest.
- Withdraw consent (Art. 7(3)) — where processing relies on consent, without affecting the lawfulness of processing before withdrawal.
- Lodge a complaint with the Norwegian Data Protection Authority (Datatilsynet — datatilsynet.no) or the supervisory authority where you live or work.
Where Sigill acts as a processor on behalf of a tenant (for example, end users of a customer that uses Sigill.ai to seal documents that include their data), data subjects should direct rights requests to the tenant in the first instance. Sigill will support the tenant in answering the request as required by the Data Processing Agreement.
Automated decision-making
Sigill.ai does not make decisions about individuals using solely automated processing that produces legal or similarly significant effects (Article 22). Plan limits, usage caps, and abuse heuristics are automated controls on the service itself, not decisions about individuals.
Children
Sigill.ai is a B2B platform aimed at organisations and the engineers who build for them. It is not intended for, marketed to, or used by children. We do not knowingly collect personal data from anyone under 16.
Changes to this notice
We update this notice when our processing changes. The version and effective date at the top of the page identify the current text. Material changes that affect a contractual statement, a sub-processor, or a documented retention period are notified by email to the billing contact on each active paid tenant at least 30 days before they take effect.
Contact
Privacy questions, data subject access requests, GDPR queries, and notices about this policy:
| Channel | For |
|---|---|
contact@sigill.ai | Privacy, GDPR, data subject access requests, DPA queries |
security@sigill.ai | Suspected security incident or data breach |
| Sigill AS, Trondheim, Norway | Postal correspondence — write to contact@sigill.ai first for the current address |
Document history
| Version | Date | Change |
|---|---|---|
| v1.0 | 2026-05-23 | Initial publication. |