Security, in plain English.

This overview describes, at the level of detail a careful lab director needs, how LabSync Solutions ("LabSync") protects the data you entrust to us. We write it in plain language because security is only meaningful if the people who rely on it can understand it. The underlying controls are written up in greater technical depth in our internal runbooks, available under NDA to Enterprise customers.

1.Our philosophy

A lab's data — patient identities linked to clinical results — is among the most sensitive information any organization handles. We build LabSync on four commitments:

• Least privilege by default. Every query is scoped to a Tenant; every role has only the permissions it needs.
• Fail closed. When uncertainty arises — a corrupted token, an unexpected schema — we reject the operation rather than proceed.
• Tamper-evident records. The clinical audit trail is append-only and reviewable; operators cannot silently rewrite history.
• Boring infrastructure. We prefer widely-reviewed, long-patched technologies over novelty; Python, SQLite/Postgres, nginx/Caddy, well-tested cryptographic libraries.

2.Infrastructure and hosting

Production services run inside containers on a hardened Linux host in a commercial data-center partner (ISO 27001 certified) with physical security controls including 24/7 staffing, biometric access, CCTV, and redundant power. The underlying hypervisor and OS are patched on a monthly cycle, and critical CVEs are patched within 72 hours of advisory.

Infrastructure-as-code describes every production change. Manual console access is reserved for diagnostic work and is logged.

3.Encryption

In transit

Every connection to LabSync terminates at a TLS 1.2+ reverse proxy with modern cipher suites (ECDHE with AES-GCM or ChaCha20-Poly1305). HSTS is enabled with a 2-year max-age and preload; HTTPS is mandatory for all endpoints.

At rest

Database volumes and object storage are encrypted with AES-256 at the filesystem layer. Sensitive fields that leave the database (for example, GCash payment screenshots) are additionally encrypted application-side before being written. Backups are encrypted with a separate key held in a hardware-backed key vault.

Credentials

User passwords are never stored in plaintext. We hash with Argon2id, parameters tuned to current guidance (memory cost ≥ 64 MiB, parallelism 2, iteration count that empirically produces ≥ 100 ms on production hardware). Legacy hashes are upgraded transparently on next successful login.

4.Access control and tenant isolation

LabSync is multi-tenant. Every tenant-scoped database table carries a tenant_id column that is enforced in the ORM layer on every query; no user session can read or modify another tenant's data. A @tenant_required decorator and a tenant_query() helper make it impossible to write a route handler that accidentally bypasses the filter — attempts to do so fail static analysis in CI.

Within a tenant, role-based access control distinguishes admin, lab technician, doctor, and receptionist, each with a different permission matrix published in the in-app documentation. Superadmin access — ours — is limited to a small named group, protected by MFA, and every superadmin action is written to a platform-wide audit log.

Sessions expire after 12 hours of inactivity by default; Enterprise customers can tighten this per policy. CSRF tokens are enforced on every state-changing request.

5.Audit trail (ISO 15189-aligned)

LabSync writes an append-only audit record for every significant clinical event: patient created, sample collected, order placed, result entered, result approved, report released, data exported. Each record captures actor, entity, timestamp, IP, and a structured diff. The table is locked against updates and deletes at the database level. For ISO 15189 accreditation work, we export a signed PDF that can be presented during assessor visits.

6.Backups and disaster recovery

• Daily encrypted snapshots of the database and attached object storage, retained 30 days.
• Weekly off-site mirrors to a secondary region for disaster recovery, retained 90 days.
• Quarterly restore drills: we restore the last backup into a sandbox environment and verify a random sample of records; results are documented and shared with Enterprise customers on request.
• Recovery objectives: RTO ≤ 8 hours, RPO ≤ 24 hours for Pro customers. Enterprise customers can negotiate stricter targets.

7.Network and application security

• DDoS protection and TLS termination via Cloudflare with Philippine-preferred POPs.
• Web application firewall rules tuned for OWASP Top 10 categories.
• Per-route rate limits on login, password reset, and the public demo form; global rate limits per IP.
• Content Security Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy headers set conservatively.
• HTTP-only, secure, SameSite=Lax cookies for sessions.
• Outbound traffic from production servers to the internet is restricted to a small allow-list (payment verification, email delivery, update feeds).

8.Secure development lifecycle

• All code changes pass through pull request with peer review before merging.
• Continuous integration runs linters, type checks, unit tests, and dependency-vulnerability scanning on every push.
• Static analysis for common web vulnerabilities (SQL injection, XSS, SSRF, open redirect) is part of CI.
• Secrets are stored in an encrypted vault, never in the repository or in environment dumps.
• Releases follow a staging-then-production cadence with the ability to roll back quickly if a regression slips through.

9.People and training

• All staff sign confidentiality agreements and acceptable-use policies on joining.
• Annual security awareness training covering phishing, credential hygiene, and handling sensitive data.
• Quarterly tabletop exercises walking through breach, DDoS, and insider-threat scenarios.
• Production access is limited to a named subset of engineers; access is time-boxed and logged.
• Background checks for staff granted production or financial-system access.

10.Incident response

We maintain a written incident-response runbook with clear roles (Incident Commander, Communications, Forensics), a severity-based escalation ladder, and a 24-hour on-call rotation. When a possible incident is detected:

1. Triage within 1 hour: confirm scope, classify severity, contain the immediate risk.
2. Investigate: preserve evidence, identify root cause.
3. Notify affected customers within 72 hours with the information required by NPC Circular 16-03 (nature of incident, affected data, mitigation, next steps).
4. Remediate: deploy fixes, rotate credentials, strengthen controls.
5. Post-mortem within 14 days: blameless, published internally, summary shared with affected customers.

11.Uptime and monitoring

Target uptime is 99.5% monthly. We monitor HTTP availability, database latency, queue depth, disk usage, and application error rates with pager escalation. Historical status is published at status.labsyncsolutions.com, updated automatically by the monitoring system and annotated with human context after significant events.

12.Third-party testing

We commission an independent penetration test at least once per year from a reputable Southeast Asian security firm. Findings are triaged immediately, with critical and high-severity items fixed before retest. A summary of the most recent report (redacted where necessary) is available to Enterprise customers and prospects under NDA.

13.Responsible disclosure

If you are a security researcher and believe you have found a vulnerability in LabSync, we are grateful for your report. Please email security@labsyncsolutions.com, optionally encrypted with the PGP key published at labsyncsolutions.com/.well-known/security.txt. We will:

• Acknowledge your report within 2 business days.
• Confirm or dispute it within 7 business days.
• Fix validated issues, severity-permitting, within 30 days for high, 90 days for medium.
• Credit you publicly if you wish.

We commit not to pursue legal action against researchers who make a good-faith effort to report privately first, avoid accessing or modifying user data, and do not impair Service availability.

14.Compliance posture

We are transparent about what we do not yet have: formal ISO 27001 certification is a 2027 target, not a current state. We publish real status rather than aspirational claims.

15.Contact