Standards.
This page is the honest list of what CJI aligns with, what we do not yet hold, and what we will not do. It is written for bank IT reviewers, URL-filter analysts, and security-conscious partners evaluating the service before granting network access.
UK GDPR and the Data Protection Act 2018.
Data controller
CJI is an independent market-research publication operating from the United Kingdom. For the purpose of UK GDPR, the data controller is the publisher of cjipro.com, contactable at [email protected]. The full privacy notice — including lawful bases, retention periods, and your data-subject rights — is at /privacy/.
What we collect and what we do not
- The public surface at cjipro.com collects no personal data. No analytics, no cookies, no tracking pixels.
- The alpha briefing surface processes a named email address for the sole purpose of authorisation. No other personal data is collected from partners.
- Authentication events are recorded in an append-only audit log. PII fields (IP address, user agent, JWT subject) are hashed with daily-rotating salts — not stored in plaintext — so the log cannot be used to re-identify individuals.
- Public-signal briefings quote verbatim customer feedback from public platforms (app stores, forums, press). Attribution is platform and date only. We do not attempt to identify the individuals who wrote them.
- CJI Pulse — the product that would process internal firm telemetry — does not currently process any real customer data. A DPIA is a prerequisite for that activation.
RFC 9116.
Contact and process
Our machine-readable disclosure file is at /.well-known/security.txt, conforming to RFC 9116. The preferred contact is [email protected].
We acknowledge vulnerability reports within 5 business days. We operate a 90-day responsible disclosure policy, with possible extension upon written agreement: researchers are asked to give us a reasonable window to investigate and remediate before publishing, and we hold ourselves to the same window before any disclosed issue ages out. We will not pursue legal action against researchers who follow responsible disclosure practice and do not exfiltrate data or disrupt service.
We have no bug-bounty programme at this stage. We will credit researchers publicly if they wish.
How access to the briefing surface works.
Magic-link email authentication
The alpha briefing surface uses WorkOS AuthKit to issue magic-link authentication emails. A partner requests access, receives a one-time link by email, and exchanges it for a short-lived session. There are no passwords on record anywhere in the system.
SMS multi-factor authentication is explicitly excluded from the design. SIM-swap is a well-documented attack class in regulated-firm environments; email-only authentication eliminates that surface. Passkeys (TouchID / FaceID via WebAuthn) are preferred as an additional factor and are managed through the WorkOS-backed flow.
Allowlist gate and principle of least privilege
Every partner email address must be explicitly approved by an administrator before it can access any authenticated surface. Self-service signup requests enter a pending queue; approval is a manual per-account decision. Accounts can be revoked individually at any time, which immediately invalidates any active session for that account.
All administrative actions — approval, denial, revocation, force sign-out — are recorded in the immutable audit log with the acting administrator's account and timestamp.
Session and token design
Sessions are tracked in a server-side table. The session cookie is named
__Secure-cjipro-session, scoped to .cjipro.com,
SameSite=Lax, Secure flag set. JWTs carry a short expiry; the edge bouncer
validates them on every request before passing traffic to the origin.
Session activity is recorded so administrators can see when each account
was last active and force sign-out remotely.
Infrastructure and headers.
Cloudflare-fronted hosting
All traffic to cjipro.com and login.cjipro.com is routed through Cloudflare. TLS termination, DDoS mitigation, and WAF rate-limiting rules run at the Cloudflare edge before any request reaches the origin. The public site is served from GitHub Pages; the authenticated surface runs on Cloudflare Workers.
TLS 1.3 is enforced at the Cloudflare edge. The current public-cert chain targets SSL Labs grade A+; we monitor this on every deployment. HTTP Strict Transport Security (HSTS) and full HTTP-header delivery for the marketing surface are scheduled for Q2 2026 alongside the migration described under Security header delivery below.
Inbound email for [email protected] and [email protected] is handled by Cloudflare Email Routing. SPF, DKIM, and MX records are configured and maintained by Cloudflare.
Security headers on every page
Every page on the public surface carries the following meta-equivalent security headers:
- Content-Security-Policy — restricts resource loading to self + inline styles. No external scripts loaded from the public surface.
- X-Content-Type-Options: nosniff — prevents MIME-type sniffing.
- Referrer-Policy: strict-origin-when-cross-origin — limits referrer leakage.
- Permissions-Policy — camera, microphone, geolocation, payment, and USB access all denied.
- Session cookie: SameSite=Lax + Secure + HttpOnly +
__Secure-prefix.
Security header delivery — current state and roadmap
Security headers on the marketing surface (cjipro.com) are currently
delivered via <meta http-equiv> tags due to static
hosting constraints — the public surface is served from GitHub Pages
behind Cloudflare. All authenticated surfaces (app.cjipro.com and
login.cjipro.com) and API traffic are served through Cloudflare
Workers and use proper HTTP response headers. We are migrating
marketing pages to Worker delivery in Q2 2026 for full header
consistency.
The practical effect for an IT reviewer running curl -I
against cjipro.com today: the GitHub Pages headers appear in transit,
but the security policies are parsed by the browser from the
in-document meta tags. The policies are enforced; the
delivery channel for the marketing surface is on the roadmap.
Authenticated surfaces already serve real HTTP headers.
The audit log.
Hash-chained immutable audit log
All authentication events — login, approval, denial, revocation, force
sign-out, webhook receipt, admin action — are recorded in an append-only
D1 table. Each row carries a prev_hash field that references
the SHA-256 hash of the previous row. Tampering with any row invalidates
all subsequent rows; the chain can be verified programmatically using the
verifier CLI that ships with the audit package.
PII fields — IP address, user agent, JWT subject — are not stored in plaintext. Each is hashed as SHA-256(value ‖ daily_salt), where the daily salt rotates at midnight UTC and is stored separately. If the audit log rows are obtained without the salt table, PII is not recoverable.
Per-tenant audit export
Partners can request a download of their own authentication events via the admin interface. Exports are available as JSONL (one event per line, suitable for SIEM ingest) or CSV. Internal hash columns are excluded from all exports — the chain-integrity fields are for our internal verification, not for onward processing.
The export endpoint requires admin authentication and records the export action itself in the audit log.
What we do not yet hold.
These certifications and assessments are on the roadmap. We are pursuing them concurrently with the alpha cohort, not as a precondition for it. This section exists because we believe the absence of a certification is at least as important to disclose as its presence.
- Planned SOC 2 Type 1 — readiness assessment underway; an independent auditor has not yet been engaged. The controls described on these pages are designed with SOC 2 Trust Service Criteria in mind. We will not claim SOC 2 compliance until the report is issued.
- Evaluating ISO 27001 — under evaluation. We operate an ISMS consistent with ISO 27001 intent and are currently assessing the path to accredited certification.
- Evaluating Cyber Essentials Plus — under evaluation. UK-government-backed scheme; we are assessing scope and timing for assessment.
- Planned Formal penetration test — by a named third-party security firm. Planned before the first enterprise contract. We are not aware of any open vulnerabilities in the current production stack but we have not commissioned an independent assessment.
- Out of scope HIPAA — not applicable. CJI processes no health data.
- Out of scope PCI DSS — not applicable. CJI handles no payment card data.
- Pending DPIA — a Data Protection Impact Assessment is a prerequisite before any live internal customer data is processed. CJI Pulse does not currently process real customer data. The DPIA will be completed and documented before that capability activates.
If the absence of any of these items is a blocker for your organisation, contact us at [email protected]. We will be direct about the timeline.
What we will not do.
These are explicit commitments, not aspirational goals. Where a technical control enforces the commitment, we say so.
- Never No SMS MFA. SIM-swap is a documented attack class in banking and regulated-firm environments. SMS multi-factor authentication is excluded from the design. Email-only authentication plus passkeys is the chosen model.
- Never No third-party-cookie analytics on public pages. The public surface has no Google Analytics, Plausible, Fathom, or equivalent. Cloudflare may record request logs at the network layer for security purposes; those are not accessible to CJI.
- Never No AI framing on the public surface. The intelligence product is alpha-only and not exposed on cjipro.com. The public site does not describe, link to, or imply the existence of an AI product. This is a URL-filter consideration: AI-category filters at regulated firms are common.
- Never No cross-tenant data crossing. MIL (public market signal) and Pulse (private internal telemetry) never share infrastructure, code, or data. The boundary is enforced at build time by a static import validator; a violation breaks the build. This is called Zero Entanglement and is documented on the architecture page.
- Never No synthetic customer voice in real briefings. Verbatim customer quotes in all briefings are real, unedited, attributed to source and date. Synthetic content appears only on the clearly labelled sample briefing at /insights/sample-briefing/, which carries a persistent [Illustrative] banner throughout.
- Never No live customer data without a DPIA. CJI Pulse does not activate on any firm's live telemetry until a Data Protection Impact Assessment has been completed, documented, and agreed with the data controller. This is a hard prerequisite, not a best-efforts step.
-
Never
No Cloudflare Access on paths alpha partners need to reach from corporate networks. Cloudflare Access redirects to
*.cloudflareaccess.com, a domain that matches phishing-pattern signatures at major bank proxies and is auto-blocked. Public content on cjipro.com is served without Access gating. This is a documented architectural constraint, not a convenience decision.