Skip to main content

Boardroom Answers · Security & Compliance · Security & Cyber Risk

Forget external hackers — your biggest threat is your own people. What stops one of your engineers, or frankly you yourself, from reading my board's data?

The question a Chief Risk Officer (CRO) asks.

The short answer

An insider can't browse casually (CI blocks unscoped queries), can't read the crown jewels without KMS access that's separately logged, and can't cover their tracks — the audit log is append-only and hash-chained. Small-team honesty, cryptographic accountability.

The full executive answer

The uncomfortable honest core first: at our current size, a determined insider with production credentials could access customer data — that is true of every early-stage vendor and of most large ones, and anyone who tells you otherwise is describing controls they don't have. So the real answer is about making access rare, scoped, visible, and non-deniable. Rare: production credentials are held by a very small named set of people — effectively founder-level only today — with MFA enforced. Scoped: day-to-day operations don't use raw database access; the codebase's own CI gate blocks any new privileged query that isn't scoped to a single organisation, so casual cross-tenant browsing has no paved path — an insider would have to deliberately construct raw access outside the application.

Visible and non-deniable is where our architecture does real work: the audit trail is append-only and hash-chained, written via a controlled function — an insider with application-level access cannot read quietly and then scrub the log, because the log physically doesn't support deletion and any tampering breaks the chain mathematically. The most sensitive stored fields carry an additional KMS-managed encryption envelope, so even direct database reads don't yield those plaintexts without separately-logged key-service access. And AWS/Supabase infrastructure access is itself logged on the provider side, outside any insider's reach to clean.

What's roadmapped rather than real: we're a company small enough that "segregation of duties" has limited meaning — you can't two-person-rule a two-person company. The compensating controls are the tamper-evident logging above, plus contractual teeth: our DPA includes confidentiality obligations, audit rights, and breach notification duties that make insider misuse a legal event, not just an HR one. As the team grows, formal access reviews (the scaffolding already exists in the codebase — access-review tooling is a platform feature we build for customers) and just-in-time production access are the first hires' first controls, tracked in the SOC 2 readiness plan.

Grounded in: NIST SP 800-53 AU-9/AC-6 (audit protection, least privilege); SOC 2 TSC CC6.2/CC6.3; ISO 27001 A.5.3 (segregation of duties) — honestly flagged as size-constrained.

Want this answered live, on your data?