Security
CrewHour exists to produce time records an employer can stand behind under scrutiny. That only works if the system holding those records is itself trustworthy, so this page describes the controls we actually run — and, just as plainly, the attestations we don't hold yet.
1. Record integrity — the core of the product
- Append-only by construction. Punch events and the audit log cannot be updated or deleted. This is enforced by a database-level trigger that raises an error for every role, including our own operators — tamper resistance below the application, not a policy promise.
- Tamper-evident hash chain. Every event is linked into a SHA-256 hash chain using a frozen, canonical encoding. Any alteration of history — by anyone — breaks the chain and is detectable by an independent verification tool that ships with the product.
- External anchoring. The chain tip is anchored daily to write-once object storage (Amazon S3 Object Lock in compliance mode), so the chain's state on a given date can be proven after the fact.
- Retention floor. Evidentiary records carry a seven-year retention floor; destructive deletion inside the window is refused, and any sanctioned override is itself audited.
- Adjustments as new events. Corrections never mutate the original record — they are appended with the actor, timestamp, reason, and approval chain attached.
2. Tenant isolation
Each customer's data lives in its own PostgreSQL schema on infrastructure we operate — a query scoped to one tenant cannot read another tenant's rows by accident. Cross-tenant platform data (tenant registry, administrative accounts) is held separately.
3. Encryption and secrets
- All traffic between clients and the service is encrypted in transit with TLS.
- Databases are encrypted at rest with AWS-managed keys (KMS).
- Application secrets live in AWS Secrets Manager, not in code or images.
- Employee PINs and administrative passwords are stored only as one-way cryptographic hashes. Biometric unlock on mobile devices never sends biometric data to us — the match happens on the device.
4. Access and authentication
- Role-based access within each tenant (admin, manager, HR, viewer), with HR-locked fields that managers cannot edit.
- Single sign-on via OIDC for customers with an identity provider.
- Kiosk devices authenticate with registered device tokens; employees authenticate at the kiosk with a PIN.
- Support for WebAuthn-backed signing on sensitive attestations, binding the signature to the person's hardware credential.
5. Infrastructure and operations
- The database runs in private subnets with no public access; the application runs in minimal, shell-less (distroless) containers, and interactive access to production containers is disabled.
- Deployments authenticate to AWS through short-lived OIDC credentials — no long-lived cloud keys in the repository or CI.
- Errors and exceptions are monitored continuously; every administrative and record-affecting action lands in the immutable audit log.
6. What we don't claim (yet)
We would rather under-claim than over-claim — the whole product is built on that instinct.
- We do not yet hold a SOC 2 or ISO 27001 attestation. Independent third-party attestation is planned as the company scales; until then, we will answer security questionnaires directly and honestly.
- We are an early-stage company with a small team. We compensate with architecture — the integrity controls in section 1 do not depend on operator discipline — but we won't pretend to have a 24/7 security operations center.
7. Reporting a vulnerability
If you believe you've found a security issue, email info@crewhour.com with the details. We read every report, we won't pursue good-faith researchers, and we'll tell you what we did about it.