Security dossier · DPO intake

Security · DPO intake

What an enterprise DPO reads before signing a Sigil DPA.

The /security page is the document EU enterprise procurement and DPO teams ask for when a Sigil deal lands in security review. Six sections, one screen — SOC 2 posture, a GDPR Art. 28-style Data Processing summary, the sub-processor list with EU/Non-EU classification, EU data residency, encryption posture, and the breach-notification contact. All of it copy/paste-able into a DPA questionnaire or a security-review worksheet.

Issued 2026-08-19 · Quarterly. Last reviewed 2026-08-19; next review Q4 2026.

Section 01

SOC 2 Type II posture

Sigil's first SOC 2 is in flight against the EU production environment. The frame below is the only attestation Sigil currently markets; the row is Placeholder until the CPA-signed report is issued, and procurement must read it as a target — not an active report.

SOC 2 Type II

Scope · Security · Availability · Confidentiality (the Trust Services Criteria Sigil has selected for the first report)

Placeholder

Status

In progress

Timeline

Observation window opens October 2026 against the EU production environment; CPA-signed report expected Q1 2027. The Type I readiness assessment is already closed (no exceptions of substance). The Type II observation is being measurement-tested against the controls listed below; no buyer has yet been sold against a closed attestation.

Trust Services Criteria selected for the first report · Statement of Applicability and risk register available on request under NDA.

Section 02

GDPR Art. 28 Data Processing summary

Plain-prose summary of the controller-to-processor relationship in the Sigil DPA. The binding obligations live in the DPA itself; this section is what a DPO reads before opening the agreement.

Sigil processes tenant data as a processor on behalf of the customer, who remains the controller under the GDPR. The Art. 28-style controller-to-processor relationship is recorded in the Data Processing Agreement (DPA) — this page is the plain-prose summary a DPO reads before signing it.

Sigil processes the theme, template, and CSS source the customer pulls into the platform, the scan output Sigil produces against that source (axe-core diagnostics, criterion tags, evidence hashes), the pull requests Sigil files against the customer repository, and the customer account metadata required to keep the service operating (org name, billing email, seat count, audit log).

Sigil does not process special-category data under Art. 9 — no health, biometric, racial, ethnic, religious, political, trade-union, or sexual-orientation data flows through Sigil in the course of normal operation. If your tenant introduces that data into the source tree you bring into Sigil, it falls outside Sigil’s processing envelope and remains your own controller-side obligation.

Sigil processes the data only on documented instructions from the controller. The scanner runs the criteria the controller has selected (the SIGIL_RULES allowlist in the customer configuration); the PRs file against the controller repository; no Sigil feature reads, indexes, or profiles production traffic of the customer application.

Sigil ensures that persons authorised to process personal data are committed to confidentiality and process it only as instructed. Sigil staff with production access are listed in the staff-access register returned with the procurement pack; quarterly access reviews are recorded against the same register.

Sigil implements the technical and organisational measures summarised in the encryption section of this page and detailed in the SoA. Those measures are reviewed quarterly and material changes are reflected in this page within the same window.

Sigil engages the sub-processors listed on this page only under a written contract that imposes the same data-protection obligations as the DPA and that gives the controller the right to audit the sub-processor. Customers are notified ≥ 30 days before any new sub-processor is added, and may object on reasonable grounds related to data protection.

Section 03

EU data residency

Default region: EU (Frankfurt). Production workload, PostgreSQL primary, encrypted object storage, encrypted backups, and the edge runtime are all sited in Frankfurt (eu-central). On the default EU plan, no tenant-payload traffic leaves the EU region at any tier of the data path.

In-scope data flows

In-scope data path, end to end: HTTP request → edge runtime → app server → Postgres → outbound mail. Every external system named as a sub-processor on this page operates inside the EU on the default plan. Backup artefacts are stored encrypted (AES-256) on EU-resident infrastructure with a 35-day point-in-time retention window.

Section 04

Sub-processor inventory · EU / Non-EU

Every external system that processes tenant or production data on the default EU plan, with each row classified as EU-resident or Non-EU. Customer notified ≥ 30 days before any new sub-processor is added.

List of sub-processors, the data they handle, their processing region, and an EU or Non-EU classification for each.
ProcessorData handledProcessing regionClassification

Polsia (Render hosting)

Application hosting

Application payloads · request logs · Postgres primary · encrypted backupsEU (Frankfurt)
EU

Stripe (billing)

Subscription + invoice billing

Billing metadata · subscription state · invoice totalsEU (Stripe EU)
EU

Email proxy (Polsia)

Transactional mail relay

Email subjects and bodies — transactional only, never marketingEU
EU

Better-auth (Polsia)

Identity and session

Session tokens · identity claims · SSO / SCIM bindings on EnterpriseEU
EU

EU · sub-processor currently processes data inside the European Economic Area. Non-EU · processing region sits outside the EEA on the default plan; flagged here so procurement can record it in the DPA worksheet.

Section 05

Encryption posture

Encryption is enforced at every tier of the Sigil data path. The measures below are the operational baseline; the full Statement of Applicability is returned with the procurement pack under NDA.

In transit

TLS 1.3 on every customer-facing endpoint; HSTS preloaded; AEAD ciphers only (AES-GCM / ChaCha20-Poly1305). Internal east-west traffic between the edge runtime, app server, and Postgres authenticates with mTLS.

At rest

AES-256-GCM on Postgres primary, encrypted object storage, and backups. Encryption keys are scoped per-tenant on Enterprise, never shared between customers.

Key management

Customer-managed keys available on Enterprise via a documented key-handover procedure. Bring-your-own-key flows are logged against the audit-trail entry for the rotation.

The full Statement of Applicability (SoA) and the evidence chain are returned with the procurement pack under NDA.

Section 06

Breach notification contact

The mailbox below is the standing breach-notification contact recorded in the DPA. It is monitored 24×7 by the Sigil security on-call rota; Sev-1 acknowledgement runs against the SLA noted on the card.

DPA-internal mailbox

sigil-szpefu@polsia.app

Sev-1 security incident acknowledgement ≤ 1 hour · 24×7

Send the DPA-internal security contact (controller-side) plus the offer ID / tenant ID. We confirm receipt within the Sev-1 acknowledgement window above; substantive triage follows within 24 hours with the categories of affected data, the affected tenants, and the next-step envelope.

Sister pages

/trust

Procurement-facing view of compliance posture, EU data residency, the sub-processor inventory, and the Enterprise-tier availability + incident-response commitments.

Open /trust

/methodology

The citable artifact EU procurement and counsel read: how Sigil turns source into evidence, files a pull request, and stamps an immutable evidence trail on every commit.

Open /methodology

Bring the questionnaire

Send the security pack, we'll return answers within a business day.

The full sub-processor change log, the encryption SoA, and the EU-enclave network diagram are all returned on request. Drop them into an email and we'll respond with the matching section lined up against your DPA.