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 detached seals only, the
.p7s(CAdES) or.jades.json(JAdES) signature. You can turn both off and the row will hold the hash and metadata only. - Our MCP server (for AI assistants and agents) has no document upload or download capability. Its tools take and return hashes, evidence tokens (timestamp tokens and detached signatures) and ordinary text arguments such as labels and tags; documents are hashed on your side before anything reaches Sigill.
- 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, organisation number 937 798 970, with registered office at Arne Garborgs veg 21, 7071 Trondheim, Norway. 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) or JAdES detached signature (.jades.json), 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 sealing only — PDF upload via /seal/sign) | Processed in memory only to produce the PAdES signature, then discarded with the response. Not persisted. CAdES and JAdES sealing use /seal/sign-hash and receive only a SHA-256 digest — the file never reaches our servers. | Performance of a contract (Art. 6(1)(b)) | Not retained — the bytes do not outlive the HTTP request |
Sealed output bytes (PAdES PDF, CAdES .p7s, or JAdES .jades.json) 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 |
| Connected apps (AI assistants connected through MCP sign-in): your user id, organisation id, the app name as provided by the app, the permissions you granted, when you connected and when the connection last refreshed, and hashed (never plain) connection tokens | Letting an assistant you connected act for you in your organisation, and showing and revoking connections under Settings → Connected apps. Owners can see members' connections. | Performance of a contract (Art. 6(1)(b)) | While the connection is active; deleted 30 days after it is disconnected or expires (it expires after 30 days without use). A password reset disconnects all of your connected apps. |
Verification (PAdES, CAdES, JAdES, 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). Source networks are stored masked to /24; the one exception is confirmed-abuse events (failed logins, failed bot-checks, rate-limit blocks), where the exact source IP is kept so we can block the actor. | 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. Exact abuse-event source IPs are scrubbed after 90 days regardless of plan. Pruned automatically. Exception: evidence-lifecycle events (reminder changes, risk acknowledgements, archive/restore, tags, verification runs) form each evidence's chain of custody and are kept for the life of the evidence; they contain record identifiers and the acting user, never addresses or source networks. |
| 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 detached seals only) the
.p7s(CAdES) or.jades.json(JAdES) signature, 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. The Model Context Protocol integration has no document upload or download capability in either direction: its tools work on hashes, evidence tokens (timestamp tokens and detached signatures) and ordinary text arguments, and there are no upload or download slots. Sealing or verifying a whole document goes through the web app, the HTTP API or the SDKs.
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 and the sign-up page, 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. It is not loaded on sign-in or elsewhere in the authenticated application.
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 · 937 798 970 · Arne Garborgs veg 21, 7071 Trondheim, Norway | Postal correspondence |
Document history
| Version | Date | Change |
|---|---|---|
| v1.2 | 2026-10-02 | Adds Connected apps: AI assistants (ChatGPT, Claude) connected through MCP sign-in, with what is stored and for how long. |
| v1.1 | 2026-10-01 | MCP server no longer offers temporary document upload/download slots; the corresponding retention entry is removed. |
| v1.0 | 2026-05-23 | Initial publication. |