Trust
What a security review asks
For a medical director, DPO, and security lead reading the same page. How Signet is built, not policy intentions. Partners forward it to IT. For questionnaire rows, ask for the partner DD pack.
Design
Fail-closed by construction
Nothing reaches a patient before a clinician releases it. Incomplete, invalid, mismatched and critical work is held. Facades refuse unbound or unreleased material.
- Hold cases — incomplete panel; invalid unit or range; mismatched test code; critical value. A person decides; critical results never auto-deliver to the patient.
- Protocol ≠ release — acknowledging a clinic protocol records that action; it does not release the report.
- Bulk release — where enabled for the clinic, remains subject to every hold gate; same release does not create a second report.
Clinic write-back to the clinic system is available only when the deployment’s completion path is bound and where licensed. Write-back is refused if that path is unbound or where write-back is not licensed. Detail: Deliver · Hold.
Assurance
Assurance programme
A SOC 2 Type II programme is in place / commencing. Independent penetration testing is in place / commencing. Controls are operated to that bar.
Programme work is not a certification. This page does not claim that Signet is certified, attested, or badge-complete under SOC 2 Type II or any other standard. We do not display compliance badges.
What this page does not claim
- No SOC 2 Type II certification claim.
- No HITRUST, ISO 27001, HIPAA, PDPA, or GDPR certification or “compliant” claim on this page.
- We will name a framework as certified on this page only when a deployment has been audited against it. No completed SOC 2 report date, certificate ID or “penetration tested” badge until audited evidence is supplied.
Evidence path
Pen-test date, scope, remediations, and whether a report can be shared under NDA are confirmed in contracting — not published as badges or certificate IDs on this page. We answer questionnaires directly for partner reviews — write to hello@lumepath.ai.
Incident and continuity
Operational incident containment is designed into the platform. A published customer-facing incident-response or business-continuity pack is confirmed per partner engagement — not asserted as a public document on this page.
Residency
Named per deployment — exceptions written down
Residency follows the clinics you serve. Each deployment’s data at rest stays in the region those clinics are regulated in. Name that region in the deployment record — whether United States, Singapore, or another market the partner already operates in. Exact hosting terms are confirmed in contracting.
Where Singapore is the deployment record, the platform is designed for Singapore residency, with every named exception written down for the clinic’s data protection officer to accept or reject. The same exception-honest rule applies when the named region is elsewhere.
We do not claim “all data stays in Singapore,” and we do not claim a single global “all data always in X.” Absolute slogans are false for the documented exceptions below.
| Deployment | Named residency | Honest exceptions |
|---|---|---|
| Clinical and aggregate data stores | Named per deployment (e.g. United States or Singapore region where that is the record) | A named region is not a comprehensive guarantee. Confirm the live deployment record in contracting. |
| Platform audit streams | Not pinned with the clinical store | Mandatory platform audit streams may run on global services that cannot be pinned. Named exception. |
| Identity store and hosted sign-in | Not pinned with the clinical store | Identity store location and the hosted sign-in handler are named exceptions where the service cannot be pinned to the clinical region. |
| Email, SMS, laboratory, practice-management, billing | Named per processor, case by case | Transfer terms are confirmed with the clinic’s DPO. Not asserted as complete on this page. |
| Backups, key material, support access | Intended to follow the clinical data plane | Replica regions, key-management region, and whether break-glass support review can occur outside the clinical region are confirmed in contracting. |
Further global identity-provider or audit-stream exceptions, if any, are named in contracting and security questionnaires — not asserted as complete on this page.
Cloud
Cloud-agnostic; SaaS defaults to GCP.
Signet deployments are cloud-agnostic and partnered with GCP, Microsoft Azure, AWS and Oracle. The SaaS option defaults to GCP.
Dedicated or non-GCP cloud, and self-hosted or customer-account deployments with the customer’s own KMS, are deal terms — not a second product line. Encryption in transit and at rest is designed into the platform; exact cipher and KMS binding are confirmed per deployment.
Privacy floor
Employer views refuse small groups
k ≥ 10 is an absolute floor: raiseable by the tenant, never lowerable — including by Lumepath. It is not a default. Aggregates are computed server-side. Complementary suppression applies in the design so small complementary groups cannot re-identify.
Patients are addressed by opaque reference. Identifiers do not appear in patient URLs.
Integrity
Determined only by inputs; byte-identical regeneration
Generation is determined only by inputs, content version and engine version — no clock, no randomness, no external call in the clinical path. Released reports regenerate byte-identical from the same sealed inputs. Sealed digests. Receipted side effects for intake, release and delivery.
Release refuses when sealed source has moved; regeneration is revision-bound. Unsigned material cannot pass as signed. Specimen and unreleased paths stay closed to patients. Facades refuse unbound or unreleased material.
Keys
Managed keys on hosted tiers; customer KMS where self-hosted
Managed keys on hosted tiers. A self-hosted or customer-account deployment can bring its own KMS key so the customer can revoke access to data at rest without asking Lumepath. Self-host and customer KMS are deal terms confirmed in contracting.
Encryption in transit and at rest is designed into the platform; exact cipher and KMS binding are confirmed per deployment. Backup and replica key posture follows the clinical data plane unless a named exception is written into the deployment record.
Identity
OIDC or SAML; local accounts with authenticator also available
OIDC or SAML — Okta and Microsoft Entra are supported patterns under test; hosted customer acceptance is per deployment. Named customer IdPs are listed only with a proved endpoint.
Local accounts with password and authenticator code, or both together, are also available. MFA is required on staff paths. Recovery codes issued once. Clinics are expected to enrol at least two administrators.
Application authorisation is distinct from directory admission: identity-provider group attributes alone do not grant privileges. Application session revocation is distinct from identity-provider disablement; durable hosted qualification of session revocation may be confirmed per deployment.
Patient access
One-use link plus SMS or email code.
Opaque reference. No patient password. No identifier in the URL. No report before clinician release. A patient cannot see a report before a clinician has released it — including when the sealed document is a smart patient report generated in Compose.
Patient access is a delivery surface under the partner brand. Lumepath does not sell to patients and does not open a retail patient channel.
Portals
Separate origins; separate sessions
Each portal is its own origin with its own host-scoped session. Clinical, employer, and patient surfaces are separate doors with separate sign-in. One portal cannot reach another’s routes or session. Foreign portal tokens are refused.
Logs
No clinical payload in the log plane
Operational logs and metrics are designed without clinical values, document bytes, or tokens. Errors use stable, value-free reason codes. Quarantine and hold reasons are meant to be operable without leaking payload content into the log plane.
Retention
Retention is per deployment
Retention is set with the customer’s DPO per deployment — not a single global public number on this page. Controller / processor classification is agreed per relationship with the partner’s DPO; we do not assert a one-line global label without a signed position.
Named third-party sub-processors (email, SMS, laboratory, CMS, billing) and their locations are disclosed per deployment architecture — not asserted as a complete public list here. Mapped cloud patterns are discussed in questionnaires.
PDPA
PDPA posture
Personal data is handled with a Singapore PDPA posture set with the clinic’s DPO where that is the deployment’s law. Compliance remains the clinic’s determination. We do not say “PDPA certified” or “PDPA compliant.” The same honesty applies to GDPR, HIPAA and other regimes: compliance determination sits with the customer and applicable law — not as a Lumepath badge.
Sub-processors are not listed on this page; disclosed on request in security questionnaires.
Stage
Signet is live. A new generation is under active build.
What partners licence today is production software. What is under build is the next generation of the same line. We do not publish customer names, logos or usage counts.
Boundaries
What this page is not
- Not a SOC 2 Type II report, certificate, or badge.
- Not a claim that penetration testing is finished, scoped to every surface, or remediations-closed.
- Not a comprehensive data-residency guarantee or “all data always in X with zero exceptions.”
- Not live customer-count evidence or named client proof.
- Not “HIPAA / GDPR / PDPA / ISO 27001 / HITRUST certified” or “compliant” badges.
- Not a medical-device, SaMD, FDA, CE, or clinical-validation claim.
- Not measured uptime or latency percentages presented as proof.
- Not named lab, CMS or IdP integrations without a proved endpoint.
- Not a public price list.
- Not a published customer-facing IR / BCP pack asserted as complete here.
- Not “certified FHIR.”
Delivery partners: write to the partner team.