Security

Where is my data stored?

All servers, object storage, and backups are in EU regions of Hetzner Cloud (Falkenstein, Germany, or Helsinki, Finland). No tenant data leaves the EU.

How are workspaces isolated?

Every tenant table carries a workspace id and PostgreSQL Row Level Security is forced on it. The application's database role cannot bypass those policies, and a request without a workspace context reads nothing and writes nothing. Foreign keys are composite with the workspace id, so a reference can never point into another workspace. Cross-workspace reads exist only as fixed, audited platform functions that the application role cannot execute.

How do users log in?

Passwords

Following NIST 800-63B: minimum length, a check against known breached passwords (only a partial hash leaves SAQ), no composition rules. Hashed at rest.

Passkeys and two-factor

Passkeys (WebAuthn) and time-based one-time codes with recovery codes. Two-factor login is required for workspace owners and admins and for platform operators, and offered to everyone else.

Magic links

For regular client users: single use, 15-minute validity, 24-hour sessions. Disabled for an identity as soon as it has a password or SSO login.

Single sign-on

OpenID Connect with a Microsoft Entra ID preset, claim mapping, and an MFA assurance rule. A workspace can verify its email domains by DNS and force SSO for them, enforced at the workspace boundary. SCIM 2.0 provisions users and groups. Single sign-on, verified domains, and SCIM are included from the Business plan; the trial includes them.

Sessions

Server-side session rows with the authentication method, time, and MFA state. Sensitive actions (mailbox credentials, billing runs, period close, deleting the workspace, minting API keys) require re-authentication within the last ten minutes. Sessions are listed and revocable by the user.

API keys

Hashed at rest, shown once, scoped, with optional expiry and network restriction, checked on every call against the grantor's current permissions.

Is data encrypted?

TLS for everything in transit. Mailbox credentials and identity-provider secrets are encrypted at rest with AES-256-GCM, bound to the workspace they belong to. Tokens are stored as hashes.

How are backups and recovery handled?

Continuous write-ahead-log archiving with a weekly full and daily incremental backup to a separate, versioned object storage repository that only the backup process can reach, with 30-day retention. The recovery point objective is five minutes and the recovery time objective four hours, with an alert if the archive falls behind. Restore drills, covering database, object storage, and keys on a fresh machine, are scheduled quarterly and their results logged. Deletions and redactions are replayed on top of a restore before the data is served, so a restore never resurrects what a customer removed.

What is audited?

Every privileged action writes an append-only audit row with actor, on-behalf-of, action, target, and reason. That includes operator impersonation and cross-tenant reads, viewer grants, billing runs and voids, period close, member changes, and authentication settings. Workspace owners and admins see their workspace's log under Settings → Audit. Descriptive payloads are stored separately from the structural row so they can be purged in a redaction without breaking the trail.

How is the application itself protected?

• A strict Content Security Policy without inline scripts, HSTS, and no third-party resources
• Origin checks on every state-changing request; no CSRF token cookie to leak
• Rate limits per address, per identity, and per API key, including on login and magic-link issuance
• Uploads quarantined until type sniffing and size checks pass; never served inline as HTML or SVG
• Markdown and inbound email HTML sanitized with an allowlist; remote images blocked
• PDF rendering in a sandbox with JavaScript off and no network access
• Ingest logs never contain email subjects, bodies, sender addresses, or attachment names
• Log labels never contain tenant identifiers; tenant metadata in logs is a platform privilege

How are vulnerabilities managed?

Dependency, secret, container, configuration, and static analysis scans run on every change (Trivy and Opengrep) alongside lint, type checks, unit and integration tests, browser tests with accessibility checks, and Lighthouse. Nothing ships with a HIGH or CRITICAL finding. Packages younger than five days are not installed, to limit exposure to supply-chain attacks. Images are pinned by digest and signed; a deployment verifies the signature before rolling out. OWASP ASVS level 2 is the reference standard.

Is SAQ certified (ISO 27001, SOC 2)?

No. SAQ is built to the OWASP Application Security Verification Standard level 2 as its reference, with automated checks in every release, and this page describes the controls. We do not hold a formal certification today.

Where does SAQ stand on GDPR?

ArktIQ IT AS is the processor for everything a customer puts into a workspace, and the controller only for its own customer relationship. The data processing agreement is written to GDPR Article 28 and comes with every subscription rather than having to be requested. It binds all processing to the EU, lists every sub-processor and gives 30 days' notice before one changes, and commits us to notifying the workspace owners without undue delay in the event of a personal data breach. Customers can answer most data subject requests themselves, since owners and admins can view, correct, delete, redact, and export without going through us; where the tools fall short, we do the work on the customer's instruction. The privacy policy describes what we process as controller, on what basis, and for how long.

What is the customer's responsibility, and what is ours?

The customer decides which tickets get created, which clients and staff are entered, and how long it all stays there. Whoever decides the purpose and the means is the controller under GDPR Article 4(7), which is why it is the customer who answers to the supervisory authority and to the individuals concerned. We process only what we are instructed to process, and we answer neither data subjects nor regulators on the customer's behalf unless asked to.

The customer still has to have a lawful basis for what goes in, keep their own record of processing activities, respond to data subject requests, and notify the supervisory authority within 72 hours when a breach calls for it. Our part is to make that possible: export and deletion of a whole workspace, redaction and pseudonymisation of individuals, an audit trail the owner can read directly, notification to the owners without undue delay if something happens at our end, and a sub-processor list that does not change without 30 days' notice. No supplier can make a customer compliant on its own; what we can do is make sure the tools and the paperwork are there when they are needed.

Who at ArktIQ can see what?

Platform staff are not workspace members unless invited. The operator console runs on a private listener, not on the public address, and requires password plus a one-time code. Reading a workspace from it is read-only by default, requires re-authentication within ten minutes, shows a banner, expires, cannot mint tokens or change mailbox credentials, and is written to the audit log with a reason.

Does SAQ track its users?

No. There is no analytics, no advertising, and no third-party script on the public site or in the app. The public site sets no cookies; the app sets only the cookies needed to keep you logged in and remember your language, workspace, and theme.

How do I get my data out, or delete it?

A workspace owner exports the entire workspace as a package of newline-delimited JSON with every attachment and document, at most once an hour. An owner who has taken an export within the last hour can schedule deletion; the workspace is read-only and restorable for 30 days, then everything is purged, including backups as they age out under their 30-day retention. A person can delete their own global identity from Account → Security; their workspace-local records are pseudonymized so that ticket history stays coherent.

How do I report a security issue?

Email with the details. We acknowledge reports within two working days and do not pursue good-faith researchers.

FAQ

Security questions

Does our data leave the EU?

No. Servers, files, and backups are on Hetzner Cloud in Germany or Finland, and nothing moves outside. The hosting section above names the regions.

Can one client see another client's tickets?

No. Workspaces are separated in the database itself, not only in the application, and a request without a workspace behind it gets nothing back. The isolation section above explains how that is enforced.

What happens if something goes wrong at your end?

The target is to lose at most five minutes of work and to be running again within four hours. Backups are continuous, and we rehearse recovery every quarter. The backup section above describes the routine.

Can we require everyone here to log in with their work account?

Yes. A workspace can verify its own email domains and force single sign-on for them, against Microsoft Entra ID or another OIDC provider. The login section above covers the other methods.

Do we need a cookie consent banner to use SAQ?

No. There is no analytics, no advertising, and no third-party script, and the app sets only the cookies needed to keep you logged in. The tracking section above says what is set.

Is SAQ GDPR compliant?

Yes. ArktIQ is the processor for what goes into your workspace, all processing happens in the EU, and the Article 28 data processing agreement comes with the subscription without your having to ask for it. The GDPR section above says what it commits us to.

Do you have documentation we can use in a procurement process?

This page, the privacy policy, and the data processing agreement cover most of what gets asked. SAQ holds no ISO 27001 or SOC 2 certification today; the certification section above says what we build to instead.