Security

Email support@lazshift.com with enough detail to reproduce the issue. A machine-readable version of this is at /.well-known/security.txt.

What to expect:

• We acknowledge within three business days.
• We tell you our assessment, and what we intend to do, within ten business days.
• We will tell you when it is fixed, and credit you if you would like to be credited.

Testing in good faith

If you follow the boundaries below, we will not bring legal action against you, and we will say so to anyone who asks. Please:

• use only accounts you own, or a test account we have given you;
• stop as soon as you have demonstrated a problem — do not read, copy, alter or keep other people's data, and tell us immediately if you encounter any;
• avoid anything that degrades the Service for its users: no denial of service, no bulk automated scanning, no spam or social engineering of our staff or customers;
• give us a reasonable chance to fix the issue before you publish it.

We do not run a paid bug bounty. We are a small company; what we can offer is a prompt, non-hostile response and public credit.

LazShift is a web application served over HTTPS only, backed by a managed Postgres database and server-side functions. It runs in the United States. Traffic is encrypted in transit with TLS, and data is encrypted at rest by the platform.

HTTP is redirected to HTTPS, HSTS is set, and the application declines to be embedded in a frame — a page that renders somebody's wage should not be loadable inside another site.

Every table holding customer data is protected by row-level security in the database itself, scoped to the requesting user's company and location. The check is not in the application code that happens to be asking; it is in the database, and it applies to every query regardless of which screen or endpoint issued it.

Privileged operations that must cross that boundary — provisioning a company, inviting an employee, billing — live in server-side functions that verify the caller before doing anything, rather than in the browser. Where one acts on a person, it also checks that the caller is responsible for them: a manager can change the sign-in details of, or remove, only someone at a location they manage and below them in rank.

• Employees see their own schedule, profile, pay rate and requests.
• Colleagues at the same site see each other as a work directory — name, role, profile photo, work contact details, published shifts, approved time off, marked availability — which is what makes covering a shift possible without a manager relaying it. Pay rates are never visible to colleagues.
• Managers and administrators see their team's details and pay, scoped to the locations they are responsible for.

Passwords are stored hashed by our authentication provider and never in readable form. Sign-ins are recorded. LazShift staff accounts require two-step sign-in with an authenticator app, enforced by the database rather than only by the sign-in screen, so a staff password on its own reaches nothing beyond our own internal account. Administrative actions by our own staff — including the support "view as" capability — are written to an audit log.

When a manager changes somebody's sign-in email or password, it is recorded, and the person is emailed at their previous address if they have used their account. A sign-in on a computer other people use can be marked as shared, which ends it when the browser closes or after 30 minutes without activity. Schedule PDFs sent to staff are private files behind links that expire after 30 days.

Our staff do not access a customer's data except to provide support that has been asked for, to investigate a security or billing problem, or where the law requires it.

What we collect, how long we keep it, and the providers that process it on our behalf are set out in the Privacy Policy, which names every one of them and says what each receives. Card details go to Stripe directly and never reach our systems.

If a breach affects personal information we will notify affected customers and, where required, regulators and individuals, without undue delay and within the timeframes the law sets.

Stated plainly, because you would otherwise have to ask, and because a security page that lists only strengths is not telling you anything.

• No SOC 2 report and no ISO 27001 certification. We have not been through either audit.
• No independent penetration test has been carried out against the Service.
• No formal bug bounty programme — see §1 for what we do offer.
• No single sign-on or SCIM provisioning yet, beyond Google sign-in.
• No two-step sign-in for customer accounts yet. It is required for LazShift staff accounts, which are the ones that can reach every customer.
• No customer-managed encryption keys, and no data residency options outside the United States.

If one of these is a requirement for you, tell us before you buy rather than after. We would rather lose the deal than have you discover it later.

Security reports, and questions about anything on this page, go to support@lazshift.com.