Trust
Security posture, stated plainly enough to be checked.
This page describes design requirements to discuss, not universally verified controls or a certification. Implemented controls, test results and independent assessments need dated evidence for the exact product and scope.
Controls
Designed in, not added later.
Row-level authorisation
Correctly configured and tested row-level policies can restrict ordinary client access. Server-side authorization and tenant-specific negative tests are required; privileged credentials or service roles may bypass policies and need separate protection.
Secret handling
Server-only privileged secrets, least-privilege service identities and a reviewed rotation process are design requirements. Evidence must be checked for each implementation.
Role separation
Separate protected roles from user-editable profiles; verify authorization server-side. Actual role and permission boundaries require scoped tests.
Evidence by default
Agree attributable action records, approval evidence, redaction and retention. Log presence alone is not proof of immutable history or compliant operations.
Operational hardening
Plan least-privilege accounts, test/production separation, dependency checks, monitoring and incident ownership; verify them before claiming operational assurance.
Procurement support
Security questionnaires, DPAs, architecture diagrams and control mappings can be scoped as part of delivery, subject to the agreed engagement.
Frameworks
Requirements to review for the agreed scope.
NIST SP 800-171 / CMMC
Enclave design, controlled-information boundaries and workflow evidence for defense-supply-chain platforms.
SOC 2
Control design and evidence generation supporting a Type II programme run by the client and their auditor.
HIPAA
PHI segregation, minimum-necessary access patterns and recorded disclosure paths in healthcare workflows.
GDPR / PIPEDA
Lawful-basis modelling, retention rules and subject-request paths designed into the data model rather than bolted on.
Being able to build to a framework is not the same as being certified against it. We distinguish which applies to each scoped claim, in writing, before it is presented for independent review.
Reporting
Found something?
If you believe you have found a vulnerability in this site or in a platform we operate, use the contact form and mark it as a security report. Do not include secrets, exploit payloads or customer records in the initial report. An approved reporting policy and response window are not established by this page.
Vendor review
Send the questionnaire before the kickoff, not after.
Security review is treated as part of delivery. Share your requirements early and they shape the architecture rather than delaying it.