Data classification
Every piece of data in Rucja is classified as one of the following: protected health information (PHI), personally identifiable information (PII), operational data (audit logs, config), or public data (marketing content). Different controls apply to each class. PHI gets the strongest handling.
Encryption
- In transit: TLS 1.2 or higher on every public endpoint. HSTS with preload. Internal service-to-service traffic in private networks is also encrypted.
- At rest: customer databases are encrypted at rest using AES-256 through the managed database service. Object storage for lab PDFs and images is encrypted at rest with server-side keys.
- Backups: encrypted with a separate key stream and stored in a different region from the primary.
- Field-level: especially sensitive fields (integration secrets, third-party API keys) are encrypted at the application layer with envelope encryption on top of the database encryption.
Access controls
- Role-based access control inside the product. Users see only what their role permits.
- Single sign-on for enterprise customers via SAML or OpenID Connect. MFA is enforced for admin roles.
- Rucja staff access to customer environments is on a need-to-know basis, logged, and time-boxed. Production database access is not part of routine engineering work; break- glass access is reviewed after the fact.
- Every mutation is written to an append-only audit log with actor, target record, before / after values, and timestamp. Hospitals can export their audit log at any time.
HIPAA readiness
Rucja is HIPAA-ready. We sign a Business Associate Agreement with US hospital customers and follow HIPAA Security Rule technical safeguards. We do not claim HIPAA certification, because HIPAA has no certifying authority. Where a customer requires an equivalent audit report, we can provide one under NDA.
Outside the US, we sign the Data Processing Agreement required by the customer's jurisdiction (UK GDPR, EU GDPR, India DPDPA, and equivalents). International data transfers rely on Standard Contractual Clauses or the equivalent framework recognised by the customer's regulator.
Application security
- Code review is required on every merge; secrets are never committed to source control.
- Dependencies are pinned and monitored for known vulnerabilities. High and critical fixes are prioritised over feature work.
- Static analysis and secret scanning run in CI. Container images are scanned before deploy.
- Third-party penetration tests are run at defined intervals. Findings and remediation are tracked to closure.
Infrastructure and network
- Hosted on major cloud providers with SOC 2 Type II and ISO 27001 attestations.
- Isolated private networking for application and database tiers. Public endpoints are fronted by a WAF and rate limiting.
- Least-privilege IAM. No long-lived access keys for services that can use IAM roles.
- Infrastructure changes go through code review; drift is monitored.
Availability, backups, and recovery
- Automated backups multiple times per day with a defined retention window.
- Backups are restored in a non-production environment on a regular cadence to verify they work.
- Recovery point objective and recovery time objective are set out per customer in the service level agreement.
Incident response
- On-call engineers are paged for security-relevant alarms 24 hours a day.
- If we confirm a security incident affecting customer data, we notify affected customers within the timeframe required by the applicable law (72 hours under UK / EU GDPR; equivalent windows apply elsewhere).
- Post-incident, we run a blameless review and publish the findings and follow-up work to affected customers.
Responsible disclosure
If you believe you have found a security issue in Rucja, please email info@rucja.io. We ask that you:
- Give us a reasonable window to fix the issue before making it public.
- Do not access or modify data that is not yours.
- Do not run automated scans that would degrade service for other customers.
In return, we will acknowledge your report within two business days, keep you updated on remediation, and credit you publicly if you would like once the fix is deployed.
Sub-processors and shared responsibility
A full list of sub-processors is available on request under NDA and is refreshed whenever it changes. Security is a shared responsibility: we run the platform, and hospital customers own user provisioning, access reviews, device security, and the way the product is configured for their staff.
Contact
Security questions and disclosure reports: info@rucja.io. Compliance requests (BAA, DPA, pen-test reports): info@rucja.io.