JobRoute AI Spend

Data Processing Agreement

Effective date: 13 November 2026

1. Parties and purpose

1.1 This Data Processing Agreement ("DPA") is between the customer named in the Order or that accepted the JobRoute AI Spend Terms of Service (the "Customer") and QueryNow Inc. of Dallas, Texas ("QueryNow").

1.2 It forms part of the agreement between them for JobRoute AI Spend (the "Agreement") and applies whenever QueryNow processes Customer Personal Data to provide the Service, including during a free trial and during a fixed-scope review. It applies without a signature when the Customer accepts the Agreement. A signed copy is available on request to privacy@jobroute.ai.

2. Definitions

• Data Protection Law: the laws on personal data that apply to the processing, including the EU General Data Protection Regulation ("GDPR"), the UK GDPR and Data Protection Act 2018, the Swiss Federal Act on Data Protection, and the California Consumer Privacy Act and other US state privacy laws where they apply.
• Customer Personal Data: personal data in Customer Data that QueryNow processes for the Customer.
• Data Subject: the person the Customer Personal Data is about.
• Personal Data Breach: a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Customer Personal Data.
• Sub-processor: a third party QueryNow engages to process Customer Personal Data.
• Controller, processor, business, service provider, contractor, processing and personal data have the meanings given in Data Protection Law. Terms defined in the Agreement, such as Customer Data, Connection, Workspace, Report, Order and Minimum Group Size, have the same meaning here.

3. Roles and instructions

3.1 The Customer is the controller of Customer Personal Data, or a processor acting for its own controller, and QueryNow is its processor. Under US state privacy laws the Customer is the business and QueryNow is its service provider or contractor. The account details of Authorized Users (work email, workspace role, sign-in records) are handled by QueryNow as a controller under its Privacy Policy, not under this DPA.

3.2 QueryNow processes Customer Personal Data only on the Customer's documented instructions. The instructions are this DPA, the Agreement, the Customer's settings and Connections in the Service, and any further written instruction the parties agree.

3.3 QueryNow will tell the Customer immediately if it believes an instruction breaks Data Protection Law, and may decline to follow that instruction.

3.4 The details of the processing are in Annex 1.

4. The Customer's responsibilities

The Customer is responsible for:

• having a lawful basis for the processing and for each Connection it makes;
• telling its employees and contractors about the processing, and consulting works councils or other employee representatives where the law requires it;
• carrying out any data protection impact assessment its law requires;
• having authority over each system it connects, including any vendor setting it changes so that usage can be matched to people;
• sending only the data the Service needs, and no names, special category data, government ID numbers or data about children;
• making any decision about a person through a person at the Customer, and never treating a Report as a score or ranking of an individual, as section 7.4 of the Terms of Service sets out.

5. QueryNow's commitments for this Service

5.1 Read-only access. Every Connection uses read-only access. Annex 1 lists what is read from each source. The Service does not read the content of prompts, chats, files or code in the Customer's AI tools or code repositories.

5.2 Keyed hashes. In roster, usage and output records, work emails, employee IDs, manager references and vendor logins are turned into keyed hashes as the records are read, before anything is saved. The hash is HMAC-SHA256, computed with a secret key held on QueryNow's servers together with the identifier of the Customer's Workspace, so the same person has a different hash in each Workspace. The readable value is never stored and is used only to match usage to the roster.

5.3 No names. Roster records have no field for a name or a date of birth, and no pay amount is stored. Names that an HR system or a file includes are dropped as the records are read. Roster, usage and output files are read into records when they are uploaded and are not kept.

5.4 Reports by role and group. No screen, PDF or export in the Service shows the AI use or output of one person, and the Service does not show or export identifier hashes or raw usage records. The only exceptions are records QueryNow provides to the Customer under section 9 or section 12.5.

5.5 Minimum Group Size. No figure in a Report describes fewer people than the Customer's Minimum Group Size. The default is 10. The Customer may raise it. QueryNow lowers it below 10 only on the Customer's written request, records the reason, and never sets it below 5. Annex 2, part E, describes how smaller groups are combined or withheld and the one limit that remains.

5.6 No individual scoring. QueryNow does not score or rank individual people on their AI use or output.

5.7 Limits on use. QueryNow will not try to identify individuals from hashes or Reports, will not combine Customer Personal Data with other customers' data, will not sell or share it, and will not use it to train AI models or for any purpose of its own, including to improve Role Data.

6. QueryNow personnel

QueryNow gives access to Customer Personal Data only to personnel who need it to provide, secure or support the Service, and only after they are bound by a duty of confidentiality.

7. Security

7.1 QueryNow implements and maintains the technical and organizational measures in Annex 2.

7.2 QueryNow may update those measures over time, provided the update does not reduce the overall protection of Customer Personal Data.

8. Sub-processors

8.1 The Customer gives general authorization for QueryNow to use the Sub-processors listed in Annex 3.

8.2 QueryNow will give the Customer at least 30 days' notice of a new or replacement Sub-processor, by email to workspace admins and by updating Annex 3 on this page.

8.3 The Customer may object on reasonable data protection grounds within that period. The parties will discuss the objection in good faith. If it cannot be resolved, the Customer may end the affected part of the Service and receive a refund of prepaid fees for the unused period.

8.4 QueryNow imposes on each Sub-processor written terms with, in substance, the same data protection obligations as this DPA, as far as they apply to the service that Sub-processor provides, and remains responsible to the Customer for each Sub-processor's performance.

8.5 The Customer's own AI vendors and HR systems that the Service reads from (for example Microsoft, GitHub, Anthropic, OpenAI, Workday and SAP) are the Customer's suppliers when they act as data sources. They are not QueryNow's Sub-processors in that role.

9. Data subject requests

9.1 If QueryNow receives a request from a Data Subject about Customer Personal Data, it will pass the request to the Customer without undue delay and will not answer it except to confirm that it was passed on, unless the law requires otherwise.

9.2 QueryNow will help the Customer respond. Because the Service holds no names, the Customer supplies the person's work email, employee ID or vendor login. QueryNow turns it into the same keyed hash and then finds, provides to the Customer, corrects or deletes the matching records, as the Customer instructs, without undue delay after the Customer's request.

9.3 QueryNow handles these requests through its support team. The Service has no in-product tool to find or delete the records of one person.

10. Personal Data Breach

10.1 QueryNow will notify the Customer of a Personal Data Breach without undue delay, and no later than 72 hours after QueryNow becomes aware of it.

10.2 The notice will describe, as far as then known, the nature of the breach, the categories and approximate number of Data Subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact for more information. QueryNow will send further details as they become available.

10.3 QueryNow will take reasonable steps to contain the breach and reduce its effects, and will help the Customer with any notice the Customer must give to authorities or Data Subjects.

10.4 The Customer decides whether to notify authorities and Data Subjects, unless the law requires QueryNow to do so itself.

10.5 A notice under this section is not an admission of fault.

10.6 Notices go to the workspace admins' email addresses and to any security contact the Customer names in an Order or in writing to QueryNow.

11. Impact assessments and consultation

QueryNow will give the Customer reasonable help with data protection impact assessments and with any prior consultation with an authority that relate to the Service, using the information QueryNow has. This includes this DPA, its annexes, the security page of the Service and written answers to reasonable questions.

12. Deletion and return

12.1 Deletion by the Customer. A workspace admin can delete data at any time in the Service, with two choices. The first deletes the AI spend data: usage, output, seats, matched logins and every Connection with its key or token. The second deletes that and the roster too, with its scores, role mappings, role documents and output measures. Both work after a trial ends or a license lapses. The workspace account, its license and its users stay until the Customer asks QueryNow to close the account or the Workspace is deleted under section 12.3 or 12.4.

12.2 Disconnecting. Disconnecting a source deletes QueryNow's copy of its key or token and, where the admin chooses, the data that source brought in.

12.3 End of a trial. QueryNow deletes the Workspace and its Customer Personal Data 30 days after the trial ends, unless the Customer places an Order first. A Workspace that never reaches a usable report is deleted 30 days after sign-up. Of the deleted Workspace, only the company email domain, the organization name and the dates of the sign-up are kept, to stop a second trial on the same domain. Backup copies expire as section 12.6 describes.

12.4 End of the Agreement or a subscription. QueryNow deletes Customer Personal Data within 30 days after the Agreement ends, or after a paid subscription ends without a new Order, unless the law requires QueryNow to keep it.

12.5 Return. On request before deletion, QueryNow provides the Customer's Reports and role-level tables as CSV or PDF files and, if the Customer asks, a copy of the Customer Personal Data it holds in a common machine-readable format such as CSV. Identifiers in that copy are keyed hashes, as they are stored.

12.6 Backups. Deleted data remains in encrypted database backups until those backups expire, which happens within 7 days. Until then QueryNow will not restore it except for disaster recovery, and will delete it again if it is restored.

12.7 On request, QueryNow confirms deletion in writing.

13. Audits and information

13.1 QueryNow will make available the information reasonably needed to show that it meets this DPA, including answers to security questionnaires and the measures in Annex 2.

13.2 QueryNow does not hold a SOC 2 report, an ISO 27001 certificate or any other security certification.

13.3 Where the information in section 13.1 is not enough, or an authority requires it, the Customer may audit QueryNow's compliance with this DPA once a year, on at least 30 days' notice, during business hours, at the Customer's cost, under a duty of confidentiality, and without access to other customers' data. These limits on frequency and notice do not apply to an audit that an authority requires, or that follows a Personal Data Breach affecting the Customer; such an audit may take place on shorter notice that is reasonable in the circumstances.

14. International transfers

14.1 QueryNow stores Customer Personal Data in the United States, as Annex 3 sets out. QueryNow does not offer hosting in any other region.

14.2 Where Customer Personal Data is transferred from the European Economic Area to QueryNow, the Standard Contractual Clauses approved by the European Commission in Implementing Decision (EU) 2021/914 apply, Module Two (controller to processor), or Module Three (processor to processor) where the Customer is itself a processor. They are incorporated by reference and completed as set out in Annex 4.

14.3 For transfers from the United Kingdom, the International Data Transfer Addendum issued by the UK Information Commissioner applies together with those clauses. For transfers from Switzerland, the clauses apply with the changes Swiss law requires, as set out in Annex 4.

14.4 If the clauses conflict with this DPA, the clauses prevail.

15. US state privacy laws

Where QueryNow acts as a service provider or contractor, it:

• processes Customer Personal Data only for the business purposes in Annex 1;
• does not sell or share it, and does not retain, use or disclose it outside its direct business relationship with the Customer;
• does not combine it with personal information from other sources, except as those laws allow;
• complies with those laws and gives the same level of protection they require;
• tells the Customer if it can no longer meet these obligations, and lets the Customer take reasonable steps to stop and fix unauthorized use.

16. Liability

Each party's liability under this DPA is subject to the limits in section 17 of the Terms of Service, except where the Standard Contractual Clauses do not allow a limit.

17. Term and order of precedence

17.1 This DPA lasts as long as QueryNow processes Customer Personal Data.

17.2 On personal data, this DPA prevails over the rest of the Agreement, unless an Order expressly changes a named part of this DPA. The Standard Contractual Clauses prevail over all of them.

Annex 1: Description of the processing

What each Connection reads

Annex 2: Technical and organizational measures

A. Data minimization and pseudonymization

• Keyed hashes (HMAC-SHA256, with a secret key held on QueryNow's servers and the Workspace identifier, so hashes differ between Workspaces) in place of employee IDs, work emails, manager references and vendor logins, applied as records are read and before any write.
• No name, date of birth or pay amount field in roster records. Names that a source returns are dropped as records are read.
• The preview of an uploaded usage or output file masks the columns that identify people, such as email and user ID columns, and any cell that holds an email address. Roster, usage and output files are not kept.
• No identifier hash or raw record is returned by the API to users or included in an export, apart from records QueryNow provides to the Customer under section 9 or section 12.5.
• Log lines for sign-up, connection and lifecycle jobs carry reason codes and counts, never an address, login or hash.

B. Access control and tenant isolation

• Every query is scoped to one Workspace, to keep each customer's data apart from every other customer's.
• Passwordless sign-in: a single-use link (stored only as a hash, valid for 15 minutes) issues a signed, httpOnly, secure session cookie that lasts up to 7 days.
• Two workspace roles, admin and viewer. Only admins can connect, disconnect, upload and delete.

C. Encryption

• HTTPS for all traffic, enforced for connector addresses in production.
• Data at rest in Azure Database for PostgreSQL, encrypted by default with Microsoft-managed keys, and database backups encrypted the same way.
• Every stored key or token is encrypted with AES-256-GCM envelope encryption: a fresh data key per record, wrapped under a master key held as an application secret in Microsoft Azure, outside the database, and bound to the Workspace and the Connection, so a copy moved to another Workspace or Connection does not decrypt. The Service refuses to store or read credentials if the master key is not configured.
• The hashing key and the master key are held as application secrets in Microsoft Azure, outside the database.

D. Connection security

• Read-only scopes only.
• Microsoft: the connecting person signs in with Microsoft and must hold an admin role in that directory, and the Connection is stored only when the directory in that person's validated ID token matches the directory that gave admin consent. A Microsoft directory already connected to another Workspace is refused.
• GitHub: the connecting person must be authorized for the installation and be an owner of the organization, and an installation already connected to another Workspace is refused.
• Outbound requests block private, loopback, link-local and cloud metadata addresses, re-check hosts against DNS rebinding and never follow redirects.

E. Reporting safeguards

• Minimum Group Size of 10 by default, raised by the Customer if it wishes, never below 5, and shown in the Service.
• A role is shown only when it has at least the Minimum Group Size of people on the roster, and usage detail inside a role needs at least that many active people.
• Roles under the minimum are combined into an "other roles" line, which is withheld if it is still under the minimum. Where a total is shown, further cells are withheld until a hidden group cannot be found by subtraction, or the total is withheld.
• Views allow one filter dimension at a time, so two filtered views of the same period cannot be subtracted to reveal a small group.
• Lines that are not a role (people not on the roster, logins not matched) are withheld when they hold fewer people than the Minimum Group Size rounded up to a multiple of 5, and are otherwise shown rounded down to a multiple of 5. The "other roles" line shows its headcount and role count only, never its active people.
• The remaining limit: the minimum is checked for each period on its own, so subtracting the figures of two periods that overlap can isolate the use of a small number of people, possibly one. The Terms of Service forbid the Customer from doing this to identify or assess an individual.
• Exports are the role table as a CSV file and the board page and one-page summary as PDF files, built from the same role-level figures as the screens.
• After a trial ends, file downloads are refused while reading, disconnecting and deleting still work.

F. Deletion

• In-product deletion of AI spend data, or of all Workspace data including the roster, available to admins at all times (section 12.1).
• Automatic deletion of ended trials 30 days after the end, and of trial Workspaces that never reached a usable report 30 days after sign-up.
• Keys and tokens deleted on disconnect.

G. Abuse controls

• Sign-up limits per address and per email domain. Free and disposable email domains refused. One trial per company domain.
• Rate limiting on the API.

H. Operations

• Database backups are made automatically by Microsoft Azure and kept for 7 days, and the database can be restored to a point in time within that period.
• Application logs are kept in Azure Monitor for 30 days.
• Access to Customer Personal Data is limited to QueryNow personnel who need it, under a duty of confidentiality (section 6).

I. Not in place today

• No SOC 2 report and no security certification of any kind.
• Sessions expire on a fixed schedule and cannot yet be revoked one by one on the server.
• No in-product tool to find or delete one person's records. Requests are handled by support (section 9).
• Single sign-on for customer users is not offered. Sign-in is by single-use email link.
• Customer-managed encryption keys are not offered.

Annex 3: Sub-processors

Two other providers support the Service without processing Customer Personal Data, and are listed in the Privacy Policy: Plus Five Five, Inc. (Resend), in the United States, sends sign-in links and service emails to Authorized Users, whose account details QueryNow handles as a controller (section 3.1); and Formspree, Inc. receives demo and contact requests, including a request to continue after a trial.

Annex 4: Standard Contractual Clauses

The Standard Contractual Clauses in section 14 are completed as follows.

• Clauses: Commission Implementing Decision (EU) 2021/914, Module Two, and Module Three where the Customer is a processor.
• Clause 7 (docking clause): included.
• Clause 9 (use of sub-processors): Option 2, general written authorization, with the notice period in section 8.2.
• Clause 11 (redress): the optional independent dispute resolution wording is not included.
• Clause 13 (supervision): the supervisory authority set by Clause 13(a) for the Customer, as data exporter.
• Clause 17 (governing law): Option 1, the law of Ireland.
• Clause 18 (choice of forum and jurisdiction): the courts of Ireland. Data Subjects may also bring proceedings in the member state where they habitually reside, as Clause 18(c) provides.
• Annex I of the clauses: Annex 1 of this DPA, with the parties as stated there. Annex II: Annex 2 of this DPA. Annex III: Annex 3 of this DPA.
• United Kingdom: the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses, version B1.0, issued by the Information Commissioner under section 119A of the Data Protection Act 2018. Table 1: the parties in Annex 1. Table 2: the modules and options above. Table 3: Annexes 1, 2 and 3 of this DPA. Table 4: either party may end the Addendum as its section 19 allows.
• Switzerland: where the Swiss Federal Act on Data Protection applies, the Federal Data Protection and Information Commissioner is the competent supervisory authority, references to the GDPR include that Act, and the term "member state" does not prevent Data Subjects in Switzerland from bringing claims where they habitually reside.

QueryNow Inc.
Dallas, Texas