Security Brochure

Sentinel42 Ltd is a UK cyber and AI advisory company. We build and operate the ISMS27001 platform.

• Company number 17286468, registered in England & Wales.
• ICO registration number C1974552.
• Registered office: 66 Paul Street, London EC2A 4NA.

ISMS27001 is built by a UK-based cyber and AI assessor with over two decades in information security, currently auditing organisations against ISO/IEC 27001 and ISO/IEC 42001 and running Cyber Essentials assessments. The controls in this brochure are modelled on how the standard is actually assessed in the field, not on marketing checklists.

Founder credentials

• ISO/IEC 27001 Lead Auditor
• ISO/IEC 27001 Lead Implementer
• ISO/IEC 42001 Lead Auditor
• ISO/IEC 42001 Lead Implementer
• CISM — Certified Information Security Manager
• CCSK — Certificate of Cloud Security Knowledge
• Cyber Essentials Assessor
• UK SC cleared

More on the team at /about.

Sentinel42 Ltd is not currently ISO/IEC 27001 certified as a service provider.

We operate a live ISMS on the ISMS27001 platform itself. Every policy, risk, control test, access review, management review, incident, non-conformity and audit finding for Sentinel42 Ltd is managed in the same product our customers use — so the ISMS is real, current, and continuously evidenced rather than a document set that gets refreshed before an audit.

• Scope of the ISMS is defined and documented.
• Statement of Applicability in place against ISO/IEC 27001 Annex A.
• Internal audit programme is running, with findings tracked in-app.
• Target: Stage 1 assessment against ISO/IEC 27001 in the near future. We will update this page when certification status changes.

Independent assurance available today is at the founder level: ISO 27001 LA/LI, ISO 42001 LA/LI, CISM, CCSK, Cyber Essentials Assessor, UK SC cleared. Sentinel42 Ltd does not yet hold SOC 2 or Cyber Essentials certification as an organisation.

Verified from the live production database on 21 July 2026. These numbers change as the platform grows; this page will be re-verified each quarter and after any material change.

The static tenant-isolation audit report is available under NDA on request via security@sentinel42.com.

• Email + password authentication, with Google OAuth as an alternative sign-in.
• No anonymous sign-ups. Account creation is controlled by the customer's Admin.
• TOTP multi-factor authentication with recovery codes, enforced by an in-app MFA gate on accounts that require it.
• Leaked-password check against the Have I Been Pwned corpus on signup and password change.
• Failed-login tracking and lockout to slow credential-stuffing attempts.
• Idle-session timeout and session-change detection to reduce the risk of unattended or hijacked sessions.

• Six product roles: Admin, Head of Information Security, Head of Department, Auditor, User, Viewer. Permissions are enforced in the database, not just in the UI.
• Row-Level Security is enabled on every customer-data table. Role checks are evaluated through a SECURITY DEFINER helper so that policy logic cannot be bypassed by a client query.
• Multi-organisation tenancy: every row is pinned to an organisation, and a database trigger prevents an existing row from being moved to a different tenant.
• Third-party integration credentials (Jira, GitHub, Microsoft Defender, Intune, and similar connectors) are stored encrypted and are never exposed to the browser bundle.

The platform is a multi-tenant SaaS service. Every customer organisation shares the same managed database, object storage and compute infrastructure, but data is kept separate by logical isolation at the row level.

• Each row is tagged with an org_id and every customer-data table has Row-Level Security policies that ensure a user can only see rows belonging to their own organisation.
• A database trigger prevents any row from being moved from one organisation to another after it is created.
• Nightly automated adversarial probes run against an isolated staging backend to verify that a user in Organisation A cannot read, write, update, delete or infer data belonging to Organisation B.
• This is logical isolation on shared infrastructure, not physical separation. A dedicated, physically separated environment is available to Enterprise customers by arrangement.

Sentinel42 exposes a Model Context Protocol (MCP) server so that compatible AI assistants — such as ChatGPT, Claude and Cursor — can read live data and create management actions on behalf of a signed-in user. This access is gated by the same controls as the web app.

• A user must authenticate with their normal Sentinel42 credentials (and MFA, if required) before any AI connection is established.
• The user is shown an explicit consent screen naming the client and must choose to approve or deny the connection.
• The AI assistant receives a short-lived OAuth 2.1 access token minted by Supabase Auth. The token identifies the user, so Row-Level Security and organisation policies apply exactly as they do in the browser.
• The MCP server exposes read-only tools for risks, incidents, Statement of Applicability controls and management actions, plus the ability to create a new management action. It cannot delete or modify existing records, and it cannot access data the user is not permitted to see.
• Agent access is included with every workspace at no extra charge.

• Customer data is logically isolated per organisation. Cross-organisation access is restricted to platform super-admins for support purposes and is itself audited.
• All traffic is served over TLS. Data is encrypted at rest at the platform layer.
• Server-only secrets (integration credentials, service keys, signing keys) never reach the browser bundle.

We rely on well-established, standards-based cryptography rather than anything home-rolled. Signing keys and encryption keys are held server-side only and are never shipped in the browser bundle.

In transit

• All traffic to the platform is served over TLS 1.2+, terminated at the Cloudflare edge with modern cipher suites and HSTS.
• Outbound calls to sub-processors (managed Postgres, R2, Defender/Graph, Jira, GitHub, Google, BambooHR, email provider) are all over TLS.

At rest

• Managed Postgres storage is encrypted at rest with AES-256 at the platform layer.
• Cloudflare R2 backup objects are encrypted at rest with AES-256 server-side encryption.
• Third-party integration credentials (Jira, GitHub, Defender, Intune, Google Workspace, BambooHR) are stored encrypted in the database via Postgres pgcrypto (pgp_sym_encrypt) using a server-only symmetric key, and are only ever decrypted inside server-side functions.

Authentication & tokens

• Passwords are hashed with bcrypt by the managed auth layer — plaintext passwords are never stored or logged.
• Sessions use short-lived JWT access tokens with refresh-token rotation; MFA uses TOTP (RFC 6238) with single-use recovery codes.
• Public verification and unsubscribe links use cryptographically random tokens (single-use where applicable) rather than guessable identifiers.

Integrity & signing

• The security audit log is SHA-256 hash-chained, and the chain can be recomputed on demand to prove no entries have been altered.
• Every nightly backup archive is written with a SHA-256 sidecar, and the restore-verification job recomputes the digest to prove the archive is intact and restorable.
• Uploaded files are looked up by SHA-256 hash against VirusTotal (hash-only, no file bytes leave the platform).
• Public inbound webhooks (detections, email provider events) are verified with HMAC-SHA256 signatures against a server-only signing secret before any payload is trusted.
• Requests to Cloudflare R2 are signed with AWS Signature v4 (HMAC-SHA256).

Key management

• Signing and encryption keys (integration-credential key, webhook signing secrets, R2 credentials, service keys) are held as server-only secrets, are never exposed to the browser bundle, and are rotatable.
• Rotation of a signing secret or the integration-credential key is a controlled change tracked in our own ISMS on this platform.

Security telemetry from the app, its integrations and its edge is normalised into a single audit and finding surface — a lightweight, purpose-built SIEM for the ISMS.

• Append-only, hash-chained security audit log covering authentication events, role changes, RLS-relevant writes, admin actions and integration syncs. Retention: two years.
• Chain-integrity verifier: Admin and Head of Information Security can recompute the hash chain on demand to prove no entries have been altered or removed.
• Record-level history in a separate change log ("who changed what, when").
• Detection ingestion: a verified public webhook accepts external detection events (WAF, edge, custom rules) and lands them in the platform Findings register.
• Microsoft Defender XDR integration: incidents and alerts are pulled on a schedule and surfaced in the Incident Register and Vulnerability register.
• Jira and GitHub evidence hooks feed the same incident and finding surface, so telemetry from multiple sources is normalised in one place.

• Nightly logical backups per organisation written to object storage with a SHA-256 sidecar. Every backup run is recorded in an append-only backup_runs log for evidence.
• Retention pruner: last 90 daily snapshots kept, plus the first-of-month snapshot for the previous year.
• Automated restore verification: on a schedule the latest backup for every organisation is downloaded and its SHA-256 recomputed. This proves backups are actually restorable, not just written. Every run and result is recorded for audit.
• Failure alerts are emailed to the security inbox on any backup or restore-test failure.
• Managed-Postgres point-in-time recovery sits underneath the application-level backups as a second line of defence.

Recovery objectives are set at the application layer and evidenced by the automated restore-verification job. These are our published targets; contractual RTO/RPO for a specific customer is agreed in the MSA.

• Upload malware / AV scanning: every file uploaded to Storage is scanned via a dedicated hook, results are recorded per file, and infected files are quarantined before any user can access them.
• Dependency vulnerability scanning: Dependabot plus a scheduled dependency-audit workflow. High and critical findings are mirrored into the in-app vulnerability register.
• Static analysis (SAST): CodeQL runs on every push and pull request against the platform codebase.
• Tenant-isolation probe suite: automated tests run against staging covering RLS reads, RLS writes, SECURITY DEFINER RPCs, org_id invariants and Storage isolation — designed to catch cross-tenant regressions before they ship.
• Phishing simulation results and Microsoft Defender configuration posture are visible to Admin and Head of Information Security.

Beyond human review, these controls run automatically against the platform on every code change and on a schedule. Each one produces evidence that is retained in our own ISMS on this platform.

• DSAR workflow covering access, rectification, erasure and portability, with a public intake form, verified in-app fulfilment, and an event log for evidence.
• Email integrity: suppression list and signed unsubscribe tokens for all outbound email, and webhook-verified handling of authentication emails.
• Return or secure deletion of personal data on termination, subject to any legal retention obligation (DPA clause 12).

• Incident Register with regulator-notification tracking.
• Access reviews, control tests, management reviews and a vulnerability register — the same modules customers use, run for Sentinel42 Ltd itself as part of our own ISMS.
• Change log captures who changed what, when, across the platform.

These are the recurring reviews that keep the ISMS honest. Each one is scheduled and evidenced in the platform's own registers.

• The platform runs on managed cloud infrastructure (managed Postgres, serverless edge runtime, object storage with tenant-prefixed keys) hosted in the EU/UK region.
• All traffic is served over TLS. Data is encrypted at rest at the platform layer.
• Application framework: TanStack Start on Cloudflare Workers. Database: Postgres with Row-Level Security on every customer-data table.
• Server-only secrets are never exposed to the browser bundle.

Where we process personal data on a customer's behalf, our standard Data Processing Agreement applies as an addendum to the Master Services Agreement. Key terms:

• Article 28 UK GDPR, controller-to-processor.
• Governed by the law of England & Wales.
• Processing only on the customer's documented instructions.
• Sub-processor changes notified in advance, with a reasonable opportunity to object on data-protection grounds (clause 6.1).
• Assistance with data-subject requests, DPIAs and breach notification (clauses 7–9).
• Return or secure deletion of personal data on termination, subject to any legal retention obligation (clause 12).
• Audit right: once per twelve-month period on reasonable notice, or more often following a personal-data breach or at a regulator's request (clause 11.2).

The following sub-processors support the platform today. The list includes both core infrastructure and customer-controlled integrations that pull data into the platform. Changes are notified per DPA clause 6.1.

List current as of 21 July 2026.

• We operate a documented incident-response process covering detection, triage, containment, notification and post-incident review.
• Personal-data breaches affecting a customer are notified to that customer without undue delay, with the information required under DPA clause 8 and Article 33 UK GDPR.
• Customers can log incidents directly in the platform's Incident Register, and can pipe external detections into the same register via the Defender, Jira and detections webhooks described above.

If you believe you have found a security issue affecting the ISMS27001 platform, please email security@sentinel42.com with details and, if possible, steps to reproduce. Please do not publicly disclose the issue before we have had a chance to respond.

We will acknowledge reports within two UK business days and keep you updated through remediation.

• General enquiries: info@sentinel42.com
• Security reports and incidents: security@sentinel42.com
• About the founder and company: /about
• Data Processing Agreement: /dpa