How RegLens protects customer data.

RegLens is built for financial-services organizations and the providers they rely on. That means our security posture has to satisfy the procurement, risk, and compliance teams at banks, regulators, and the customers our customers serve — not just our own team. This page tells you, at a scannable level, what's in place today, what's on the near-term roadmap, and how to get the depth your procurement team needs.

We describe what we've implemented, not what we aspire to. Where a control isn't in place yet, we say so directly. Where a control is in place but full third-party attestation (SOC 2, ISO 27001) isn't yet complete, we note that too. The goal is that a procurement reviewer can trust the picture on this page and know exactly where to dig deeper.

• Authentication. Email and password with TOTP multi-factor authentication, plus OAuth via Google. MFA is mandatory for every RegLens platform-staff account and optional for end users.
• Access control. Role-based access at the organization level for customer orgs; a separate tiered platform-staff role model with mandatory MFA for RegLens team access.
• Data isolation. Every request is scoped to the requesting user's organization membership. Cross-organization access is blocked at the database policy layer, not just in application code.
• Encryption. AES-256 at rest; TLS 1.3 in transit with TLS 1.2 minimum enforced.
• Audit logging. Append-only audit trail of security-relevant actions including authentication, authorization changes, data exports, and administrative operations.
• Incident response. Documented procedure for detection, investigation, and communication. Customers notified of material incidents within 72 hours per applicable privacy legislation.

The controls below describe the security architecture as actually deployed. Each item is either enabled in production today or explicitly flagged as planned. Where the underlying implementation involves specifics that would help an attacker profile the stack, the description is intentionally at the capability level — the depth is available on request under NDA via the procurement pack below.

RegLens relies on a small, disclosed set of infrastructure providers. Each carries independent SOC 2 Type II attestation. We list them publicly because they are already externally observable and because standard procurement review expects it.

Transactional email is delivered through Resend on a DNS-verified RegLens-owned sending domain. No marketing email is sent today; any future marketing sender will be listed here before first send.

Analytics is loaded only on public marketing pages and is fully suppressed on authenticated routes at the SDK level. IP anonymization is enabled and consent defaults to denied until the visitor explicitly accepts analytics cookies via the on-site consent banner. Customer assessment URLs and dashboard navigation events are never sent to Google.

This section is specific to RegLens. Regulation content currency is the differentiator the platform exists to deliver, and the machinery below is how we deliver it.

• Source monitoring is active for every published regulation on a defined cadence, configurable per regulation.
• Automated hash-based drift detection against the canonical regulator source URL; any byte-level change produces an alert visible to content admins in the Regulation Library.
• Every drift alert is reviewed by a human content admin who assesses whether the change is material, drafts any required content update, and routes the update through the change-review workflow.
• A regulation change audit log records every published content change with proposer, reviewer, approver, publish timestamp, impacted-control set, and count of impacted customers at time of publication.
• Every published regulation is reviewed within a defined SLA of any detected source change. If the change is material, content is updated and customers in scope are notified.

The overview above and the implementation status below are written to be scannable by a procurement reviewer without a security background, and honest enough that a security reviewer can trust the shape of the picture. What the public page does not include, by deliberate choice, is the depth that would help an attacker profile the stack — exact timeout values, internal helper-function names, schema-level detail, and configuration specifics.

That depth exists. If you are evaluating RegLens for use at a regulated institution, we make it available on request under NDA in a procurement pack, and we're happy to walk your security team through it directly. The two paths below route to the right conversation.

The following is public but deliberately conceptual. Deeper implementation detail lives in the procurement pack.

• Multi-tenant isolation. Every customer-data table carries database-level row-level-security policies keyed to organisation membership. Application code cannot bypass these policies; only explicit, audited service-role operations can, and every such operation is logged.
• Encryption approach. AES-256 at rest via the underlying managed-storage layer; TLS 1.3 in transit with TLS 1.2 minimum enforced.
• Audit trail architecture. Audit rows are written via a security-definer function or trusted service-role inserts; updates and deletes are blocked at the policy layer. Every audit row carries actor identity and role, target identity, outcome, request metadata, session identifier, correlation identifier, and timestamp.
• Content-currency machinery. Automated hash-based drift detection against the canonical regulator source URL for every published regulation, on a defined cadence. Drift alerts route to a human content admin who assesses materiality and drafts any required content update. Machines detect change; humans assess materiality.
• Analytics posture. Analytics is loaded only on public marketing pages and is fully suppressed on authenticated routes via SDK-level opt-out and property-level configuration. IP anonymization is enabled and consent defaults to denied until the visitor explicitly accepts analytics cookies.
• Vulnerability disclosure. Report security issues to support@reglens.io. This is the RegLens security team inbox; a dedicated security@reglens.io address will replace it as the team scales. Triage within 5 business days of receipt; critical within a week, high within 30 days, medium/low in the next release cycle.

RegLens helps you assess your compliance posture against a defined catalog of regulations across Canada, the United States, the Caribbean, and the European Union. We produce structured assessments, evidence inventories, and remediation roadmaps tailored to your business profile. RegLens does not replace qualified legal or compliance counsel, and does not submit anything on your behalf to regulators, banking partners, or other third parties. You retain full control over what evidence and assessments you share externally.

This page describes the security and governance architecture of RegLens as implemented on the date below. The architecture is subject to change; the most recent version is always at reglens.io/trust. For contractual commitments, please refer to your signed Master Service Agreement and Data Processing Addendum. RegLens reviews this page in full at least quarterly and on any material change to the underlying architecture.

Last reviewed: 2026-07-02