Data Processing Agreement

Terms not defined here have the meaning given in the relevant data-protection law applicable to Customer's data subjects. Customer is responsible for identifying which regime(s) apply to its operations. This DPA is drafted to be compatible with:

• GDPR (EU Regulation 2016/679) + UK GDPR + Data Protection Act 2018
• NDPR (Nigeria Data Protection Regulation 2019) + Nigeria Data Protection Act 2023
• CCPA/CPRA (California Consumer Privacy Act + Privacy Rights Act)
• POPIA (South Africa Protection of Personal Information Act, 2013)
• LGPD (Brazil Lei Geral de Proteção de Dados, Law No. 13,709/2018)
• PIPEDA (Canada Personal Information Protection and Electronic Documents Act)
• Privacy Act 1988 (Australia) + Notifiable Data Breaches scheme
• PDPA (Singapore Personal Data Protection Act 2012)
• Data Protection Act 2019 (Kenya)

“Personal Data,” “Processing,” “Data Subject,” “Controller,” and “Sub-processor” have the meanings given in whichever regime applies to Customer's data subjects. References to specific Articles (e.g. GDPR Art. 28) apply mutatis mutandis where local-law equivalents exist.

• Purpose: to provide the TalentOS recruitment platform, including candidate sourcing, screening, pipeline management, interview scheduling, offer drafting, and analytics
• Categories of data subjects: Customer's employees, recruiters, hiring managers, candidates, applicants, and agency partners
• Categories of personal data: identification (name, email, phone), employment history, education, skills, interview notes, salary expectations, candidate-supplied documents (CVs, portfolios), and operational telemetry (IP address, user agent)
• Duration: for the term of the underlying agreement, plus any audit-retention obligations agreed in writing

1. Process Personal Data only on documented instructions from Customer, as provided through the platform's documented interfaces (API, web UI, configuration)
2. Ensure all personnel authorised to process Personal Data are under confidentiality obligations
3. Implement appropriate technical + organisational measures (Section 7)
4. Assist Customer in responding to Data Subject requests by providing the export + delete endpoints documented at /account
5. Assist Customer with breach notification (Section 9), DPIAs, and prior consultations with supervisory authorities
6. Make available all information necessary to demonstrate compliance with Article 28 GDPR / NDPR equivalents, including permitting audits on reasonable notice (Section 10)

Customer authorises the use of the following sub-processors, each of which processes a defined subset of Personal Data:

Vercel runs the application in Frankfurt (fra1) and Washington DC (iad1), but the Upstash Redis database behind it is a single database in one physical region, and uploads live in a single Vercel Blob store. Selecting a data region at /account pins Customer's preference and contractual commitment; it does not route records to a separate regional database, and the asia-southeast option is not deployed.

What Anthropic receives depends on the input. Text sent to the model passes through identifier scrubbing at every call site — on by default, and disablable per tenant — so names, emails and phone numbers are replaced before the request leaves the platform. CVs uploaded as PDF or image files cannot be scrubbed that way: the CV-parsing path sends the file itself to the model as a document or image block, unredacted, so Anthropic receives the complete candidate document. The audit row for each call records which of the two applied.

hCaptcha guards the public sign-up, login, agency-login and candidate application forms. Server-side verification sends the submitter's IP address to hCaptcha with the challenge token, and the widget itself loads from hCaptcha in the visitor's browser, so hCaptcha sees the IP address and user agent of every candidate who applies through a TalentOS careers page — not only Customer personnel. It receives no name, email address, CV or other application content.

This table is exhaustive as to sub-processors that receive Personal Data on the production deployment today. Anthropic, Vercel, Upstash, Resend and hCaptcha are live; Sentry is listed because the integration ships in the platform, but no Sentry credentials are configured in production, so it currently receives nothing. Destinations Customer configures itself — SIEM endpoints (Section 7) and outbound webhooks — are Customer's own processors, not TalentOS sub-processors.

TalentOS will provide Customer at least 30 days' notice before adding or replacing a sub-processor. Customer may object on reasonable grounds; the parties will negotiate a remedy in good faith.

Personal Data is transferred across borders in the ordinary operation of the platform (Section 5). The instrument relied on depends on the source jurisdiction; each is executed as a schedule to this DPA and none is in force until both parties have signed it:

• EU → outside EEA: European Commission's Standard Contractual Clauses (SCCs, Decision 2021/914) + Transfer Impact Assessment where required by Schrems II
• UK → outside UK: UK International Data Transfer Agreement (IDTA) or UK Addendum to EU SCCs
• Nigeria → outside Nigeria: NDPR Art. 2.11 compliant transfer (consent, adequacy, or contractual safeguards)
• South Africa → outside SA: POPIA s.72 compliant transfer (consent, adequacy, similar law, or BCRs)
• Other jurisdictions: equivalent safeguards approved by the source jurisdiction's supervisory authority

On request, TalentOS will execute jurisdiction-specific transfer addenda (e.g. EU SCCs, UK IDTA) as a schedule to this DPA. The Customer's data controller obligations under their home jurisdiction remain with the Customer.

• Encryption: TLS 1.3 in transit; at rest, records and uploaded files are encrypted by the storage services themselves (Upstash Redis, Vercel Blob) — TalentOS does not independently test or verify that mechanism
• File access: CVs, assessment submissions, portfolios, offer documents and message attachments are served only through the authenticated /api/upload/[id] route, which re-checks the session, the owning tenant, agency scope and MFA on every request and never redirects the caller to the storage URL. Only careers-site assets — tenant logo, careers-page imagery, and job descriptions attached to a public vacancy — are served from a public URL. The Blob store behind the current deployment is provisioned public-only, so sensitive files are still written with public access: their bytes are reachable by anyone who obtains the storage URL, and the protection is that the URL is unguessable and is never published or handed to a client. A private store is not yet provisioned.
• Access control: role-based access (RBAC) with per-tenant isolation enforced at every read + write
• Authentication: scrypt-hashed passwords with a per-record random salt, screened at set time against the Have I Been Pwned k-anonymity breach API; multi-factor authentication enforced server-side for the roles a tenant designates, applying to browser sessions (Bearer API keys are a separate credential class and are not MFA-gated); 14-day session tokens. Login, password-reset and sign-up are throttled per IP address by an in-process counter: on the serverless deployment each function instance keeps its own counter, so the effective limit is multiplied by the number of live instances and resets on cold start. There is no per-account throttle and no account lockout.
• Audit trail: a single platform-wide event list in Redis (key talentos:audit:list) holding the most recent 2,000 events across all tenants, trimmed to that cap on every write. It is not tenant-partitioned — tenant scoping is applied on read — and it is neither immutable nor tamper-evident: rows are rewritten in place to service erasure requests and tenant purges, and there is no hash chain or write-once storage. Because the 2,000-event cap is shared across the whole platform, Customer's events can be evicted by unrelated platform activity, so TalentOS commits to no retention window for the in-platform trail. Durable retention runs through Customer-controlled storage instead, by either of two routes: per-event streaming to Customer's own SIEM (Splunk HEC, Datadog Logs, or an HMAC-signed webhook) configured at /account, which is best-effort and at-most-once with no retry or replay; or CSV export (with token + cost data) from /api/audit/export, served inline or emailed as a background job. An export contains only the events still inside the 2,000-event window when it runs.
• Backups: none operated by TalentOS. The platform has no backup job, no snapshot schedule, no restore procedure and no import path — an export cannot be loaded back in. Records live in one Upstash Redis database and uploads in one Vercel Blob store; cross-region replication is not configured, and TalentOS neither tests nor verifies any durability mechanism those providers may apply by default. Deletion is immediate and irreversible: there is no soft delete or recycle bin anywhere in the platform. Customer needing a recoverable copy should take regular exports (Section 8) and retain them itself. TalentOS gives no RPO or RTO commitment.
• Vulnerability management: dependency scanning is configured in the repository — Dependabot plus a weekly npm audit workflow — but it is not running: the repository has no hosted remote, so neither has ever executed and no automated scan result exists. Review of dependency advisories is manual today. Security disclosures via security@talentosglobal.co
• Incident response: written runbooks covering security incidents, incident communications, on-call handling, candidate DSARs, tenant purge and key rotation. Sentry-driven alerting is implemented but not enabled on the production deployment (Section 5), so no automated error alerting is in place today; incidents are detected by manual review.
• Compliance posture: no SOC 2 report has been issued, no ISO 27001 certification is held, and no independent penetration test has been performed — there is no third-party audit report or attestation TalentOS can provide today. What is available on request is the operational runbook set described above; TalentOS holds no policy library, no data protection impact assessment and no record of processing activities, and has not appointed a Data Protection Officer.

• Right to access — per-candidate JSON bundle at GET /api/candidates/[id]/dsar/export (admin / CHRO / recruiter), plus the tenant-wide admin/CHRO export endpoint at /account
• Right to erasure — per-candidate erase at POST /api/candidates/[id]/dsar/erase and the admin tenant-delete endpoint at /account, both requiring the id to be echoed back as typed confirmation. Both are hard deletes: there is no grace period and no way to undo them (Section 7, Backups)
• Right to correction — direct edit through platform UI / API
• Right to data portability — JSON export (machine-readable, schema-versioned)
• Right to object / restrict processing — no in-product restriction or objection switch exists. The only per-tenant processing opt-outs implemented today are for the outbound job feeds (Indeed, LinkedIn). A restriction or objection has to be actioned operationally by Customer — for example by removing the record from active pipelines or erasing it — with TalentOS engineering assistance on request

TalentOS will respond to Customer-forwarded Data Subject requests within 5 business days where engineering support is required, materially assisting Customer to meet its 30-day NDPR / 1-month GDPR obligation.