Current status register

Google, Microsoft and Apple OAuth sign-in controls are present in the application alongside email/password with MFA. Provider availability at any given time depends on live provider configuration; provider-by-provider runtime availability on regalign.app and the platform host has not been independently verified in this closure.

Why: The buyer question is one corporate identity plus MFA. The controls are in place; the operator confirms which providers are enabled for a specific engagement before go-live and records that confirmation on the Order Form.

SAML 2.0 single sign-on with enterprise identity providers (Okta, Entra ID, OneLogin, Ping, ADFS) is not yet available. There is no self-service SAML configuration UI, and no operator-run provisioning path in production today.

Why: SAML is a stated future capability. It sequences with the first enterprise-shaped engagement that requires it and will be scoped, priced and dated in that Order Form. See the Security Roadmap for the trigger.

In the meantime: OAuth SSO above is sufficient for pilot-scale buyers today.

SCIM 2.0 automatic user provisioning and de-provisioning is not built. Seats are created and revoked manually by an operator.

Why: SCIM only pays off above roughly fifty seats and depends on SAML shipping first. Not required at pilot scale.

In the meantime: Seats are granted and revoked by an operator under the applicable support and operating arrangements for the engagement.

There is no documented public REST API for customer integrations yet.

Why: The export surface today is CSV (the RegAlign ↔ RiskAlign bridge contract is v1, frozen) and PDF. A REST API will follow customer demand.

In the meantime: CSV import/export covers reporting and bulk operations.

RegAlign is cloud-only. There is no on-premise or customer-managed deployment.

Why: A single-tenant managed deployment can be discussed on request; a true on-premise build is not on the roadmap.

No credit-card processing. RegAlign invoices customers and is paid by bank transfer.

Why: Regulated firms procure via Order Form + invoice + bank transfer (NET30). Card rails add fees and PCI scope without matching how buyers actually pay. Issue forms from /order-form in the operator console.

There is no completed third-party penetration test report today. A scoped Statement of Work and an RFP have been drafted; a test has not been commissioned to a named tester and no attestation letter has been issued.

Why: The test will be contracted and scheduled when the first paid pilot commits. The Trust Centre will publish an executive summary when a report exists.

Not certified. A SOC 2 Type I readiness path is outlined in the Security Roadmap.

Why: Certification timing is driven by customer demand; controls are already documented and audit-walkable.

The 5 calls / hour / IP limit on Compass is enforced per edge-runtime worker, not globally.

Why: Acceptable for the pilot traffic profile. A durable per-IP counter is on the dev backlog.

Role-specific first-run checklists (CCO, MLRO, Board) ship in-product at /first-run-checklist.

Why: Live since the System-Readiness Sprint. Replaces the founder-led walkthrough as the default onboarding path. Progress is stored per browser/device — clearing browser storage or signing in on a new device resets the visible checklist state.

Notification digest cadence and working-hours are user-level, not tenant-level.

Why: Tenant-level overrides will land once we have feedback from two live pilots on what they actually want batched.

There is no in-product 'delete my pilot data' button.

Why: Deletion on pilot exit is run by us, documented in the Data Retention & Deletion policy, and evidenced in the audit trail. A self-serve button is on the backlog.

In the meantime: Email a deletion request to hello@regalignplatform.com. Deletion timing and residual-backup treatment follow the agreed retention and deletion scope for the engagement, and the verified operational process; a deletion certificate is returned on completion.

Ten registers (incidents, findings, breach register, internal SARs, whistleblowing reports, third parties, DP breaches, DSARs, conflicts, training) still allow free-text categorisation alongside the structured linkage model.

Why: Phase 1 shipped the linkage model and a universal picker; per-form retrofits are mechanical and sequenced post pilot #1 to avoid concurrent UI churn.

Several internal diagnostic and aging-cohort routes exist as separate URLs rather than query parameters on a single route. The /diagnostics index page surfaces them centrally.

Why: Historical scaffolding. Bulk consolidation is a developer-handover ticket; the index page is the safe interim. Does not affect operator workflows.

Server-side error telemetry is wired to Sentry. The browser-side Sentry initialiser reads its DSN from a server function at runtime, so the DSN is not required at build time.

Why: Lovable Cloud disallows user-managed VITE_-prefixed build secrets, so the public DSN is exposed via a server function instead. Functionally equivalent to a build-time DSN.

The /status page reads from the status_probes table and is publicly viewable. Probes are written every five minutes by a scheduled job against a fixed allow-list of public surfaces (application root, public status JSON, chain verifier).

Why: Jurisdiction landing pages are not currently in the probe set. Broader surface coverage is a dev-handover ticket.

We have a designed support model but no externally published SLA.

Why: Will be published when the first paying tenant signs. Pilot agreements include explicit per-pilot response commitments.

Today, one person (the founder) is the named operator and the named technical contact.

Why: Successor role spec, second-operator brief and source-code escrow are drafted but not signed. We are explicit about this rather than hiding it.

In the meantime: Supported CSV and PDF export surfaces exist for specified platform records (obligations, controls, findings, tasks, board-pack sections, audit-trail extracts). Comprehensive export of every governance state has not been independently verified. The audit trail records every operator action for after-the-fact review.

There is no third-party support partner today.

Why: Will be introduced after the first paying tenant signs (Phase 17 support-model design).

RegAlign is a tool. Suggestions and classifications are assistive only.

Why: Every output is reviewable by a named human before it becomes a governance record. See AI Use Disclosure. This is a permanent product boundary, not a defect.

The methodology library reflects our research and current professional practice; it has not yet been signed off by an external SME panel.

Why: An SME review brief has been drafted; a named SME has not been engaged. Sign-off will be published alongside any material methodology change.

Jersey (JFSC) regulatory content is the deepest. Guernsey, Isle of Man and UK content exists but is shallower.

Why: We are pre-pilot and Jersey-first by design. Other jurisdictions will deepen with each pilot signed there.

RegAlign is deployed on Lovable Cloud (Cloudflare Workers + Supabase Postgres). Single-vendor hosting concentration is a real procurement question. Continuity, escrow, migration and DR arrangements are disclosed and agreed per engagement in the Order Form.

Why: We do not make universal source-code-escrow, rehearsed-DR-drill or 'switching in days' claims on the public surface; those terms depend on the specific engagement and are set out in writing at contract stage.