Security without the questionnaire dread

Security reviews stall deals. The questionnaire arrives — three hundred rows of yes/no/explain — the answers require engineering time nobody scheduled, and weeks pass while a champion who already wants to buy waits for their security team to sign off. The fix isn't a better sales deck or a slicker trust page. It's controls built in from the start, so the honest answer to every question is 'yes, and here's where to verify it.'

Isolation at the database

Postgres Row-Level Security isolates every workspace at the data layer. Each query runs in a tenant context, and the database itself refuses to return rows that belong to another workspace. Application bugs can't cross tenant boundaries because the database enforces the boundary, not the app code. That's a fundamentally stronger guarantee than app-level checks, where a single forgotten WHERE workspace_id = ? is a cross-tenant leak waiting to happen.

The distinction matters to a reviewer who's seen how breaches actually occur. Most tenant-isolation failures aren't exotic — they're a missing filter on a new endpoint that someone shipped in a hurry. RLS makes that class of bug impossible by construction: the new endpoint inherits the boundary whether the author remembered it or not. 'Enforced by the database' is a sentence that ends a lot of follow-up questions.

The controls reviewers expect

SSO/SAML so identity lives in the customer's IdP and offboarding is one action in one place. SCIM provisioning so access is granted and revoked automatically as the directory changes, instead of a quarterly access review nobody enjoys. An immutable audit log that records who did what and when, in an append-only trail a reviewer can inspect. Signed webhooks so downstream systems can verify a payload genuinely came from us. Encrypted OAuth tokens at rest so a database snapshot isn't a credential dump.

None of these is exotic. They're the standard table stakes of selling to a company with a security function — and that's exactly the point. When the controls are the ones reviewers already expect, and the answers are ready before they ask, the questionnaire stops being a negotiation. It becomes a checklist someone runs down and signs.

The audit log is the answer to most questions

If you build one control well, build the audit log. An immutable, append-only record of who did what and when is the single artifact that answers the largest share of a security questionnaire, because almost every question underneath the surface is really 'and how would you know?' How would you know if an admin exported the data? If a permission changed? If someone accessed a record they shouldn't have? Without an audit trail, the honest answer is 'we wouldn't,' and that answer fails reviews. With one, the answer is 'it's recorded, here's the schema, here's how you'd query it.'

The discipline is making it genuinely immutable and genuinely complete. A log that the application can edit isn't evidence — it's a suggestion. A log that records the easy events and silently skips the sensitive ones is worse than none, because it implies coverage it doesn't have. Every privileged action writes a row, the rows can't be altered after the fact, and the trail is the same one your own operations and agent tooling write to, so there's exactly one place to look. Reviewers trust a system that can't lie to itself.

Defense in depth, because one layer fails

No single control is the answer, because every single control eventually has a bad day. RLS is a strong boundary, but you still scope queries in the application so a misconfiguration isn't a single point of failure. Tokens are encrypted at rest, but you also rotate them and scope them narrowly so a leak is contained rather than catastrophic. The mindset a good reviewer is testing for isn't 'do you have the controls' — it's 'do you assume each of them will fail, and what catches it when it does.' A vendor who can describe their second line of defense for each risk is a vendor whose first line is probably real too.

That layered posture is also what makes the review fast, oddly enough. A reviewer who hears 'we enforce it here, and we also catch it here if that fails' stops digging, because they've found the depth they were probing for. A reviewer who hears a single confident 'we handle that' for everything keeps digging, because confidence without depth is exactly what they're trained to distrust. Layers don't just make you safer. They make you legible.

The payoff is speed, not just safety

Teams treat security as a tax on velocity — the thing you bolt on before a big deal, grudgingly, late. Built in from the start, it's the opposite: it's what lets a deal close in days instead of months. The questionnaire comes back in a day because the answers were true before the question was asked, and the champion who wanted to buy doesn't lose momentum waiting on their own security team. Security done early is a sales accelerant disguised as a compliance chore.