Security isn't a dashboard. It's the architecture.
One tenant, one database. Secrets in Azure Key Vault. Audit events that not even an engineer with direct access can alter. The security posture is in the schema, not in a Confluence policy.
What holds the posture up
SOC 2 Type I in progress
Security controls audited by an independent third party. Direct mapping to <code>CC6.1</code>, <code>CC7.2</code>, <code>CC8.1</code>, <code>A1.2</code> and <code>P1/P3</code>. Evidence generated by the system, not by manual screenshots.
Database per tenant
Every customer lives in their own database. No shared rows, no cross-tenant leak risk from a buggy <code>WHERE</code> clause. Customer offboarding drops the database — not a soft-delete.
At rest and in transit
AES-256 at rest on the database; TLS 1.2+ in transit between client, application and SQL. Connection strings and credentials rotated from <code>Key Vault</code> — never in code.
Why history can't be rewritten
Audit evidence lives in two parallel records managed by the SQL engine, not by the application. The principle is simple: a system that trusts application code to block writes is not defensible under SOC 2. An engineer with database access could alter history. We close that door at the engine.
- Temporal tables. Every mutable business entity keeps its own history table in SQL Server. Each UPDATE leaves a row with
ValidFrom/ValidTo. It's transparent to application code. - Append-only
AuditEvents. An append-only table for discrete business events — "invoice posted", "period closed", "permission granted". Theapp_rwprincipal hasDENY UPDATE/DELETE. Onlyaudit_admincan purge. - Audited investigation. Support queries run through
readonly_investigator, a separate principal. Every query is logged toAuditEvents. Nobody looks at the database "on the side".
Your security team will have questions.
We answer your SIG Lite, CAIQ or vendor review questionnaire in a 30-minute meeting, with concrete evidence.