Data Processing Agreement

1. Parties and scope

This Agreement supplements the Terms of Service between JStar Technologies Pty Ltd ("Processor") and the customer ("Controller"), and governs Processor's processing of personal data on Controller's behalf.

The Processor's registered number and address, governing law and jurisdiction, and whether this is a standalone agreement or an annex to the Terms, are to be completed.

2. Roles

Controller determines the purposes and means of processing candidate and recruiter personal data. Processor processes it only on Controller's documented instructions.

Processor acts as an independent controller for a narrow, separable set: account administration, billing, and security telemetry about Controller's own users. That data is not candidate data. The exact boundary of this carve-out is to be confirmed.

3. Subject matter, duration, nature and purpose

Subject matter. Provision of an applicant tracking system.
Duration. The term of the Terms of Service, plus the deletion window in section 9.
Nature and purpose. Storing, organising, retrieving, analysing and transmitting personal data for recruitment: candidate management, pipeline progression, communication, automated match scoring, scheduling, reporting and data portability.

Categories of data subject

Candidates and applicants; Controller's own personnel (recruiters, hiring managers, administrators); contacts at Controller's client organisations; and — where Controller enables sourcing — individuals whose public professional profiles are retrieved from third-party sources and who have not applied.

Categories of personal data

Identity and contact details; CV and résumé content, including free text supplied by the data subject; employment and education history; skills and certifications; application and pipeline status; recruiter assessments, notes and interview scorecards; email and message content within connected threads; calendar entries for interviews; automated match scores and their explanations; and authentication data for Controller's own users.

Special categories and equivalent

Processor does not require special-category data. Two classes may nevertheless be present, and both are isolated by design:

Voluntary self-identification data. Collected only where Controller enables the AI-governance module and an organisation owner switches self-identification on, and only from candidates who volunteer it. It is held in a dedicated table that the candidate record cannot reach, and that reaches the candidate record only to be deleted with it, is never given to the scoring model, and is readable on recruiter-facing surfaces only as aggregates with small groups suppressed; the organisation owner's export of the whole workspace contains the individual answers.
Right-to-work declarations and compliance documents. Passport, visa and permit scans, and a candidate's self-declared right-to-work status. Not special-category data as such, but identity-document scans warrant equivalent handling, and work-authorisation status can proxy national origin — so it is excluded from the scoring model by design.

Whether a data protection impact assessment is a precondition to offering either module is to be confirmed with counsel.

4. Controller instructions

Processor processes personal data only on Controller's documented instructions, which comprise this Agreement, the Terms of Service, and Controller's own configuration of the service — including which integrations and sub-processors it enables. Processor informs Controller if an instruction appears to infringe applicable data-protection law.

5. Confidentiality

Personnel authorised to process personal data are bound by confidentiality obligations. The specific obligation relied on is to be referenced.

6. Security measures

Processor implements the measures in Annex A below. Annex A describes controls that exist in the software. It is not an audit result and asserts no certification.

7. Sub-processors

Controller gives general written authorisation for Processor to engage sub-processors. The current register is published at /legal/subprocessors.

Sub-processors are engaged in three ways, and the register says which applies to each. Hosting, the database and log collection are engaged whenever the service runs. Others are engaged by Processor's configuration of the deployment: file storage and backups on the storage service the deployment configures; a third-party service such as the AI, email or payment provider, which processes nothing until Processor supplies its credentials for that deployment, without which the service runs on local fallbacks; and the operations directory, which is configured once for the whole deployment. For each deployment the register records whether each one is engaged, not configured, or still undecided. The rest are engaged only by a choice made in Controller's workspace: a recruiter connecting their own Google or Microsoft account, Controller switching on paid WhatsApp and SMS messaging, or Controller registering its own webhook endpoint.

Processor gives Controller notice before adding or replacing a sub-processor that processes candidate data, on the sub-processor change feed, an Atom feed at /legal/subprocessors/feed, and Controller may object on reasonable data-protection grounds. The notice period and the objection and escalation mechanism are to be completed.

8. Data-subject rights

Processor assists Controller in responding to data-subject requests. The service provides:

Access and portability — per-candidate export, on the Professional plan and above, and a full workspace archive of the records and the stored files they reference.
Rectification — candidate records are editable throughout.
Erasure — a per-candidate erasure path that removes the candidate's records and stages a durable, retried deletion obligation for each stored file, which a deletion worker then carries out by the file's exact version identifier. Erasure itself records an obligation, not an accomplished deletion; see the limitations below. It acts on the candidate record chosen: another record of the same person in the workspace, such as a second application, is not erased with it, and the Service reports how many records share the erased record's email address or phone number or were copied from the same source record.
Restriction and objection — consent withdrawal, which suppresses further contact, retracts in-flight submissions to client organisations, and reaches the search index.
Automated decision-making — every automated score of an applicant or a candidate against a role, and every rubric score of a sourced profile, is recorded with the model, a content-hashed prompt version, the signals the model saw, and a redacted rationale; the similarity ranking that orders a sourcing run's profiles before they are scored is stored with them, stands as the score of a profile the rubric did not score, and is not recorded as a decision. Every human decision that departs from a recommendation is recorded.

Known limitations — disclosed, not drafted around.

Erasure completes for a candidate who holds an email-thread attachment: the candidate's records are removed and a durable, retried deletion obligation is recorded for the attachment, as for every other stored file. The deletion worker then deletes an attachment stored with a version identifier — every one a deployment stored once it ran the code of 26 September 2026 — by that identifier; one stored earlier is the limitation described below.

For a candidate who holds a compliance document, the outcome depends on one setting Controller must record for its workspace: the period for which it keeps compliance documents. While no period is recorded, erasure is refused for that candidate; while the period is running, erasure is refused (the Service does not yet show the date it lapses); once it has elapsed, a durable deletion obligation is recorded for the document, as for every other stored file, and carried out by the document's version identifier if it was stored once the deployment ran the code of 26 September 2026. The setting has no default, so a workspace where nobody has recorded one refuses erasure for such a candidate — the service does not choose the period on Controller's behalf.

Where the candidate-portal pilot is switched on for a workspace, erasure is refused for a candidate who applied through it — who holds a portal application, account relationship or consent record — because the anonymisation that would dispose of that evidence under a recorded retention reason is not yet built. The refusal is recorded and nothing is deleted. The portal is off unless it is enabled for a workspace.

Deleting a whole workspace records a durable deletion obligation for every stored file, in the same operation that deletes its database rows, and keeps that record so the remaining files stay reconcilable. A completed obligation means the automated work finished; it does not prove that every stored object is gone.

Every file a deployment stores once it runs the code of 26 September 2026 is written with the version identifier its storage returned, and the deletion worker deletes it by that identifier, only while the identifier still matches, so a different file later written under the same name is never removed in its place — including, since 28 September 2026, the candidate-portal pilot's quarantine store on local disk, which records a digest of the bytes it writes; a quarantine file that store wrote before then has no version identifier and is treated as the older files described next. That deletion has been tested against local disk; it has not yet been run against the live Cloud Storage service a production deployment uses. A file stored before then — which a deployment holds only if it carries data written then — is kept without a version identifier. For such a file Processor cannot prove that the object now at that name is the one the erasure request names, so it declines to delete it rather than destroy a file it cannot identify: the obligation is recorded and re-refused on every retry, and the bytes are retained. No operator procedure for completing these obligations is in operation yet. Such a file's record names no storage location, so finding nothing where the deployment stores files now does not show that the file is gone: since 28 September 2026 that does not close the obligation, which is escalated for an operator instead. A production release is refused while the deployment holds such a file.

Since 27 September 2026 an erasure reduces the candidate's do-not-contact entries, email and phone, to a keyed digest that no longer holds the address or number and still stops the candidate being contacted, for as long as the key that made it is kept; deletes the outbound webhook deliveries about the candidate that have not been sent — including one a node still on the previous version staged during a deployment, which the erasure finds by the candidate its body names, and any that a node on the current version would send later, since it checks for a record of the erasure immediately before every send; one a node still on the previous version sends before it stops still goes, with its body — and removes the body of those already delivered or abandoned; removes the sourcing records the candidate was created from, and the person's other sourcing records found by the profile address the candidate came from unless one became another candidate still in the workspace, with their search vectors; and deletes the candidate's own sign-in account when no other record in the workspace holds its address. An outbound email that could not be delivered no longer keeps its recipient. Since 28 September 2026 an erasure also keeps a record of itself — the candidate's internal identifier and keyed digests of the email address, phone number and profile addresses it reached, never the values — so that restoring an older archive of the workspace does not bring the candidate back; no retention period for that record is settled, and it is kept until one is. Since 29 September 2026 a copy of that record, and a record of each consent withdrawal and opt-out, holding the candidates' internal identifiers and keyed digests only, is also written outside the database to the deployment's backup storage, so that a restore of the whole database can re-apply them before it serves anyone; how long those copies are kept is set by the deployment and is not yet settled.

Some copies still outlive their erasure: a message or webhook already delivered to its recipient; an interview event already placed in a recruiter's connected Google or Microsoft calendar, which stays in that calendar; the security-audit trail, which keeps internal identifiers, the network address and browser identification recorded with every audited action (sign-ins, and actions such as the candidate's own unsubscribe) and any reason a recruiter typed when overriding the hire guardrail or converting a candidate to staff, which can name the person — and, in a record written before 27 September 2026, an email address, a phone number or the name of the person signing in — because the append-only trail has no settled retention period; the copy a partner workspace received of a candidate submitted to it, when the partner-network pilot is on; and backups, until they expire.

The metadata row that outlives a disposed file — a storage object name and, where one was learned, a digest and a length — is retained with no settled retention basis, so complete metadata erasure is not claimed.

Until these are resolved, the manual procedure and remediation date that apply are to be completed, and this agreement does not assert unqualified erasure.

9. Return and deletion

On termination, Controller may export its data through the service. Processor then deletes it, except where retention is required by law. The deletion window, and the separate period after which backups expire on their own schedule, are to be completed — and depend on the section 8 limitations being resolved first.

10. Audits

Processor makes available the information necessary to demonstrate compliance, and allows audits at reasonable frequency and on reasonable notice. Frequency, notice, cost allocation, and whether a third-party report may substitute, are to be completed.

No SOC 2 or ISO 27001 audit has been performed, and none is referenced anywhere in this agreement.

11. International transfers

The transfer position depends on the hosting region and the configured sub-processors, several of which are US-headquartered. The transfer mechanism, the transfer impact assessment, and any applicable addendum are to be completed.

12. Breach notification

Processor notifies Controller without undue delay after becoming aware of a personal-data breach, with the information available at the time. The notification deadline, contact channel and content are to be completed.

13. Liability

Caps, carve-outs and indemnities are to be completed, and must align with the Terms of Service.

Annex A — Technical and organisational measures

Each item is a control that exists in the software, not a plan, re-verified control by control against the code on 28 September 2026. Where a control depends on how a deployment is configured, that is stated; the production deployment does not exist yet, so no such control has been verified against it.

Workspace isolation

Workspaces are isolated from one another two independent ways: application-level query filters, and database row-level security enforced on every workspace-owned table. Per-record ownership checks then govern which member of a workspace may change which record. The application connects as a database role provisioned to be neither a superuser nor able to bypass row-level security, and not to own the schema — the deployment's provisioning scripts set that; outside development it refuses to start when its role is a superuser or can bypass row-level security. That the role does not own the schema is not checked at start, and a start at which the check cannot run logs a warning and continues. A test derived from the data model asserts that every workspace-owned table carries an active policy, and it runs against a real database.

Encryption

In transit. Plain HTTP is redirected to HTTPS — by the load balancer that the Google Cloud deployment kits configure, and by the application itself only where it is configured with its HTTPS port. A one-year strict-transport policy including subdomains is configured and is emitted where the deployment terminates TLS at the application, or terminates it at a reverse proxy the application has been configured to trust; a deployment that has not configured that trust does not send the header. Processor does not represent that the strict-transport policy reaches browsers in every deployment configuration.
Candidate contact fields at rest. Four fields are sealed with randomised AES-256-GCM through a dedicated key ring, separate from the framework's key ring: a candidate record's email address and phone number, the phone number on a candidate's own portal profile, and the phone number a CV parse extracts. Lookups use keyed blind indexes rather than decrypting. Outside development the application refuses to start without that key ring. Other copies of a candidate's contact details are held in the clear in the database, and Processor does not represent them as encrypted: the sign-in account an application or the candidate portal creates, which holds the email address; the opening text of the CV kept with the record, which usually holds both, and the parsed profile, which can; an address or number on the do-not-contact list while a record still holds it; an email waiting to be sent, which holds its recipient's address; the contact details revealed for a sourced profile; the number on a WhatsApp or SMS send log; message and note text; the address a Google Drive import parsed and a candidate-portal sign-in challenge's address, where those pilots are on; and security-audit records written before 27 September 2026.
Files at rest. Every uploaded CV, attachment and compliance document is encrypted at the storage boundary before it is written, in every storage mode, under the same key ring. The quarantine partition fails closed — it refuses to write rather than write unprotected, in every environment.
Backups. Sealed with an authenticated envelope bound to the workspace and archive name when a backup encryption key is configured: outside development a deployment that writes backups to cloud storage refuses to start without one, and the production manifest configures one; a backup written to the application host's own disk is sealed only if a key is set. Where a key is configured, a backup without that envelope is refused on read unless an operator explicitly opts in.
Scope limit, stated deliberately. The framework key ring that protects session cookies and stored OAuth tokens is held in the database and is encrypted at rest only where a deployment supplies a certificate for it. Outside development a deployment without one refuses to start unless an operator explicitly accepts an unencrypted ring, and key-ring entries written before a certificate was configured are not re-protected. Processor does not represent that all key material is encrypted at rest.

Access control

Role-based access with per-record ownership. Four separate authentication boundaries — internal staff, API keys, employer-portal contacts and candidate-portal users — none of which can satisfy another. Optional two-factor authentication with an authenticator app and recovery codes. A workspace can require it, and the requirement is enforced on every request: a member who has not set it up is sent to set it up and can use nothing else until they do — only signing in and out and the setup and account-security pages stay open to them — and the workspace's access review lists them. Account lockout after repeated failures. API keys are stored only as a hash. Every key is limited to the operations selected when it is created, and a key cannot be created with none; keys that had been created with none, which could then call every API endpoint, were each given the operations that existed at the time, listed on the key. A key changes a record only as the named person it was issued for, never as a workspace administrator.

Audit logging

Append-only and tamper-evident: every entry carries a chained SHA-256 hash. Updates are blocked by a database trigger on every deployment and revoked from the application's role by the deployment's provisioning scripts, and deletion requires an explicit session opt-in used by three named code paths. A verifier walks every chain once a day by default and writes each chain's head hash to the application log, so a truncation of a chain's newest entries can be detected by comparing it with a head written earlier. That comparison is not automated, and how long the log is kept is the deployment's.

Data minimisation and retention

A daily retention pass — on by default, and a production process refuses to start with it switched off — deletes each category below on its own configurable window: activity records, notifications and message threads (90 days by default); un-imported sourced profiles, sourcing decisions and WhatsApp and SMS send logs (30 days by default); and CVs uploaded to an application form that was never submitted, on a period that has no default and that a production process must be given before it will start. Candidate data supplied by Controller is retained for the term, since Controller determines its retention.

Automated decision-making safeguards

The dedicated name field is omitted from the scoring prompt, but résumé text may contain identifying information: the prompt carries the résumé summary, the first 800 characters of the CV, which usually hold the candidate's name and contact details. The prompt never receives self-identification data or work-authorisation status. The model is instructed not to use a name or any other protected attribute, which does not guarantee that it does not. The ranking of sourced profiles likewise omits the profile's name field, while the scraped text it carries may contain identifying information. Every automated score — including a score produced by the deterministic fallback when the model is unavailable — is recorded with the model (or "templated"), a hash of the prompt wording, the score and its band, the job-relevant signals the model was given, and a rationale from which contact details and the candidate's own name are removed; the records are erased with the candidate. Where a workspace uses the fairness report — a pilot that is switched off in the production configuration — adverse-impact statistics suppress small groups and defend against recovering them by subtraction, and the report is prevented in code from ever concluding "no bias found".

Development practices

Nullable-reference analysis; two automated test tiers, one of which runs against a real database under a least-privilege role; and structural tests that detect when a required security check is absent rather than merely wrong.

Processor does not assert any of these as a CI-enforced gate, and does not assert automated dependency-vulnerability gating or static analysis at all. All of those workflows exist in the repository, but as of 24 August 2026 every continuous-integration job was refused at start by an exhausted build-minutes budget and the default branch carries no protection rule requiring them — so "fails the build" would describe what the tests are written to do, not a control that was running. Annex A states only what is operating.