Security at Doctena

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 and chairs the quarterly Information Security Steering Committee, attended by the heads of engineering, product, customer support, legal & compliance, and the DPO.

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 presented at every steering committee.

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 (daily for security patches, weekly for routine).
• 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 — typically a hardware security key — 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. Production access is named, time-limited, ticketed and audited.
• Quarterly 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 AWS KMS-managed customer master keys and automatic rotation. TLS 1.3 (TLS 1.2 minimum) in transit. Hostname-based pinning on sub-processor integrations where supported.

Environment isolation

Four logically isolated environments: Production, Staging (pre-production replica with synthetic data), Demo (sales / training, synthetic data), and Test (CI sandbox, ephemeral). No production data ever flows into non-production environments. Customer test environments and demo accounts are seeded from synthetic data only.

Backups and disaster recovery

Daily encrypted snapshots of the production databases retained for a rolling 90 days. Cross-region disaster-recovery copies of the snapshots inside the EU. Recovery procedures are exercised on a quarterly cadence 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.

Security logs are routed through a separate ingestion path with write-once semantics and a dedicated access role. Access to the security log archive is itself logged.

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. Findings are triaged against a CVSS-based SLA:

• Critical (CVSS 9.0–10.0): remediation target 24 hours.
• High (CVSS 7.0–8.9): remediation target 7 days.
• Medium (CVSS 4.0–6.9): remediation target 30 days.
• Low (CVSS 0.1–3.9): remediation target 90 days.

Compensating controls are documented when a within-SLA fix is not feasible. Vulnerability KPIs are reviewed at every steering committee.

Incident response

Doctena maintains a documented incident response plan covering triage, communication, containment, eradication, recovery and post-incident review. The plan is exercised in tabletop format twice a year.

Breach notification commitments to controllers are documented in the Data Processing Agreement — 48 hours from Doctena awareness.

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 week.
• Annual security and privacy refreshers tracked in the learning system.
• Quarterly phishing simulations with metrics presented to the steering committee.
• 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.

To report a vulnerability, see /security/responsible-disclosure. For specific security questions from a customer or partner, email security@doctena.com.