Security at StaffClock

Data encryption

• In transit: All connections to StaffClock are encrypted using TLS 1.2 or higher. Plain-HTTP connections are rejected in production.
• At rest: Data is stored in a managed PostgreSQL database with encryption at rest provided by the infrastructure layer (United Kingdom).
• Passwords: StaffClock does not use passwords. Authentication is entirely passwordless (magic links), eliminating password-reuse and brute-force attack surfaces.

Authentication and session management

• Magic-link login: Login links are single-use, cryptographically signed, and expire after 72 hours. A consumed link cannot be replayed.
• Session cookies: Sessions are stored in signed, HttpOnly, Secure, SameSite=Strict cookies — not accessible to JavaScript and not sent on cross-site requests.
• Session revocation: Each user account carries a session epoch. Bumping the epoch instantly invalidates all active sessions for that account without affecting other users.
• Rate limiting: Login and signup endpoints are rate-limited per IP. Repeated failures are throttled before any database work is attempted.
• Bot protection: Public forms are protected by Cloudflare Turnstile (proof-of-human challenge) and a honeypot field.

Application security controls

• Tenant isolation: Every data access is scoped to the authenticated organisation. Cross-tenant access is architecturally impossible — a request for another org's data returns 404 before reaching business logic.
• CSRF protection: All state-changing requests (POST/PUT/PATCH/DELETE) are validated against an Origin/Referer allowlist, in addition to the SameSite=Strict cookie defence.
• Content Security Policy: A strict nonce-based CSP is enforced on every page. Inline scripts without the per-request nonce are blocked. frame-ancestors: none prevents clickjacking.
• Security headers: All responses include Strict-Transport-Security (HSTS with includeSubDomains), X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy, and Permissions-Policy.
• Injection prevention: All database queries use the ORM (SQLAlchemy) with parameterised queries. No raw SQL string formatting.
• Audit log: Security-relevant events (login, account deletion, data export, settings changes) are written to an append-only audit log. Sensitive client identifiers (IP, user-agent) are stored as peppered SHA-256 hashes — the raw values are never retained.

Data residency and processors

Your data is stored and processed in the United Kingdom. We use a small number of sub-processors to operate the service. A full list is published in our Data Processing Agreement.

Audit logs are automatically purged after 365 days. Account data is deleted on request via the self-service deletion flow (/delete-account) or a DSAR erasure request.

Incident response

In the event of a security incident affecting personal data we will:

1. Contain the incident and assess scope within 24 hours of discovery.
2. Notify affected customers without undue delay and, where required by UK GDPR Art. 33, report to the ICO within 72 hours of becoming aware of a breach.
3. Provide a plain-language description of what happened, what data was affected, and what steps we have taken.

To report a suspected incident, email security@staffclock.co.uk.

Responsible disclosure

We welcome responsible disclosure of security vulnerabilities. If you discover a security issue in StaffClock, please:

1. Email security@staffclock.co.uk with a description of the issue and steps to reproduce.
2. Give us reasonable time to investigate and remediate before publishing.
3. Avoid accessing, modifying, or deleting data that does not belong to you.

We will acknowledge your report within 3 business days and keep you informed of our progress. We do not currently offer a bug bounty but we will credit researchers who follow this policy (unless they prefer to remain anonymous).

A machine-readable version of this policy is available at /.well-known/security.txt.

What we don't do (yet)

We are honest about where we are. The following controls are on our roadmap but not yet in place:

• SOC 2 Type II or ISO 27001 certification
• Formal third-party penetration test
• Hardware security keys / FIDO2 as a second factor
• Automated dependency vulnerability scanning in CI

If any of these are blockers for your organisation, please contact us — we're happy to discuss our roadmap or answer specific questions.

Contact

Security questions, vulnerability reports, and incident notifications: security@staffclock.co.uk

General privacy and data requests: /privacy · Submit a DSAR