Security

Accounts and access

• Passwords are hashed with bcrypt. We never store or log them in the clear.
• A minimum password length is enforced, and passwords past bcrypt’s limit are refused rather than silently truncated.
• Sessions are held in signed, encrypted cookies, not readable by the browser.
• Roles limit what each user sees — an employee reaches self-service only; administrators and payroll roles reach the screens their job needs.
• One-click approval links carry a single-use token as the credential, so an approver never has to be given a password.

In transit and at rest

• All traffic is served over HTTPS with HSTS.
• The database is managed Postgres (Neon), with encryption at rest and daily point-in-time-recovery backups handled by the provider.
• Application hosting is on Vercel. Secrets are stored as encrypted environment variables, never in the repository.

Application safeguards

• Leave balances are a ledger, not a stored number, and are only debited on final approval — a decision cannot silently rewrite history.
• Payslips are frozen snapshots. A finalised payroll run keeps the figures it was finalised with.
• The payroll engine refuses to run against a statutory rate table that no named person has verified, so a wrong or zeroed rate cannot quietly reach a payslip.
• Scheduled jobs authenticate with a bearer secret and are not reachable from a browser.

Data handling

Access to production data is limited to what is needed to operate and support the Service. We do not sell data, and we do not use third-party advertising or analytics trackers. See the Privacy Policy for retention and deletion.

Reporting a vulnerability

If you believe you have found a security issue, email security@greenlithr.com with enough detail to reproduce it. Please give us a reasonable window to fix it before any public disclosure. We will acknowledge your report and keep you updated on the fix.