Trust & governance
Trust & Governance
This page reports the posture visible in the current application code and repository — not a certification or proof of a live deployment. Provider- and engagement-dependent controls are labelled separately.
Control model
The control ledger
Six governance layers, from human accountability to auditable evidence. Each status distinguishes current code, engagement scope, planned work, and independent assurance.
Status key
- Implemented in application code
Present in the current application code; live deployment and provider configuration may differ.
- Engagement-dependent
Available within an engagement's scope or plan.
- Planned
On the roadmap, not yet in place.
- Not yet certified
Practiced, but not independently certified.
- Not publicly disclosed
Shared under NDA during due diligence, not published here.
Layer 01
Human accountability & oversight
A person stays accountable for consequential decisions. Automation never becomes the final authority.
- Engagement-dependentNamed accountability
- Every engagement assigns a human owner accountable for consequential decisions.
- Engagement-dependentAutonomy limits
- Automated systems act within defined boundaries; actions with material impact require human review before execution.
- Engagement-dependentReview gates
- Delivery advances through governed gates — nothing reaches production without a cleared review.
Layer 02
Data boundaries & confidentiality
Where client and customer data may flow — and where it may not.
- Engagement-dependentPayment data isolation
- When the Stripe adapter is configured, payment details are handled by the payment provider; the application stores provider identifiers rather than card details.
- Implemented in application codeRetention windows
- Analytics events 400 days, audit logs 2 years, sent notification bodies 30 days.
- Implemented in application codeRight to erasure
- The deletion route removes application records through database cascades. Identity-provider deletion is a separate documented step; billing cancellation depends on the configured provider.
- Implemented in application codeCookie consent
- A consent banner stores the visitor’s choices locally and gates optional production analytics.
- Engagement-dependentClient confidentiality
- Client material is handled under the confidentiality terms of each engagement.
- Not publicly disclosedInfrastructure topology
- Detailed infrastructure and vendor topology is shared under NDA during due diligence — not published on this page.
Layer 03
Security posture
The technical controls that protect data in transit, at rest, and at the edge.
- Engagement-dependentTransport encryption
- The application defines HSTS and related transport headers; TLS termination and protocol versions depend on the production host.
- Engagement-dependentCredential hashing
- API keys are stored as SHA-256 hashes and the full secret is returned once. User-credential handling depends on the configured identity provider.
- Implemented in application codeSigned webhooks
- Every webhook is verified via HMAC-SHA256 (Svix for Clerk, Stripe signatures, Sanity HMAC) before any payload is parsed.
- Implemented in application codeHardened headers
- HSTS preload, X-Frame-Options, a strict CSP, Referrer-Policy, and Permissions-Policy.
- Implemented in application codeValidated configuration
- Configuration is schema-validated at startup; distributed rate limiting activates when Upstash Redis is configured, with a bounded local fallback otherwise.
Layer 04
Identity & authorization
Who may act — and the limits of what each role may do.
- Engagement-dependentAuthentication
- Authentication can be provided through Clerk; MFA and passkey availability depends on the configured account and plan.
- Engagement-dependentSingle sign-on (SSO)
- Available on Clerk's Organizations plan, scoped to the engagement.
- Implemented in application codeRequest integrity
- CSRF protection via a double-submit cookie plus an HMAC token on every mutating request.
- Implemented in application codeRole-scoped access
- Team-scoped RBAC (OWNER → ADMIN → EDITOR → MEMBER → VIEWER), enforced by server-side session gates.
Layer 05
Validation & independent review
How the system is tested before and after it ships — and what has not yet been independently verified.
- Implemented in application codeContinuous integration
- The repository CI workflow defines type checking, linting, unit tests, and a production build for pull requests targeting main.
- Implemented in application codePerformance & accessibility budgets
- The repository defines Lighthouse thresholds and runs the critical-path Playwright suite in pull-request CI.
- PlannedThird-party penetration test
- Planned before production launch. Not yet performed.
- Not yet certifiedSOC 2 Type II
- On the roadmap. Not yet achieved.
Layer 06
Auditability & evidence
What is recorded, how issues are traced, and the honest maturity of our recovery posture.
- Implemented in application codeAudit trail
- Authentication, billing, API keys, team operations, and webhook receipts are recorded in an audit log.
- Implemented in application codeObservability
- Sentry captures errors when enabled; structured JSON logs run with PII redaction always on.
- Engagement-dependentTraceable delivery evidence
- The retention and handover of delivery evidence is defined per engagement and must be agreed in the delivery plan.
- Engagement-dependentRegulatory alignment
- Applicable GDPR and Saudi PDPL requirements are mapped within each engagement. This is neither legal validation nor third-party certification.
- PlannedRecovery targets (RPO/RTO)
- Documented in the operations runbook, but not yet drilled or certified.
Disclosure integrity
What we do not yet have
- Not yet certifiedSOC 2 Type II
- On the roadmap — not yet achieved.
- PlannedFormal third-party pen test
- Planned before production launch.
- PlannedCertified RPO/RTO
- Documented in the ops runbook, but not yet drilled.
This page is updated the moment any of the above is genuinely earned. We will never claim a control we have not achieved.
Responsible disclosure
Security contact
To report a vulnerability or a security concern, contact security@jtaidigital.com.