Security

DRAFT — NOT YET IN EFFECT. This document is a working draft prepared for review by an attorney. It has not been approved, is not legal advice, and does not bind anyone in its current form. Text in square brackets, such as [LEGAL ENTITY NAME], is a placeholder that still has to be filled in.

This page describes the main safeguards in Tick Tack Timetrack. It is an overview, not a guarantee, and the measures may change over time as long as they keep at least the same level of protection. The commitments that bind us are in the Data Processing Addendum.

Hosting and infrastructure

• The Service runs on Amazon Web Services in the United States ([AWS REGION]). See our Subprocessor list.
• Application containers run as an unprivileged user with a read-only file system.
• The database and file storage are not reachable directly from the internet. [OWNER: confirm once hosting is set up.]
• Backups: [BACKUP FREQUENCY, e.g. daily] with point-in-time recovery for [BACKUP RETENTION PERIOD], stored encrypted. We test restoring from backup [RESTORE TEST FREQUENCY]. [OWNER: backups are not yet configured; fill in once they are.]

Encryption

• In transit: all connections to the app and API use TLS (HTTPS), and browsers are told to use HTTPS only. Email is sent to our email provider over an encrypted connection.
• At rest: stored files, such as punch photos and exports, are encrypted by the storage service. The database is stored on encrypted volumes. [OWNER: confirm RDS encryption at rest is turned on.]
• Secrets in the database: authenticator-app secrets and the one-time copy of a kiosk PIN are encrypted with AES-256-GCM. Passwords and kiosk PINs are stored only as salted argon2id hashes. Session tokens, API keys, kiosk device tokens, recovery codes, and remembered-device tokens are stored only as hashes, so a copy of the database would not reveal them.

Accounts and access

• Passwords must be at least 10 characters and mix upper case, lower case, and a digit. Repeated wrong passwords lock the account for 15 minutes.
• Two-factor authentication with an authenticator app, one-time recovery codes, and passkeys. Each company can make two-factor authentication optional or required.
• Optional restrictions that limit sign-in or punching to approved devices or IP address ranges.
• Short-lived access tokens (15 minutes) and sign-in tokens that are replaced every time they are used. Changing a password signs out other sessions, and users can see and end their own sessions.
• Role-based access: employees see their own records; managers see the people they manage; administrators manage the company.
• Shared kiosks use PINs that are never shown in responses, with automatic pauses after repeated wrong PINs.

Separation between customers

Every customer record carries its company identifier, and the database itself prevents a record from pointing to another company’s data. Automated tests check that one company can never read another company’s records.

Audit trail

Every change to records is written to an audit log in the same database transaction as the change, with who made it, when, from which IP address and browser, and the values before and after. The database refuses edits and deletions of audit entries.

Application security

• A strict content security policy, protection against framing, and other standard browser security headers. The web app loads no third-party scripts.
• Rate limits on all requests, with stricter limits on sign-in and other credential endpoints.
• Size limits on uploads and requests.
• API keys can be limited to specific resources and can expire. Webhooks are signed so the receiver can check they came from us, and cannot be pointed at private network addresses.
• Automated dependency updates and static security scanning on every change.
• Error reports are stripped of passwords, tokens, PINs, pay amounts, coordinates, and contact details before they leave our servers.

Our team

Access to production systems is limited to the people who need it to run the Service, uses two-factor authentication, and is logged. [OWNER: confirm, and describe any staff security training and confidentiality agreements.]

Incident response

If we become aware of a security incident affecting Customer Data, we will investigate, contain it, and notify affected customers without undue delay as described in the DPA.

Reporting a vulnerability

If you believe you have found a security vulnerability, email [SECURITY CONTACT EMAIL] with the details. Please give us a reasonable time to fix it before telling anyone else, and do not access other people’s data, disrupt the Service, or run automated scans. We will not pursue anyone who reports a vulnerability to us in good faith and follows these guidelines. [ATTORNEY: confirm this safe-harbour wording.]

Certifications

We do not currently hold SOC 2, ISO 27001, or similar certifications. Our hosting provider holds its own; see the AWS compliance programs.