FixingLog – Security and incident handling summary
1. Security objectives
FixingLog uses risk-appropriate technical and organisational measures to protect confidentiality, integrity, availability and recoverability, subject to regular review.
2. Access and separation
Access is tied to authenticated accounts, roles and organisational authorisation. Public reply and confirmation links use limited tokens. Internal notes and staff functions must not be exposed to public customer views.
3. Storage and transmission
HTTPS is required in production. Object storage is protected through application authorisation rather than public bucket listing. Secrets and API keys must not be exposed in client code or logs.
4. Incidents
Security and personal-data incidents are documented, investigated and contained. Where FixingLog acts as processor, affected controllers are informed without undue delay with available relevant information.
5. Contact
Security or privacy incidents: [email protected]. Reports should not contain passwords, full card details or unnecessary special-category data.
6. Recovery and deletion tracking
The stated backup location is Hetzner. Operators must separately record backup frequency, maximum retention and restoration tests; this notice does not establish a backup schedule. Erasure review covers databases, object storage, exports, automation and provider copies as relevant. Failed storage deletion must not be treated as completed erasure.
Version: 2026-10-20-v25