DiagnosticMind
Assessments Scorecards Audit Engine
Manifesto Method About
Insights Contact
EN PT
Encryption, access, recovery, response

Security

Last updated: 11 July 2026 · Version 1.1

DiagnosticMind operates in regulated sectors where compliance is the baseline, not the achievement. This page exists to make the operating reality of how this platform protects data legible — not to perform compliance theatre. The detail below is the actual protocol.

On this page

  1. What this page commits to
  2. Encryption
  3. Authentication and access control
  4. Backup and disaster recovery
  5. Vulnerability management
  6. Incident response
  7. Sub-processor security
  8. Acknowledged residual risks

01What this page commits to

Every measure on this page is a commitment, not an aspiration. Measures that are not yet implemented are listed explicitly with their committed delivery date. Where a measure is deferred (for example, external penetration testing), the deferral is named and the trigger for upgrade is specified.

This page is the technical and organisational measures annex for the Data Processing Addendum by reference, and forms part of the operational control documentation referenced in the Privacy Policy.

02Encryption

2.1 In transit

  • HTTPS enforced across all subdomains.
  • HSTS active: max-age=31536000; includeSubDomains; preload (1 year, full subdomain coverage, preload-ready).
  • TLS 1.3 preferred; TLS 1.2 minimum (Cloudflare edge default).

2.2 At rest

  • Cloudflare D1, KV, and R2 — encrypted at rest by Cloudflare default.
  • Cloudflare Pages — static assets encrypted at rest at the edge.

03Authentication and access control

3.1 User authentication (SaaS platform)

  • Passwordless magic links — no stored passwords, no password reuse risk, no password recovery surface.
  • Magic link tokens — 15-minute maximum lifetime, single-use.
  • Session tokens — 7-day rolling lifetime, regenerated on use.
  • Multi-factor authentication — committed by Q3 2026 (TOTP via standard authenticator apps such as Google Authenticator, Authy, 1Password). Implementation pattern: NPM otpauth library, additional totp_secret column in the users table, enrolment endpoints /api/auth/mfa/enroll and /api/auth/mfa/verify. Voluntary enrolment first, mandatory for the Enterprise tier on full rollout.

3.2 Operator-side access

  • MFA is enforced on the operator's Cloudflare account, with hardware security key as the primary second factor.
  • A password manager with unique credentials is used for all administrative interfaces.
  • An isolated browser profile is used for administrative operations.

04Backup and disaster recovery

AspectCommitment
Backup frequencyCloudflare D1 automated point-in-time recovery, 30-day rolling window
Recovery Time Objective (RTO)24 hours for SaaS platform availability
Recovery Point Objective (RPO)24 hours (matches D1 PITR window)
Disaster recovery test cadenceAnnual documented test, with results retained for audit

05Vulnerability management

  • Dependency updates — critical CVEs patched within 30 days; routine quarterly review.
  • Security advisories — monitored via NPM audit and GitHub security advisories.
  • Penetration testing — planned at the first enterprise contract; external pentest (€3–8k) is a best-effort defensible deferral consciously accepted at this stage. Commitment increases to annual once the first enterprise customer signs.
  • Bug bounty — none at this stage. This is typical for pre-revenue B2B SaaS and will be reviewed at scale.

06Incident response

6.1 Detection

  • Cloudflare logs reviewed at minimum weekly.
  • Automated alerting on 5xx error rate spikes (Cloudflare Analytics).
  • Manual review on user-reported anomalies.

6.2 Notification timeline

72 hours to authority and affected customers from awareness, per GDPR Articles 33 and 34. SaaS customers are notified within 48 hours under the Data Processing Addendum (Section 10 of the DPA).

Operational reality. The 72-hour clock starts at awareness, not at detection-system-alert. Discipline: log review cadence is itself a control — gaps in cadence mean gaps in clock-start visibility. The cadence above is not aspirational.

6.3 Reporting a security issue

If you believe you have discovered a security vulnerability in the DiagnosticMind platform, please email contact@diagnosticmind.eu with subject line Security disclosure. Please do not publicly disclose the issue until it has been triaged and acknowledged.

There is no formal bug bounty programme at this stage. Reports are acknowledged within 5 business days.

07Sub-processor security

Sub-processors that handle Personal Data are listed on the Privacy Policy page (Section 4) and the Data Processing Addendum page (Section 7). Each is subject to a written DPA with security obligations no less protective than those documented here.

The current sub-processor set (Cloudflare, Anthropic, Resend) is selected in part for the maturity of their security and compliance posture, including SOC 2 Type II reports, ISO 27001 certification, and DPF certification where applicable. References to each provider's public DPA and security documentation are on the Privacy Policy page.

08Acknowledged residual risks

For full transparency:

  • External penetration testing is not yet conducted; committed at first enterprise contract. Internal review and dependency scanning are the current controls.
  • Multi-factor authentication for SaaS users is not yet implemented; committed for Q3 2026.
  • Bug bounty programme — not yet established.
  • Formal SOC 2 / ISO 27001 certification — not pursued at this stage. The platform's security posture leans on the certifications of its sub-processors plus the controls documented above.

These residuals are accepted consciously, not concealed.

Last updated 11 July 2026 · Version 1.1 Privacy · Data Processing · AI Governance · Security
DiagnosticMind
Assessments Scorecards Audit Engine
Manifesto Method About
Newsletter Contact
© 2026 DiagnosticMind
Privacy Data Processing AI Governance Security