Security

Encryption at rest

All production data volumes — Postgres (Listmonk), MariaDB (Postal), message-body spool, and backup snapshots — are stored on volume-level encrypted block storage (LUKS / provider-side AES-256). Backup objects are additionally encrypted with a key held in the production region before they leave the host, so that the off-site copy is opaque to the backup provider.

Encryption in transit

• Admin panel and APIs — HTTPS with TLS 1.2 minimum, modern cipher suites only, HSTS enabled. We pin to TLS 1.3 where the client supports it.
• Outbound SMTP — opportunistic STARTTLS to recipient mail servers; we honor MTA-STS policies published by recipients and downgrade only when the recipient does not advertise STARTTLS.
• Authentication — every outbound Message is signed with DKIM. We require Customers to publish SPF and DMARC for sending domains before we accept production traffic.
• Operator access — SSH to production hosts uses Ed25519 keys with hardware-token 2FA; password authentication is disabled.

Access control

Splitsoft is single-tenant by design: each Customer deployment has one administrative account. Within a deployment, application credentials (Postal API keys, SMTP credentials) are scoped per Customer organization so that a leaked sub-credential cannot exfiltrate another organization's data. On the Splitsoft side, production access is limited to a small engineering rotation; we maintain documented onboarding and offboarding access reviews and we do not share accounts.

Backup posture

• Daily encrypted snapshots of Postgres and MariaDB volumes.
• Off-site copies in a region matched to the Customer's elected data residency.
• 35-day backup retention; deletions in production propagate within this window.
• Quarterly restore drills with documented success criteria and RTO/RPO measurements.

Incident response

We maintain a documented incident-response runbook and an on-call rotation. For any confirmed breach of personal data, we commit to notifying affected Customers within 24 hours of confirmation — and in any event well within the 72-hour regulatory window in our DPA. Notifications include what we know, what we do not yet know, what we are doing, and what we recommend you do. After material incidents we publish a public postmortem at /postmortems.

Application hardening

• Dependencies tracked and scanned automatically; high-severity advisories patched on a documented SLA.
• Secrets stored in environment variables or sealed secrets — never in source control.
• NextAuth session cookies are HTTP-only, Secure, SameSite=Lax, with rotation on privilege change.
• Input from Customers is treated as untrusted at every boundary — including Listmonk template content, which is rendered in a sandboxed Liquid context.

Reporting a vulnerability

We welcome coordinated disclosure from security researchers. Please send reports to security@splitsoft.com. Encrypt sensitive details with our PGP key (fingerprint published on the same address; ask if you need it).

Our commitment to you:

• Acknowledgement within one business day.
• An initial triage and severity assessment within five business days.
• Status updates at least every two weeks until resolution.
• We will not pursue legal action against researchers acting in good faith — testing only against accounts you own, not exfiltrating data, not degrading service, and giving us reasonable time to fix before public disclosure.
• Public credit on this page (or anonymity, your choice) for valid reports.

We do not currently operate a paid bug-bounty program; if that changes, we will announce it on this page rather than via a third-party platform.

What is out of scope

• Reports that require physical access, social engineering of our staff, or compromise of a researcher's own account.
• Missing security headers on cache-busting marketing pages with no auth surface.
• SPF/DKIM/DMARC findings on domains we don't control.
• Volumetric DoS without a working amplification or asymmetric-cost demonstration.