Security architecture

What happens to your data, end-to-end:

• Multi-tenant isolation: every database query is scoped by organization_id at the ORM layer; integration tests verify cross-tenant queries return no rows. No raw SQL access for application code.
• Audit logging: every admin mutation (create / update / delete worker, schedule, attendance entry, billing change) is recorded with actor, target, before/after values, IP address, and timestamp. Retained for the life of the account and deleted with it.
• Backups: RDS automated snapshots daily, retained 30 days; point-in-time recovery to any second within the retention window. Restores are tested quarterly per disaster-recovery runbook.
• Right-to-erasure flow: GDPR / CCPA deletion requests flow through /admin/identity/users — anonymizes worker PII (name, email, phone, biometric template) while preserving aggregated attendance records the controller (your organization) needs for labor-law compliance. See Privacy Policy §4 for the full mechanism.
• Biometric data (face recognition for clock-in): collected only when a worker explicitly consents at first use (GDPR Art. 9(2)(a)). Face templates are stored as one-way hashes — the original image is never retained. Org admins can disable face recognition globally in Attendance Rules; consent can be withdrawn anytime in worker profile.

How we run security as a function:

• Engineering practice: every code change goes through pull-request review with at least one approving reviewer. Security-relevant changes (auth, encryption, IAM) require an additional security-designated reviewer.
• Dependency management: Python via Poetry with locked versions; JavaScript via Bun lockfile. Vulnerable dependencies surfaced via GitHub Dependabot and addressed in priority order.
• Access control: production access is read-only by default; write access requires a documented change ticket. Engineer offboarding revokes all access within 24 hours of departure.
• Incident response: an internal runbook covers identification → containment → eradication → recovery → post-incident review. Severity-1 incidents trigger a 24-hour customer notification commitment (Privacy Policy §6).
• Vendor security review: every sub-processor we add (currently 5 listed at /trust/sub-processors) goes through a documented review — DPA in place, security questionnaire reviewed, data scope minimized.

We commit to a public, dated roadmap rather than retroactive claims. Live progress:

• SOC 2 Type II — TARGETED Q1 2027. Not yet certified. Vanta + A-LIGN selected (decision logged 2026-05-24). Public 8-milestone timeline at /trust/soc2; report issued Q3 2027.
• GDPR-ready architecture — privacy audit Wave 1-4 complete (data minimization, right to erasure, consent gates, biometric processing under Art. 9). Not formally certified by a regulator (GDPR has no formal certification body); we provide our DPA on request at /trust/dpa.
• ISO 27001 — NOT YET ENGAGED. May follow SOC 2 in 2027 or 2028 depending on customer demand from EU enterprise prospects.
• Industry-specific (HIPAA / PCI-DSS / FedRAMP) — NOT IN SCOPE today. SVDY targets SMB workforce management; healthcare PHI / cardholder data / federal-government workloads are out of our use case until explicitly added.