Security at DayOneFlow

• Every record that belongs to an organization carries that organization's identifier, and database constraints keep related records within the same organization.
• On every request the server checks who you are and that you have an active membership in the organization you're asking about, then looks records up only within that organization. The organization in the address bar is never treated as proof of access.
• A record from another organization looks exactly like one that doesn't exist: the answer is “not found”, and nothing is changed.
• An automated cross-tenant test suite tries to reach every kind of organization-owned record from a second organization, including by calling server actions directly.

• Organization admin, HR, manager and member, each mapped to a fixed set of permissions. There is no permission editor to misconfigure.
• Managers see only the new hires they manage, and without personal contact details, preboarding details, documents or offers. Members see only the tasks assigned to them.
• Salaries are visible only to people who manage offers, and to the candidate on their own personal page.
• Every action checks its own permission on the server. A hidden button is never the protection.
• Disabling or removing a member takes effect on their next request. Their open tasks become visible, unassigned work for HR instead of disappearing.

• Sign in with an email address and password, or with Google where Google sign-in is enabled. No Google access tokens are stored.
• An email address must be verified before it can be used to sign in with a password.
• Passwords need at least 12 characters and are hashed with Argon2id. The password itself is never stored, so no one at DayOneFlow can see it.
• Sign-in, registration and password reset are rate-limited, and they never reveal whether an email address is registered.
• Sessions expire after at most 12 hours without activity and are re-checked against the database on every request. Resetting a password or disabling an account ends all of that person's sessions at once.
• Session cookies are encrypted, HttpOnly, SameSite and, over HTTPS, Secure.

• Each link contains 256 bits of randomness and is stored only as a hash, so even a copy of our database would not reveal a working link.
• A link is bound to one organization and one new hire. It cannot be used to see anyone else's record.
• Links expire. Each new hire has one working link: issuing a new one replaces the old one. HR can revoke a link at any time, and it closes when the record closes.
• Guessing is blocked: after 20 unknown links from one address within 15 minutes, further attempts from that address are refused.
• Links are masked in our web server logs, never sent to other sites as a referrer, and personal pages are kept out of search engines.

• Served over HTTPS only (TLS 1.2 or 1.3), with HSTS so browsers refuse plain HTTP.
• A strict Content-Security-Policy with a fresh nonce for every page: only our own scripts run, and no third-party scripts are loaded.
• Pages cannot be embedded in other sites, which prevents clickjacking.
• Protection against cross-site request forgery on sign-in and on every action that changes data.
• Emails are handed to our email provider over an encrypted connection (STARTTLS is required).

• Uploads are limited to PDF, PNG and JPEG, decided from the file's content rather than its name. PDFs containing scripts or embedded files are refused, and each file can be at most 10 MB.
• Every upload is scanned for viruses with ClamAV, whose signatures update automatically, before it is stored. Infected files are refused, and if the scanner cannot give an answer the upload is refused rather than stored unchecked.
• Files are stored privately, outside anything the web server publishes, under generated names. A storage location can never be used as a link.
• Every download passes an authorization check and is sent as an attachment, with headers that stop the browser from running it.
• HR checks every document a new hire uploads — accepted, or a new copy asked for — and only HR and admins can open documents. Signature images for letters are checked and scanned the same way; verification checks record a status, never what a check found.
• Offer letters are generated from a frozen copy of the offer as it was sent, never from data that could change later.

• Important actions are recorded in the same database transaction as the change itself: offers sent and decided, membership and role changes, personal links issued and revoked, uploads and removals, probation decisions and exports.
• The database refuses any change to, or deletion of, an audit event.
• Sent offer versions, candidates' decisions, status history and probation decisions cannot be edited afterwards. The database enforces this too.
• A candidate's acceptance is bound to the exact offer version and to the version of the acceptance wording they saw.
• HR and admins can review the trail for the whole organization and for each new hire.

• We collect the minimum: no bank, payroll, tax or government-ID fields, and date of birth only if your organization turns it on.
• Logs never contain passwords, tokens, personal links or salaries. As a safety net, fields named like secrets or email addresses are redacted automatically.
• Emails and in-app notifications contain no salaries.
• Reports and CSV exports leave out free text, contact details and salaries, and every export is recorded in the audit trail.
• No analytics, advertising or tracking tools, and only the cookies needed to sign in.
• Error messages never show internal details, and a record from another organization is never confirmed to exist.

• A daily backup of the database and stored files, with checksums.
• A copy encrypted with GPG before it leaves the server. The key that decrypts it is kept off the server.
• Copies on the server are kept for about six months: 7 daily, 4 weekly and 6 monthly.
• Restoring has been tested in a drill: an encrypted off-server copy was restored, and every row count and file checksum was verified. A drill on the production server is part of the go-live.
• A database backup is taken before every update that changes the database, and every update is health-checked and rolled back automatically if it fails.

• The database accepts only local connections. The firewall allows only SSH and web traffic, SSH logins use keys only, the application runs as an unprivileged user and security updates are applied automatically.
• Only named operators can reach the server and database, each with a personal SSH key.
• No one at DayOneFlow can sign in as one of your users: there is no impersonation feature. Our operations screen shows only account information (organizations, user accounts, counts), never your new hires' records, documents, offers or bank details; if we suspend your account or change your trial, your audit trail shows it.
• Checks every five minutes cover the application, database, background worker, backups and disk space, and alert the operators when something changes.
• Secrets live only in the server's protected configuration, never in the code.

Who else processes data for us is listed on the Subprocessors page.

1. 1

   Step 1: Email us the details

   Write to security@dayoneflow.com with what you found, the steps to reproduce it, the pages or features affected and the impact you expect. Please leave out other people's personal data.
2. 2

   Step 2: Test only what is yours

   Use your own accounts and your own organization. Never access, change or delete other people's data; if you come across any, stop and tell us.
3. 3

   Step 3: Keep it safe for everyone

   No denial-of-service, spam or social-engineering tests, and nothing aimed at candidates, new hires or customers.
4. 4

   Step 4: Give us time to fix it

   Allow us a reasonable time to fix the issue before you disclose it publicly. We will work with you to understand it and resolve it.