Data Processing Agreement

About this summary

This page summarizes the draft data-processing agreement (DPA) between DayOneFlow's operator and each customer. The DPA is an addendum to the order form and the Terms of Service. If this summary and a signed DPA differ, the signed DPA applies.

The parties are the customer, [Customer legal name], [address], as controller; and [Operator legal name], [Registered address], [registration number], as processor (“we”).

Roles and instructions

• The customer is the controller (under India's DPDP Act, the Data Fiduciary) of the personal data in its DayOneFlow organization. We are its processor (Data Processor) and process that data only to provide the service.
• For staff users' accounts (sign-in details and security data), [TO CONFIRM: we act as an independent controller / as processor].
• The terms, the DPA and the customer's use and settings of DayOneFlow are its documented instructions. Examples of settings: the date-of-birth question, the confirmation letter in the personal page, and whether managers may record probation outcomes.
• We tell the customer if we believe an instruction breaks the applicable law, and may then suspend that processing.
• We do not sell the data, use it for advertising or profiling, or use it to train AI models.

Subject matter, purpose and duration

We host and operate the DayOneFlow software so the customer can make offers and record candidates' decisions, collect preboarding details and documents, run onboarding tasks and check-ins, and record probation outcomes and produce confirmation letters. Supporting processing: sending emails and reminders, securing accounts, keeping the audit trail, and backups and monitoring.

Frequency: continuous. Location: [hosting provider and location]. Duration: the term of the agreement, plus the deletion period described below.

Data subjects and personal data

Not collected: no bank, payroll, tax or government-ID fields (uploaded documents may still show such numbers); no raw IP addresses in the database; no OAuth access tokens; no analytics or tracking.

Special categories: none are requested. Free-text fields and documents (for example, right-to-work documents showing nationality) may contain them [counsel].

Security measures

We maintain the technical and organisational measures listed in Annex II of the DPA. We may improve them, and we do not lower the overall protection. In summary:

• Each organization's data is separated from every other organization's, and a cross-tenant test suite covers every kind of record.
• Fixed roles plus relationship checks: a manager sees only their own hires. Contact details, preboarding details and documents are shown to HR and admins only; salaries only to those who manage offers, and to the candidate.
• Passwords hashed with Argon2id and at least 12 characters long; verified email addresses; encrypted 12-hour sessions, checked against the database on every request.
• Personal links: 256-bit random, stored only as a hash, expiring (1 hour to 180 days), one working link per hire, revocable.
• Encryption in transit: TLS 1.2 or 1.3 and HSTS for the application; STARTTLS required for sending email.
• Files in private storage outside the web root, downloaded only after a check; type checked by content (PDF, PNG, JPEG), PDFs with active content refused, size and quota limits; every upload scanned for malware (ClamAV) before it is stored, and refused when the scanner cannot give a verdict.
• Limits on repeated attempts for sign-in, registration, password reset, invitations, personal links, uploads and exports.
• An append-only audit trail. Sent offer versions, decisions, status history and probation decisions cannot be changed.
• Daily backups with checksums, encrypted before they leave the server, and a tested restore.
• Monitoring every 5 minutes with alerts; logs that redact secrets and email addresses and are kept for 14 days.
• Server hardening (firewall, SSH keys only, database reachable only on the server, unattended upgrades) [TO CONFIRM on the production server], and change control with automated tests, health-checked deploys and a database backup before every migration [TO CONFIRM: CI live].

Known limitations during the pilot

• A single server with no high availability. Backups are daily, so up to 24 hours of data can be lost; there is no point-in-time recovery.
• No encryption at rest by the application for the database, uploaded files, backups on the server or copies made before a software update; they are protected by file permissions only. [TO CONFIRM: disk encryption at the hosting provider.]
• No multi-factor authentication for password accounts.
• Signing out does not revoke a copied session cookie, which stays valid for up to 12 hours.
• Personal links are bearer links: whoever holds one can use it until it expires, is replaced or is revoked.
• Operator access to the server or database is not recorded in the audit trail.
• No per-person export, no erasure of one person's record, no customer-set retention, and no correction of preboarding details after the first day in the app.
• Emails are sent at least once: a crash can send an offer email twice. Only the newest personal link works.
• Production setup (server hardening, SPF, DKIM and DMARC for email, off-server backups, monitoring and CI) was pending when the DPA was drafted [TO CONFIRM].

More on how DayOneFlow is protected: Security.

Our personnel

Only named operators who need access to run the service can reach the server and database, using personal SSH keys [TO CONFIRM: names or roles, and their written confidentiality obligations]. DayOneFlow has no support-impersonation feature and no platform-admin screen.

Sub-processors

The customer authorizes the sub-processors listed in Annex III of the DPA:

• Google is used only if Google sign-in is enabled and a staff user chooses it. [TO CONFIRM: Google acts as an independent controller, not a sub-processor.]
• The [uptime monitoring provider] receives no personal data: the health check returns only a status, a time and the database check. The [alert channel provider] receives only check names and counts, and the [code hosting and CI provider] holds the source code, with only synthetic test data [TO CONFIRM].
• We give [30] days' notice of a new or replaced sub-processor. The customer may object on reasonable data-protection grounds; if the objection cannot be resolved, the customer may end the agreement.
• Each sub-processor is bound by data-protection terms no less protective than the DPA, and we remain responsible for its work.

The current list is on the Subprocessors page.

International transfers

[Where the data is hosted, the transfers made to sub-processors, and the mechanism used: adequacy, EU standard contractual clauses (Module 2 or 3), the UK addendum, or the DPDP Act's cross-border rules.]

Requests from individuals and other help

If we receive a request from a candidate, new hire or other person, we pass it to the customer within [X] business days. We do not answer it ourselves unless the customer instructs us to.

• Access and copy: HR and admins see the whole record, and download documents and letter PDFs one at a time. There is no per-person export; we extract data manually on request.
• Correction: HR edits the record, and the new hire edits their own details until the first day; after that, details are corrected manually. A sent offer cannot change: only a new version can be sent, before acceptance.
• Erasure: HR can remove documents. There is no tool to erase one person's record; this is handled manually, case by case. Offer decisions and audit events cannot be deleted.
• Restriction: cancel the record, which closes the personal link, or revoke the link.
• Automated decisions: none are made.

“Manually” means an operator works on the database at the customer's written instruction, following a procedure agreed with counsel. [TO CONFIRM: that procedure, and whether it is charged.]

On request, we also help the customer with data-protection impact assessments and consultations with regulators, using the information in the DPA and its annexes.

Personal data breaches

We notify the customer without undue delay, and in any case within [X hours, counsel], after we become aware of a personal data breach affecting customer data. We give the information we have and add more as we learn it: what happened, the categories and approximate numbers of people and records, the likely consequences, and the measures taken or proposed.

Detection relies on operational alerts, the audit trail and checks that the database's protective triggers are in place. There is no dedicated intrusion-detection system [TO CONFIRM].

Records and audits

We keep a record of our processing activities where the law requires one [counsel], and give the customer the information it needs to show compliance: the DPA, its annexes, and the referenced documentation and test results.

The customer may audit our compliance once a year, or after a breach, with [30] days' notice, at its own cost and under confidentiality [counsel]. We first answer written questionnaires. We hold no third-party certification such as SOC 2 or ISO 27001 [TO CONFIRM]. See also Compliance.

Return, deletion and retention

• Return: before the agreement ends, the customer exports what it needs with the tools in the app: the CSV reports, and documents and PDFs one at a time. There is no export of the whole account.
• Deletion: on the customer's written instruction, or [X] days after the end, we first suspend the organization, which closes it to all users and personal links. Then we delete all of its records and stored files, and the accounts of users who belong to no other organization, within [30] days, and confirm it in writing. [TO CONFIRM: the final behaviour of the deletion tool.]
• Backups: deleted data remains in backups until they rotate out. We use backups only to restore the whole service after a disaster; if we ever do, we delete the customer's data again.
• We keep data longer only where the law requires it [counsel].

Retention schedule (summary of Annex IV)

Liability, precedence and term

• Liability follows the terms [counsel].
• For personal data, the DPA prevails over the terms.
• The DPA lasts as long as we process customer data.
• Governing law: [governing law].

Request the DPA

To sign the DPA, or with questions about it, write to privacy@dayoneflow.com. The Privacy notice explains how DayOneFlow handles personal data for the people who use it.