How we handle your data.

Security philosophy

We hold our own platform to the same standard we advise clients toward: controls that are real and verified, described in precise language, not aspirational marketing. Where a control is fully built, we say so. Where it is designed but not yet tested, or not yet built, we say that too — including on this page.

Infrastructure

The platform is built as serverless functions in front of a managed PostgreSQL database (Supabase), with static hosting and function execution through Netlify. There is no long-running application server to patch or lose track of — every request runs a short-lived, purpose-built function. HTTPS is enforced site-wide.

Data we collect and data protection

We collect the information you provide through our contact form, booking widget, our six free assessments, and — for clients — the client portal. Full detail: our Privacy Policy. We do not sell this information or share it with advertisers. Data is classified by sensitivity (public, internal, confidential, and restricted for the most sensitive items such as financial exposure figures and compliance evidence), with handling discipline that scales accordingly.

Access control

Access follows a defined set of roles — from administrator down to read-only — and is scoped to the consultants actually assigned to a given engagement. Client-side users, where enabled, can see only their own organization's data. A change to someone's access takes effect immediately, on their very next request; nothing is cached against a stale permission.

Authentication

Every member of our team is required to use multi-factor authentication (a time-based one-time code in addition to a passwordless email sign-in) — there is no exception and no way for an account to opt out. Sessions are carried in a cookie that JavaScript cannot read, expire automatically after 8 hours regardless of activity, and repeated failed sign-in attempts from the same source are throttled.

Client isolation

In a platform that serves multiple client organizations at once, keeping one client's data invisible to another is a foundational requirement, not a feature. That separation is enforced at the database layer itself — not only in application code — so that even a bug in our own application software cannot expose data our access rules would otherwise block. This has been proven with automated tests that attempt exactly the kind of cross-client access a real attacker or a coding mistake could otherwise cause, run directly against the database.

Encryption

Data in transit is encrypted via HTTPS across the entire platform. Data at rest relies on our database provider's underlying infrastructure encryption; we have not independently layered additional at-rest encryption beyond the provider default, and we say so here rather than implying a stronger control than exists.

Logging

Every authentication event and every data-changing action taken by our staff is recorded to an audit log with no path — for anyone, including administrators — to edit or delete an entry after the fact. This log is retained for one year and then automatically deleted on a fixed schedule. Routine read-only access is not separately logged today; we name this as a known gap rather than leaving it undisclosed.

Protecting our public forms

Our contact form, booking widget, and assessments are protected against automated abuse and flooding, and enforce a maximum submission size — so a slow or malicious script can't degrade the experience for real visitors. If our systems are ever briefly unreachable, a completed assessment or inquiry is never silently lost.

Vulnerability management

We monitor our software dependencies for known vulnerabilities and remediate meaningful findings — for example, we identified and fixed a set of high-severity vulnerabilities in an email-sending library we depend on, verifying our actual exposure against the real code before treating it as resolved, rather than reacting to the headline alone. We do not yet run continuous automated dependency scanning or a third-party penetration test; both are documented next steps, not claimed completions.

Application security controls

The site and applications set a Content Security Policy and related browser security headers, scoped to how sensitive each area is: the public marketing site's policy is permissive only for the fonts and analytics it actually loads, the client portal's is tighter, and the staff CRM's is the strictest — no inline scripts, a locked-down default policy, X-Frame-Options: DENY so it can't be framed by another site, and responses marked not to be cached or indexed. Session cookies are never readable by JavaScript and are only ever sent back to our own site (they carry SameSite=Strict), which is also what stops a malicious third-party page from forging a request using your session. Repeated failed sign-in attempts, and AI-assisted actions specifically, are both rate-limited.

Incident response

We maintain an internal incident response runbook describing how we detect, contain, and recover from a range of scenarios — from a database or hosting outage to a compromised staff credential. This plan has not yet been exercised through a live drill.

Business continuity

We've identified which of our vendor dependencies are genuine single points of failure versus ones our platform degrades gracefully without, and we prioritize recovery accordingly if something goes wrong — client-facing access to their own engagement data comes first. As with incident response, this plan is documented and has not yet been proven against a real outage.

Privacy

Our full Privacy Policy is the authoritative statement of what we collect, why, and your rights: privacy.html. Analytics on this site are anonymous and only load after you've given consent — no visitor data is sold or shared with advertisers.

Responsible disclosure

If you believe you've found a security issue affecting this website or its public forms, please tell us before disclosing it publicly. In scope: this website and its public-facing forms. Out of scope: third-party services we depend on (please report those directly to the vendor), and any destructive testing against production. We don't yet operate a paid bug-bounty program — this is a responsible-disclosure channel, and we'll acknowledge a good-faith report.

Security contact

Reach us through our contact form for any security question, disclosure report, or data-handling request.

What we can't yet claim

We believe in describing our security posture accurately rather than overstating it. As of this writing: our backup and disaster-recovery process has not yet been independently tested end-to-end, we have not undergone a third-party penetration test, we do not run continuous automated vulnerability scanning, and we do not hold a formal third-party security certification (such as SOC 2 or ISO 27001).

Important disclaimers

Content on this site — including our assessments, guides, and framework descriptions — paraphrases common practice and referenced frameworks for general guidance. It is not legal advice, does not constitute an audit, and does not replace an independent auditor's or certification body's judgment. Illustrative examples (such as the Quantified Risk example shown on this site) are for demonstration only and are not claims about actual client outcomes or empirical statistics. See also our Assessment Disclaimer and AI Disclaimer.