Data Privacy & Security Policy

How Tako-HR protects employee and applicant data under a multi-tenant architecture.

Last updated: 24 Jun 2026

  • 1. Data Classification & Sensitivity
  • 2. Multi-Tenant Isolation
  • 3. Authentication & RBAC
  • 4. Personal Data Protection (PDPA)
  • 5. Data Storage & Transmission
  • 6. Audit & Observability
  • 7. Vulnerability Reporting
  • 8. Responsibilities
1. Data Classification & Sensitivity
LevelExamplesControl
Public
Job postings (public recruitment)Open
Internal
Org structure, positionsScoped by companyId
Personal (PII)
ID card, address, emergency contactsBy permission + PDPA
Highly sensitive
Salary, payslips, appraisals, health/benefit dataStrict — owner & specific permission only
2. Multi-Tenant Isolation

The system's most important rule: one company's data must never leak to another.

  • Hierarchy: Organization → Company (tenant) → Employee
  • companyId comes only from the user's JWT, via assertCompanyId(req)
  • Never accept companyId from request body / query / params
  • Every read/write query must include WHERE company_id = …
  • By-id writes must verify the record belongs to the user's company first
  • Global master data uses company_id IS NULL deliberately, and only for non-sensitive data

Audit status

  • Phase 0–2: HIGH/MEDIUM issues closed (central auth guard + 15+ modules)
  • Phase 3: hardening by-id writes in schedules, OT, transfers, contracts, holidays, face-scan
  • Ref: docs/security/tenant-isolation-*.md
3. Authentication & RBAC

Authentication

  • JWT signed with JWT_SECRET (from environment only)
  • Supports cookie and Authorization: Bearer
  • Claims: userId, companyId, employeeId, departmentId, roleId
  • Permissions resolved per-request from roleId (cached), not embedded in token

Authorization (RBAC)

  • Format resource:action e.g. payroll:approve, leave:write
  • Every endpoint passes authenticate + authorize(...)
  • Whitelist: login, forgot/reset-password, /api/public/*
  • No permission = 403 at the API, not just a hidden UI
4. Personal Data Protection (PDPA)
  1. Data minimization: collect only what HR administration requires
  2. Purpose limitation: use data only as disclosed and consented
  3. Data-subject rights: support access / correction / consent withdrawal
  4. Retention: keep ex-personnel data for the set period, then delete/anonymize
  5. Applicant consent: public-portal applications must record consent before storing
5. Data Storage & Transmission
  • Primary data in PostgreSQL (via Drizzle ORM)
  • Files/attachments on object storage (S3) per config
  • Passwords stored hashed only — never plaintext
  • Secrets / connection strings in environment, never committed to the repo
  • Helmet and rate limiting on the API by default
6. Audit & Observability
  • Key resources record createdBy / updatedBy from req.user
  • Approvals, payroll runs, and back-dated time edits must be traceable
  • Observability (OpenTelemetry + Prometheus) monitors anomalies
7. Vulnerability Reporting
  • Report vulnerabilities immediately — especially cross-company (tenant) leaks
  • Do not disclose vulnerabilities publicly before they are fixed
  • Tenant leaks and highly-sensitive data leaks = top priority
  • Track remediation in docs/security/
8. Responsibilities
PartyResponsibility
EngineeringScope every query by company_id, add authorize, never commit secrets
Admin / HRGrant least-privilege access, review roles periodically
EveryoneUse data for its purpose; don't share sensitive data needlessly