We made our security design choices before we had a customer¶
Corrected 27 September 2026: the statements below on cryptography and encryption now say exactly what production runs; so do the ones on isolation and the network.
Security posture in a young software company usually arrives in a particular order. First the product, then the customers, then the enterprise buyer who sends a 300-question spreadsheet, then the engineer whose job for the next two quarters is to make the answers true. Logging gets extended to cover what the framework asks for, and a supply-chain story is assembled from whatever the build pipeline happened to do.
That order is rational for most products. It is the wrong order for ours. Kanonik exists to produce a record that an auditor can trust. A product like that cannot have a security posture it added later; the posture is the product. So we build Kanonik to NIST SP 800-53, the control set FedRAMP is built on. We started from the first commit.
What that means in practice¶
Cryptography first. Our Go services use Go's FIPS 140-3 module, in FIPS mode. Our key vault and sign-in service are separate products, and we make no FIPS claim for them. Approval tokens (ECDSA P-256) and chain-head signatures (ECDSA P-384) are signed inside our key vault; the private keys are not exported to our services.
Audit logging is aligned to NIST 800-53 from the start. Every action that touches a tenant's record produces a structured event with the actor, the tenant, a trace identifier, and the outcome. The database rejects edits and deletes of audit entries, and any change made around that protection would break the signed hash chain and show up when the export is verified.
Every container image is signed before release and carries a software bill of materials. Vulnerability scanning runs on the source and on the image, and a high-severity finding blocks the merge rather than filing a ticket. Infrastructure is defined as code and deployed through a GitOps pipeline.
Every workspace's records carry a workspace id. Postgres row-level security is forced on the core record tables (events, entities, tenant settings), and the application checks the workspace on every request; some approval-workflow tables are isolated in application code only. Your data is encrypted at rest by our cloud provider (Oracle Cloud block storage, AES-256). Each workspace also has its own key in our vault; today it encrypts personal contact fields such as the owner's email and approval-channel addresses.
The system boundary is one boundary. Three services, one deployment, one set of network controls. Our application services talk to each other over mutual TLS and to the database over TLS. Calls to the key vault and the sign-in service stay on the private cluster network behind network policies but are not yet encrypted.
Built in from day one¶
None of it was added for a questionnaire. It is the architecture, and every plan gets the same one.
Why it matters to you¶
Most teams that buy Kanonik will need SOC 2, or ISO 27001, or a bank's vendor questionnaire. Building to NIST SP 800-53 makes those questions easier to answer: what crypto, what logging, what isolation, what supply-chain controls, who can touch production.
When a compliance product cannot answer those questions well about itself, its customers should wonder what else it has deferred.
Kanonik is security compliance software: one record for your questionnaires, audits and live assurance. Read how we handle your data, then start your 14-day trial.