Security

Workforce data, protected in the design

CrewAware holds records about people, hours, jobsites and pay preparation. Here is how the product actually protects them — stated from the engineering, not from a brochure.

Principles

Three properties the product is built around

Server-authoritative by default

The state that matters — who may sign up, what a subscription allows, whether a punch counts — is decided on the server. A clever browser cannot talk CrewAware into a different answer.

Isolated by company

Every workforce record belongs to a company, and authorization compares that ownership on the way to every record. One company's crews, hours and projects are not another company's to see.

Accountable records

Punches, breaks and corrections are recorded as individual events with history. Time entries cannot be deleted, and approved records stop being editable — the record holds.

Access

Authenticated access, throttled at the door

Nothing operational in CrewAware is reachable without an authenticated, email-verified account inside an active company workspace.

Authentication and verification required

Every operational surface sits behind authentication, email verification and an active company context — there is no anonymous path to workforce data.

Rate-limited authentication endpoints

Registration, login, password reset and email verification are all rate-limited server-side, and login attempts are additionally throttled per account and source.

A server-held signup gate

Public signup is controlled by server configuration that defaults to closed. When it is off, the registration route simply does not exist — no header, query trick or client flag can open it.

Separated session and token contexts

Browser sessions and API tokens are distinct access contexts, and tokens are rejected where sessions are expected — one credential kind cannot masquerade as the other.

Isolation

Company boundaries enforced in code

CrewAware is multi-company software, and the boundary between companies is an authorization rule, not a convention.

Tenant resolution on every request

Dedicated middleware resolves the active company for every operational request and refuses requests that lack one.

Ownership checked per record

Time entries, projects, crews, employees, payroll exports, schedules and leave records each have an authorization policy that compares company ownership before access — cross-company reads and writes are denied at the policy layer.

Role-based permissions inside a company

Within a company, access is shaped by roles and permissions, so reporting, exports and administration can be granted to the people whose job they are — and withheld from everyone else.

Records

Time records that hold up

The value of a time record is what it can prove later. CrewAware is built so the record survives the people arguing about it.

Time entries cannot be deleted

The authorization policy for time entries refuses deletion outright — for everyone. A record that turned out to be inconvenient is corrected on the record, not removed from it.

Corrections leave a trail

Once an entry is closed or approved it stops being directly editable; changes flow through edit requests that record who asked, what changed and who approved it.

Approvals and locked exports

Hours are approved in batches, and payroll exports can be locked — a locked export is a durable record of what payroll was prepared from.

Events, not editable totals

Clock-ins, clock-outs, breaks, geofence evaluations and location captures are stored as discrete events, so the history behind a number is inspectable.

Location

Location handled honestly

GPS evidence is only worth something if it is collected honestly and bounded clearly.

Punch events only

CrewAware records location when a worker clocks in or out. It is not continuous background tracking, and it does not follow people who are off the clock.

Geofences evaluated on the record

Project geofences are defined by your administrators, and punch locations are evaluated against them with the outcome stored as part of the record — flagged for review, never silently altered.

This website

The marketing site holds nothing sensitive

crewaware.app — the site you are reading — is deliberately separate from the application and deliberately minimal.

No workforce data here

This website never holds employee, time, location or payroll data. The application lives at its own origin with its own controls; the two do not share cookies or storage.

Strict browser protections

Every page ships a restrictive Content-Security-Policy, frame-ancestors denial and content-type protections, with scripts and styles served only from this origin.

Consent-governed, fail-closed analytics

Optional analytics runs only after explicit consent, honors the Global Privacy Control signal, sends no personal or workforce data by construction, and does not exist at all in builds where no analytics property is configured.

A contact form that cannot pretend

The contact endpoint validates server-side, rate-limits, rejects automation — and fails closed: it never tells you a message was delivered unless the delivery provider positively accepted it.

Practice

Built and released carefully

Security is mostly habits. These are the ones CrewAware's engineering actually keeps.

Tested, staged, then released

CrewAware changes ship with automated test coverage and staged, evidence-recorded QA on non-production environments before release. That is an engineering practice we hold ourselves to — stated as exactly that, and nothing grander.

Synthetic data for testing

Product testing and QA run on synthetic, non-customer data in non-production environments.

Privacy

Security and privacy travel together

How CrewAware handles personal information — on this website and in the service — is described in the privacy notice, and the terms set out the commitments around the service itself.

Contact

Questions about security?

If you have a security question about CrewAware, or believe you have found a vulnerability, contact us and it will reach the engineering team.

Contact CrewAware

Questions

Security questions

Can another company see our data?

No. Every record in CrewAware belongs to a company, and access checks compare that ownership on the way to the record itself rather than trusting the request that asked for it. Isolation is a property of the data path, not a setting somebody has to remember to switch on.

How do we control what our own people can see?

Roles and permissions, administered inside your workspace. What a given person may open, change or approve is decided on the server for each request — a browser cannot talk CrewAware into a different answer by asking differently.

Is there an audit trail?

Yes, on the things that matter for a pay dispute. Punches, breaks, corrections and approvals are individual events, correction requests keep who asked and who approved, and time entries cannot be deleted by anyone. That is what makes the record usable as evidence rather than as a summary.

Do you have SOC 2, ISO 27001 or a pen-test report?

No, and we will not imply otherwise. CrewAware describes the controls it can actually demonstrate in the product, and nothing on this page is a certification, an attestation or an audited claim. If a formal attestation is a requirement for your business, we would rather you know that now.