Security organisation
Doctena's information security function reports to the CIO and ultimately to the CEO. A Chief Information Security Officer (CISO) owns the ISO 27001:2022 ISMS.
The CISO maintains the risk register, the corrective-action register from internal and external audits, the supplier security review catalogue, and the security objectives and KPIs.
Security by design
Every new feature is reviewed for privacy and security impact during design. New external dependencies trigger a supplier risk assessment. Significant architectural changes trigger a threat model that is co-owned by engineering and the security office. Privacy and security stories accompany the feature into the deploy pipeline and into the regression test suite.
Multi-layer infrastructure
Doctena's production estate is hosted on Amazon Web Services Frankfurt (eu-central-1), behind multiple defence layers:
- Cloudflare WAF, DDoS, bot-management and the EU Data Localization Suite on every internet-facing surface.
- Private subnets and AWS Security Groups isolating each tier; no public IPs on application or database tiers.
- Automated dependency upgrades.
- Software composition analysis (SCA) and static analysis (SAST) gating every pull request.
- Container scanning before images are promoted to production.
- AI-assisted attack-prevention at the edge for anomalous patterns the WAF rules do not cover.
High availability across at least two geographically isolated AWS availability zones inside the EU. Application tier is stateless, auto-scaling on load.
Identity, access and MFA
- Mandatory MFA on every Doctena employee account with access to source code, infrastructure or production data.
- SSO via the corporate identity provider on every internal tool.
- Principle of least privilege on every access path.
- Regular access reviews per system, per role, per person.
- Joiner/mover/leaver process integrated with HRIS, access revoked within hours of departure.
Encryption
AES-256 at rest on production databases, file storage and backups, with managed encryption keys. TLS 1.3 (TLS 1.2 minimum) in transit. Hostname-based pinning on sub-processor integrations where supported.
Environment isolation
Production data is strictly segregated from non-production environments. Pre-production, test and demonstration environments are seeded with synthetic data only and never contain production personal data. No production data ever flows into a non-production environment.
Backups and disaster recovery
Daily encrypted snapshots of the production databases retained for a rolling 30-day window (one month). Encrypted disaster-recovery copies of the snapshots are held in a second EU region, AWS Ireland (eu-west-1), alongside the primary AWS Frankfurt (eu-central-1) estate. Recovery procedures are exercised at least annually and a record of each test is kept.
- Recovery Time Objective (RTO): 4 hours for the production booking surface.
- Recovery Point Objective (RPO): 1 hour for transactional data.
Monitoring and detection
Continuous monitoring of application performance, infrastructure health, and security signals (authentication anomalies, WAF events, supplier integration errors) through Datadog. On-call rotation covering 24/7 for critical alerts. Anomaly detection on login events and on data-export events.
Retention is differentiated by log type: application and system logs are retained for a minimum of 3 months, while authentication and network logs are retained for a minimum of 90 days, and longer where required for investigations, legal holds or audits. The 3-month figure matches the retention table in our privacy policy.
Vulnerability management
Inbound vulnerability information flows from multiple sources: SAST and SCA on every pull request, dependency advisories, external penetration tests, and the Responsible Disclosure programme. External penetration tests are run at least annually and on major releases; findings are remediated and re-tested. Findings are triaged against a CVSS-based SLA:
- Critical (CVSS 9.0 to 10.0): remediation target 7 calendar days.
- High (CVSS 7.0 to 8.9): remediation target 14 days.
- Medium (CVSS 4.0 to 6.9): remediation target 30 days.
- Low (CVSS 0.1 to 3.9): remediation target 90 days.
Compensating controls are documented when a within-SLA fix is not feasible. Vulnerability KPIs are reviewed regularly by the Information Security Office.
Incident response
Doctena maintains a documented incident response plan covering triage, communication, containment, eradication, recovery and post-incident review. The plan is exercised at least once per year.
To date, Doctena has had no notifiable personal data breach.
Breach notification commitments to controllers are documented in the Data Processing Agreement: we notify affected controllers without undue delay and no later than 48 hours, in time for the controller to meet its own 72-hour obligation under Article 33 GDPR.
People and training
- Background checks performed for every new hire in line with national law.
- Confidentiality undertakings in every employment contract.
- Mandatory security and privacy onboarding within the first weeks.
- Annual security and privacy refreshers tracked in the learning system.
- Quarterly phishing simulations with metrics tracked by the Information Security Office.
- Role-specific training for engineers (secure coding), customer support (data-subject handling), and people managers (joiner/mover/leaver).
PCI-DSS scoping
Doctena's exposure to cardholder data is limited to redirecting end-users to Stripe-hosted checkout pages. We never receive, process, transmit or store cardholder data on our infrastructure and operate under SAQ-A scope of PCI-DSS v4.0. Stripe is a PCI-DSS Level 1 service provider.
Technical and organisational measures summary
The table below summarises the principal TOMs referenced by our Data Processing Agreement. The full set is documented in the Information Security Policy and the Statement of Applicability; see the ISO 27001 page.
| Area | Control |
|---|---|
| Encryption at rest | AES-256 for production databases, file storage and backups, with managed encryption keys. |
| Encryption in transit | TLS 1.3 (TLS 1.2 minimum) for all external traffic. Internal service-to-service traffic terminated through mTLS where AWS PrivateLink does not already provide isolation. |
| Authentication | Mandatory multi-factor authentication on every Doctena account with access to source code, infrastructure or production data; single sign-on via the corporate identity provider. |
| Network | Cloudflare in front of every internet-facing surface (WAF, DDoS protection, bot protection). AWS Security Groups + private subnets isolating workloads. No public IPs on application or database tiers. |
| Endpoint | Managed laptop fleet with disk encryption, EDR, automated patch management. Locked-down baseline; no admin rights for end-users. |
| Supplier security | Every patient- or customer-facing supplier reviewed before onboarding, re-reviewed annually, contractually bound by a DPA where personal data is involved. Public register at /sub-processors. |
| Change management | All production changes go through peer review, automated tests, security static and software-composition analysis, and a deploy pipeline with audit trail. No direct production access. |
| Logging | Application, infrastructure and security logs centralised in Datadog. Application and system logs are retained for a minimum of 3 months; authentication and network logs for a minimum of 90 days; longer where required for investigations, legal holds or audits. Access to logs is itself logged. |
| Audit logs | Authentication events, permission changes, data exports, sub-processor changes and DPO actions are recorded in an audit log. |
To report a vulnerability, see /security/responsible-disclosure. For specific security questions from a customer or partner, email security@doctena.com.