Boring security choices. Documented, not implied.

Tenant isolation ​

Every multi-tenant table has an org_id column and a database-enforced policy that filters every query by it. Application code sets the active organisation as a session variable; the database refuses to return cross-tenant rows even if the application code has a bug.

This is different from the "we'll filter in the WHERE clause" approach common in early-stage RMMs, where one missed WHERE org_id = ? is a cross-tenant leak.

Secrets & encryption ​

Encrypted at rest, not plaintext columns.

• Sensitive secrets (API keys, integration tokens, agent registration secrets) are encrypted at rest with AES-256-GCM.
• The encryption key is derived (HKDF-SHA256) from a master key loaded into the application at process boot.
• The master key lives outside the application database — a database dump alone is not enough to read secrets.

Master-key rotation tooling, and an envelope scheme with independently-rotatable per-row data keys, are on the post-beta hardening backlog. We've documented it openly because we'd rather ship the rotation right than ship it now.

Authentication & authorisation ​

• Operator login with email + password + TOTP MFA. WebAuthn on the roadmap.
• Role-based access control with permission constants checked at the API layer.
• Permission backfill migrations for every new role-bearing feature — no silent 403s when you upgrade.
• Audit log of consequential actions (asset deletion, invoice void, role changes, secret reads) with operator + IP + timestamp.

Agent trust model ​

Per-agent credentials, not shared secrets. At registration each agent generates its own cryptographic identity (its own public/private keypair) and is issued a unique, subject-scoped credential on the message bus — so an agent can only publish and subscribe on the subjects belonging to its own tenant. The trust database stores each agent's public identity. Agent-to-server traffic flows over a TLS-encrypted message bus.

Registration tokens authorise onboarding and can be single-use or shared for mass deployment; the per-agent identity is minted during registration, not carried in the token. Per-agent message-bus credentials are live across the entire fleet.

Where your data lives ​

OpsMerge is built and run from the UK. All customer data is hosted inside the European Economic Area, and we publish exactly where:

• Application and database: dedicated infrastructure in Helsinki, Finland. Account data and agent telemetry live here.
• Object storage: ticket attachments, documents and uploaded files on an EU endpoint in Amsterdam, Netherlands.
• Backups: encrypted with AES-256 before they leave the application server, then stored in Finland.
• Email: platform notices go out via a transactional email provider under Standard Contractual Clauses; ticket email runs through the Microsoft 365 mailbox you attach, inside your own Microsoft tenancy.

Processing is protected by the UK GDPR and the Data Protection Act 2018, and, because hosting sits inside the EEA, by the EU GDPR as well. All traffic is encrypted in transit with TLS 1.2 or higher.

A managed edge / DDoS layer fronts the public-facing surface but does not store application data at rest. First-party, EU-hosted product analytics — no Google Analytics, no Segment, no Mixpanel. Sub-processor names and locations are listed in our Privacy Policy — we keep that as the single source of truth so it stays in sync with our DPA.

PCI scope ​

We never see card data. Card payments are handled by a PCI-DSS Level 1 processor via hosted checkout sessions and payment links. The card flow happens entirely on the processor's domain. OpsMerge stores customer IDs and payment status — never PANs, never CVVs.

Compliance posture ​

• UK GDPR & EU GDPR — data controller established in the UK, all customer data hosted in the EEA, DPA available on request.
• SOC 2 Type 1 — not yet. Roadmap item once revenue justifies the audit cost. We'd rather build the controls before paying for the certificate.
• Cyber Essentials Plus — Brindleford Technologies application in progress.
• ISO 27001 — long-term, post-GA.

We're being explicit because "SOC 2 ready" without an actual report is meaningless and we'd rather not pretend.

Vulnerability disclosure ​

Email [email protected]. We acknowledge within 48 hours UK business time. No bug-bounty programme yet — we'll pay for severity-significant reports informally during beta and formalise post-GA.