A GDPR-first, employment-risk, AI-governance, and light-SOC-2 review of what must be true before Talent Marketplace is offered as an independent B2B beta.
The prototype presents named candidates, match percentages, capability ratings, evidence, recommendations, shortlists, and “not a fit” decisions. Yet the matching logic, candidate source and permission model, tenant controls, retention, and backend security are not present in this repository. Recruiter bearer tokens and hiring decisions are currently stored in browser localStorage. An internal demonstration using synthetic candidates may continue, but an independent customer beta requires the twelve gates below. A SOC 2 report is not a beta prerequisite.
This is a product-readiness assessment, not a certification, legal opinion, penetration test, or review of the unseen backend. The permitted beta boundary must be explicit.
Findings are based on the Talent Marketplace frontend at commit d1dabf08f38babc54b78132c2adbb22772060ffe. The platform backend, model or ranking implementation, production configuration, contracts, and operational evidence were not in scope.
| Area | Observed evidence | Beta implication |
|---|---|---|
| Strength | Invite-only signup, password rules, authenticated routes, shared auth/HTTP packages, typed API contracts, and Cloudflare deployment infrastructure. | Useful foundation; the server-side enforcement and shared packages still require evidence. |
| Strength | Production dependency audit reported zero known vulnerabilities on August 13, 2026. | Point-in-time signal only; private packages, configuration, code flaws, and future advisories remain in scope. |
| Blocker | Bearer access tokens are configured in JavaScript-readable localStorage, including a two-week “remember me” path. | An XSS flaw can become account takeover. Replace with hardened, revocable server sessions or an equivalent architecture validated by security. |
| Blocker | Saved and dismissed candidate IDs are persisted as saved-candidates and dismissed-candidates without user or tenant namespacing. | Employment decisions can persist across sessions and accounts on a shared browser, without audit, retention, correction, or tenant control. |
| Blocker | Company name, recruiter title, industry, state, target roles, preferred skills, and onboarding status are stored under company-context-state. | The browser is acting as the authoritative employer record. Account switching, shared devices, deletion, and evidence integrity are unresolved. |
| Blocker | Invitation tokens appear in /signup/:token and TanStack Query cache keys before verification and resend requests. | Tokens may reach browser history, screenshots, referrers, logs, or telemetry. They need single use, short expiry, URL removal, and redaction. |
| Blocker | The frontend consumes /api/v1/tmp/candidates data containing identity, location, score, recommendation, risk items, skills, evidence, portfolio slug, and capability indicators. | Source legitimacy, accuracy, model behavior, authorization, and correction cannot be validated from this repository. |
| Blocker | “Top 3 recommended,” match percentages, strong/moderate/limited indicators, shortlist, and “not a fit” are presented as hiring signals. | These outputs can materially influence employment decisions even if the interface does not automatically reject anyone. |
| Gap | No repository-level CSP or other response-header policy is visible; Vue devtools is included in the Vite plugin list for all builds. | Verify edge headers and production bundles; remove developer tooling and establish CSP, HSTS, frame, MIME, referrer, and permissions policies. |
| Gap | LaunchDarkly receives authenticated user context, Cloudflare observability is enabled, source maps are uploaded, and Google Fonts is loaded remotely. | Inventory transmitted fields, regions, retention, redaction, contracts, and transfers. Self-host fonts or document the legal basis. |
| Gap | PR E2E is disabled until a test secret exists; staging build does not visibly gate on unit tests, lint, or E2E. | Critical auth, tenant, invite, and candidate-decision journeys are not proven by the deployment workflow. |
The system combines observed and inferred professional information with employer preferences to evaluate suitability. That is more sensitive than an ordinary business-directory profile because it can affect access to work.
| Data group | Examples visible or implied | Required treatment |
|---|---|---|
| Recruiter and account | Name, email, password/account token, company, title, industry, state, invitations, login and security records. | Contract or legitimate interest as appropriate; account notice, security, retention, access and deletion. |
| Employer hiring context | Target roles, preferred skills, company criteria, searches, shortlists, dismissals, notes, and team activity. | Purpose limitation, tenant controls, access logs, retention, and customer instructions. |
| Candidate identity and work profile | Name, role, location, portfolio, projects, certifications, assessments, skills, and evidence dates. | Document source, candidate visibility choice, lawful basis, notice, accuracy, correction, expiry, and access recipients. |
| Inferences and decisions | Match score, recommendation, capability level, risk items, rank, shortlist, “not a fit,” and employer response. | Treat as profiling and consequential employment data; provide meaningful explanation, objection/correction, auditability, and human review. |
| Telemetry and security | Feature context, IP/device, event data, errors, logs, source maps, invite and request metadata. | Minimize and pseudonymize; prohibit secrets and candidate content; define retention and vendor transfers. |
The legal role must be assigned per processing purpose, not per product. Talent Marketplace is likely a controller for its own account security, product analytics, candidate discoverability design, and any matching model whose essential means it determines. An employer is the controller for its recruitment decision. Marketplace may be a processor for employer-only shortlists, workflow records, or notes processed solely under the employer’s instructions. The relationship with Skills Validation may involve the same legal entity or separate controller/processor responsibilities, but the architecture alone does not answer that question.
If the matching or ranking qualifies as an AI system, recruitment and candidate-selection use is an Annex III high-risk category, and profiling is especially difficult to exempt. Following the 2026 AI Omnibus, the current application date for stand-alone high-risk rules is December 2, 2027. The product should build the risk, data, documentation, logging, human-oversight, accuracy, robustness, cybersecurity, and post-market disciplines now.
A score or profile used for a solely automated decision with legal or similarly significant effect can be prohibited unless a narrow exception and safeguards apply. Even where Article 22 is not triggered, transparency, fairness, accuracy, lawful basis, DPIA, and objection rights still apply.
Title VII, the ADA, the ADEA, and selection-procedure rules apply when software makes or informs hiring decisions. Validate job relevance and business necessity, test adverse impact, provide disability accommodations, and assess less discriminatory alternatives. Employer use of a vendor does not remove employer liability.
NYC Local Law 144 can require an independent annual bias audit, a public summary, and advance notices before an automated employment decision tool is used. Colorado’s 2026 ADMT framework and rulemaking require a fresh launch assessment. Other states and cities need a maintained jurisdiction matrix.
| Document | Beta? | Required content |
|---|---|---|
| Beta service terms / order form | Yes | Named employers/users, beta limitations, permitted hiring purpose, support, suspension, changes, confidentiality, IP, liability, term/exit, and shared responsibilities. |
| Data Processing Addendum | Yes | Article 28 terms where Marketplace is processor, processing schedule, TOMs, subprocessors, transfers, rights/breach assistance, return/delete, and audit information. |
| Recruiter privacy notice | Yes | Account, security, product, feature flag, support and telemetry processing; bases, recipients, transfers, retention, rights, and contacts. |
| Candidate privacy and AI notice | Yes | Profile source, discoverability, employer recipients, matching purpose, major criteria, score limitations, retention, corrections, objection/appeal, and human review. |
| Employer acceptable-use and anti-discrimination schedule | Yes | No sole reliance, unlawful screening, protected-trait targeting, scraping, re-identification, credential sharing, export/resale, or non-hiring use; accommodation and notice duties. |
| Matching system factsheet / instructions | Yes | Intended purpose, inputs, outputs, validation population, metrics, limitations, prohibited uses, human oversight, version, monitoring, and incident/appeal contacts. |
| Candidate participation and portfolio terms | Yes | Visibility controls, license to display content, evidence accuracy, employer access, withdrawal, correction, IP/takedown, and consequences of deleting source evidence. |
| Subprocessor and transfer list | Yes | Vendor, purpose, data, region, retention, transfer mechanism, safeguards, and change-notification method. |
| Security overview / TOM schedule | Yes | Accurate system boundary, access, tenancy, encryption, SDLC, vendors, monitoring, backup, incident, retention, and customer responsibilities. |
| Bias-audit and jurisdiction disclosures | By region | NYC audit summary and notices where covered; current Colorado and other state/local notices, impact assessments, and appeal requirements. |
Do not add background checks, credit or criminal records, health/disability questions, biometrics, video/emotion analysis, citizenship or protected-trait inference, children, or candidate-contact automation without a separate legal and product assessment. If consumer reports are later used, assess Fair Credit Reporting Act obligations before design or procurement.
_tmp.auth._token.local and _tmp.auth._token_expiration.local with the approved hardened session architecture.saved-candidates, dismissed-candidates, and authoritative company-context-state records to secure tenant APIs. If an onboarding draft remains local, minimize it, namespace it, expire it, and clear it on logout/account change.history.replaceState or router replacement to remove them; set Referrer-Policy: no-referrer on the invite flow.vite-plugin-vue-devtools from production builds and prove edge security headers on staging and production.Candidate discoverability should expire or be reconfirmed; stale skill evidence should be visibly dated and excluded from current matching when no longer reliable. Employer searches, shortlists, dismissals, explanations, audit records, notices, and appeals need separate periods based on recruitment need and legal claims. Deleted source evidence must stop influencing future matching. Backups require a fixed rolling expiry and documented restoration handling. Telemetry should be retained for less time than core product records.
The response plan must cover confidentiality incidents and harmful model behavior. Record discovery time, affected candidates/employers, data/model versions, containment, evidence preservation, regulatory/customer notice, candidate communications, and remediation. As a processor, notify controllers without undue delay. As a controller, preserve the ability to meet the GDPR 72-hour authority deadline where applicable. A bias or scoring incident needs the same named ownership, rollback, impact analysis, and post-incident correction discipline as a security incident.
SOC 2 is a CPA examination of controls, not legal compliance, certification, or a substitute for GDPR and employment-law work. The beta needs evidence discipline, not an immediate audit purchase.
| Control family | Light beta practice | Evidence |
|---|---|---|
| CC1-CC2 Governance | Name security, privacy, product, model, and employment-risk owners; approve concise policies; train staff and employer admins. | Approvals, responsibilities, training, customer instructions. |
| CC3 Risk assessment | Maintain one product risk register covering privacy, discrimination, model, security, vendors, and jurisdiction. | Risk entries, DPIA/AI assessments, owners, due dates, acceptance. |
| CC6 Access controls | MFA, least privilege, tenant authorization, session hardening, access approval/offboarding and review. | Configurations, approvals, negative tests, review exports, session evidence. |
| CC7 System operations | Monitor alerts, vulnerabilities, model quality and fairness; run security and harmful-output incident exercises. | Scans, alerts, dashboards, incidents, tabletop results, remediations. |
| CC8 Change management | Peer review, automated tests, controlled deployment, model/version approval, rollback and emergency changes. | PRs, CI, deployment/model registry, approvals, rollback records. |
| CC9 Vendor risk | Tier and review Cloudflare, LaunchDarkly, identity, hosting, Skills Validation, portfolio, support, and other processors. | Vendor register, DPAs, transfer terms, reviews, renewal/exit decisions. |
| Processing integrity design | Define score semantics, data lineage, validation, completeness, correction propagation, and employer-facing limitations. | Model factsheet, tests, reconciliations, correction and appeal logs. |
| Window | Outcome | Work |
|---|---|---|
| Days 0-30 | Contain the prototype and define the decision system | Keep candidate data synthetic; name owners; document system/data/model boundary; decide candidate source and discoverability; classify legal roles and jurisdictions; start DPIA/Article 22/AI Act/US assessments; inventory vendors and telemetry; draft beta prohibitions and risk register. |
| Days 31-60 | Implement privacy, model, and security controls | Harden sessions/invites; move employer context and decisions server-side; prove tenant isolation; implement notices/rights/retention/audit; document and validate matching; test adverse impact and accessibility; approve terms, DPA, notices, factsheet and customer instructions; enable CI gates and restore/incident tests. |
| Days 61-90 | Run a named-employer pilot with continuous evidence | Close jurisdiction requirements and independent audit where required; sign documents; activate only approved candidates/employers; rehearse correction/appeal/deletion; monitor score quality, disparities, access, incidents and complaints; review every model change; hold weekly risk review and retain release evidence. |
A real-data beta begins only when legal, privacy, security, product, and model owners sign a one-page release record linking every gate to current evidence. Any open blocker keeps the decision at no-go. Medium residual risks require a named accepting owner, a deadline, and a beta-specific containment. A customer contract cannot transfer away the product’s own controller, security, accuracy, or discrimination responsibilities.
| Evidence | Owner | Pass condition |
|---|---|---|
| Beta scope, geography, customer and prohibited-use record | Product / Legal | Named employers and candidate population; no ambiguous automated-decision use. |
| System/data map, RoPA, role matrix, LIA and DPIA | Privacy / Engineering | Approved, dated and matches production fields, vendors, regions and flows. |
| Candidate source, visibility, notice and content-rights evidence | Product / Privacy | Every profile has an attributable source, basis, notice, expiry and correction route. |
| Model/rule factsheet, code/version, validation and limitation record | Model / Product | Job relevance, metrics, failure modes, data lineage and change controls approved. |
| Fairness, accessibility, accommodation and jurisdiction results | Legal / Model | No unresolved material disparity; alternatives assessed; required audit/notices complete. |
| Human oversight, explanation, correction and appeal rehearsal | Support / Product | A trained reviewer can explain, pause and change a result within target time. |
| Terms, DPA, notices, AUP, factsheet, TOMs and subprocessors | Legal / Privacy | Approved versions and signed customer acceptance before access. |
| Session, invite, MFA, tenant and audit-log evidence | Engineering / Security | Hardened configuration plus passing cross-tenant and account-switch tests. |
| Telemetry, headers, dependency, secret and vulnerability evidence | Security / Engineering | No tokens/candidate PII in telemetry; no open critical/high issues; production headers proven. |
| Backups, restore, incident and harmful-model tabletop | Platform / Security | Successful restore and exercises with gaps owned and dated. |
| Beta release and monitoring record | Product / Legal / Security | All gates closed; thresholds, rollback, residual risks and reviewers signed. |
src/main.ts, src/router/index.ts, src/services/auth.service.ts, signup/login components, useCompanyContext.ts, useSavedCandidates.ts, candidate services/types/cards/details/dashboard, onboarding and hiring-context components, architecture.md, vite.config.ts, index.html, wrangler.toml, Terraform and Cloudflare workflows, E2E workflows and Playwright strategy material, dependency manifests, and the production dependency audit.