Security overview
Security-first engineering
Security is designed into SwiftCode from the start. We build in layers, grant the least access necessary, and treat every request as untrusted until it is authenticated and authorized.
Secure software lifecycle
Security is part of how we build, not a step at the end. Changes move through code review and an automated pipeline before release.
- Peer code review on changes before they merge to the main branch.
- Continuous integration builds, vets, and tests the backend and clients on every change.
- Automated dependency, container, and secret scanning run in the pipeline.
- Security-relevant changes (authentication, transport, data handling) receive additional review.
Defense in depth
No single control is trusted to stand alone. Protections are layered so that a weakness in one does not expose clinical data.
- Network isolation: internal services (database, cache, message broker) are reachable only from application services on a private network.
- Application-layer authorization on every request, scoped to the caller's facility and role.
- Encryption in transit and at rest, plus minimization of clinical data in notifications and logs.
- Durable, append-only audit logging of critical security and clinical events.
Least privilege
Access is granted narrowly and derived from the verified session — never from client-supplied input.
- Database-backed role-based access control with granular, per-role permissions.
- Per-facility data isolation enforced at the API layer for every read and write.
- Cloud identity and service permissions scoped to only what each component needs.
- Administrative actions are restricted and recorded.
Zero-trust principles
Every request is authenticated and authorized regardless of where it originates.
- Signed, short-lived session tokens with server-side revocation on logout, deactivation, or role change.
- Session tokens travel in request headers, not URLs, and are stored in the device keychain on mobile.
- Realtime connections are authenticated and authorized per facility, so a facility receives only its own data.
- No implicit trust between clients and services; identity is verified on each call.
Threat modeling & review
We reason about how the system could be attacked and review our controls as the platform evolves.
- A maintained threat model informs design decisions and prioritization.
- Internal security reviews accompany significant changes.
- A documented vulnerability-management process with severity-based remediation targets.
- An independent third-party penetration test is planned before production PHI use — not yet completed.
Evaluating SwiftCode for your facility?
Enterprise customers may request our security questionnaire, architecture overview, and pilot materials during procurement — under NDA where required.
Security questions? security@swiftcode.tech