Security overview

LumkoMDX is built on the premise that privacy must be a property of the system, not a policy enforced by people. The Three-Boundary Model ensures that identifying patient data cannot enter the federation. That architectural guarantee is the foundation; this page describes the operational practices that defend it.

We map our controls to the standards our customers are evaluated against: ISO/IEC 27001:2022, SOC 2 Type II, HITRUST CSF, POPIA Conditions 1–8, the GDPR Article 32 baseline, and the HIPAA Security Rule. Our certification roadmap is shared with prospective customers under NDA on request.

We classify everything we touch into four bands. Controls scale to classification.

Patient identifying data is — by design — not a classification LumkoMDX handles. It never crosses the federation boundary into LumkoMDX-controlled systems.

In transit

TLS 1.3 with modern cipher suites only. HSTS with preload, certificate pinning for federation peer-to-peer links. Internal service-to-service uses mutual TLS with short-lived workload identities.

At rest

AES-256-GCM for primary stores, ChaCha20-Poly1305 on mobile and edge. Backups encrypted independently with separately-managed keys.

Key management

Customer-managed keys (CMK) supported on enterprise plans. Default keys are held in FIPS 140-2 Level 3 HSMs, rotated quarterly, with documented break-glass procedures.

At query time

Federated queries are signed by the originating identity, verified at each federation edge, and re-signed by each edge with a per-execution signature recorded in the immutable audit log.

Access to production systems is treated as an exceptional act, not a default state.

• Identity — Single sign-on via an enterprise IdP, hardware-key MFA required for any production-adjacent role. No shared accounts. No long-lived API tokens.
• Authorisation — Role-based access control with deny-by-default. Production permissions are issued just-in-time via a signed elevation request, time-bounded to the minimum needed, and revoked automatically on completion.
• Auditing — Every authentication, every elevation, every privileged action is logged to an append-only store that the operating team cannot edit.
• Segregation — Engineers building the platform do not have standing access to customer environments. Customer-environment access is performed by the customer support team, with the customer's written authorisation per ticket where the data classification requires it.

Customer environments are deployed as logically isolated tenants. Where required by regulation or contract, we deploy dedicated single-tenant environments with their own networking, key material, and operational pipelines.

Tenant boundaries are enforced at three layers: network (per-tenant VPC and firewall policy), data (per-tenant encryption keys), and application (per-tenant authorisation context applied to every request, with cross-tenant access cryptographically impossible by construction).

Penetration testing

Quarterly, by independent third parties. Annual deep-test against the federation protocol and consent verifier. Summary reports available to enterprise customers under NDA.

Static and dynamic analysis

Continuous SAST on every commit, dependency scanning with SBOM generation, DAST against staging environments before each release.

Code review

Two-person review for all production code. Security-sensitive changes require a third signoff from the security team and are tagged in the audit log.

Bug bounty

Coordinated disclosure programme open to vetted researchers. See Vulnerability disclosure.

Production environments stream telemetry to a central SIEM with detections written by our security team and tuned weekly. Coverage includes:

• Anomalous authentication patterns, geo-impossible logins, brute-force attempts.
• Elevation requests outside the operator's normal envelope.
• Unexpected federation traffic — queries against unauthorised sites, malformed cryptographic envelopes, replay attempts.
• Resource patterns that suggest a tenant boundary is being tested.

On-call security engineers are paged 24/7. Median time to acknowledge a high-severity alert is under 8 minutes.

We operate a formal Incident Response Plan aligned with NIST SP 800-61. The shape of a serious incident:

1. Detect & triage. Severity is assigned within 30 minutes, on-call security lead is the single decision-maker.
2. Contain. Scope-limiting actions — revoke credentials, block routes, isolate affected tenants — take priority over root-cause analysis.
3. Notify. Customers affected by a confirmed security incident are notified within the contractual SLA — at minimum, within 72 hours for incidents that may have compromised personal data, in line with POPIA and GDPR.
4. Eradicate & recover. Remediate the root cause, restore service, run a "stay-well" period under elevated monitoring.
5. Learn. Blameless post-mortem within 14 days. Material lessons feed back into the platform within one release cycle.

Regulator notification timelines vary by jurisdiction; our DPO leads that workstream and customers are kept in the loop throughout.

RPO

15 minutes for operational stores. Customer data inside their own boundary is governed by their own RPO; we provide the federation layer to keep it that way.

RTO

4 hours for the LumkoMDX control plane.

Backups

Encrypted, geographically redundant, restoration tested monthly against a synthetic incident.

Region failover

Active-passive across two AWS regions in our home jurisdiction. Customer-region environments fail over within the same regulatory boundary.

Tabletop exercises

Quarterly, with rotating scenarios. Outcomes feed back into the IRP.

• Background screening for everyone with production-adjacent access, repeated every two years.
• Mandatory security and privacy training on hire and annually.
• Role-specific training for the federation, cryptography, and SRE teams.
• NDAs and contractual confidentiality survive employment.
• Offboarding checklist closes access within 24 hours of last working day, faster on adverse exits.

Sub-processors are evaluated against the same controls we hold ourselves to. Onboarding requires a security questionnaire, DPA, and review of their most recent independent attestation. Material vendors are reviewed annually and on any reported incident affecting them.

Our open-source dependencies are tracked in an SBOM published per release. We pin transitive dependencies, scan for vulnerabilities continuously, and patch on a published SLA: critical inside 24 hours, high inside 7 days, others on the next release.

If you believe you've found a security issue, please email security@lumkomdx.com with proof-of-concept detail and the smallest report that reproduces it. PGP key on request.

We will acknowledge inside 24 hours, classify inside 72, and keep you updated as we work through it. We will not pursue good-faith researchers who follow coordinated disclosure. Public credit on remediation is offered, with your consent, on our security advisories page.

Reporting an issue

security@lumkomdx.com

Compliance questions

compliance@lumkomdx.com

Data protection officer

dpo@lumkomdx.com

24/7 incident hotline

Provided to enterprise customers in the runbook delivered at onboarding.