Sourcing Data Acquisition Policy

​

Purpose

Establish the lawful-basis, source-vetting, ingestion, retention, and review obligations for any data source that contributes Personal Data to the Sourcing Database — the aggregated database of professional-profile information about Candidates curated and maintained by Neuroscale on its own behalf as controller within the meaning of GDPR Art. 4(7), the CCPA / CPRA “business” definition, and analogous state-law definitions. The Sourcing Database is distinct from Customer Content: Customer Content is governed by the DPA Template and the controller/processor allocation described in the Privacy Notice. The Sourcing Database is governed by this policy and by Privacy Notice §2.5.

​

Scope

All upstream data sources — public-web profiles, licensed business-information vendors (including People Data Labs, RocketReach, Kickbox, NumVerify, and any future vendors), Customer-authorized integrations, and any other sources — that contribute Personal Data to the Sourcing Database, plus the suppression-list infrastructure that enforces Candidate opt-outs against future re-ingestion.

​

Lawful basis

Neuroscale processes the Sourcing Database on the basis of its legitimate interests under GDPR Art. 6(1)(f) and UK GDPR Art. 6(1)(f), balanced against the rights and freedoms of Candidates. The legitimate interest pursued is the operation of an AI-powered recruiting platform that helps employer-customers identify and engage potential candidates. The General Counsel maintains a written Legitimate-Interest Assessment (LIA) in the SharePoint Compliance folder covering:

1. The legitimate interest pursued (what; for whom; how it benefits Candidates indirectly).
2. The necessity test (whether the legitimate interest can be achieved with less Personal Data; whether less-intrusive means are reasonably available).
3. The balancing test against Candidate rights and freedoms — including the reasonable expectations of EU/UK/Swiss Candidates with public professional profiles; the safeguards Neuroscale applies (suppression list, Art. 14 notice, opt-out path, deidentification before training); and the limited categories of Personal Data ingested.
4. A per-source ToS review memo and a CFAA / California CDAFA risk note (see “Source vetting” below).
5. Source-removal / opt-out signal honoring (robots.txt, ai.txt, per-publisher opt-out lists; the Neuroscale suppression list described below).
6. Annual re-review trigger and material-change triggers.

For Personal Data of EU, UK, and Swiss Candidates, the GDPR Art. 14 indirect-collection notice obligation attaches; the standalone notice is published at /public/art-14-notice and is cross-referenced from Privacy Notice §2.5. Special-category data within the meaning of GDPR Art. 9 is not knowingly ingested into the Sourcing Database. Where a source emits special-category data inadvertently (e.g., trade-union membership inferred from a profile), the field is dropped at Stage 1 ingest and is not stored.

​

Source vetting (performed before any new source contributes)

The General Counsel signs off on source admission to the Sourcing Database. Each source requires the following diligence, retained for the life of the source + 6 years:

​

Public-web sources

• Source-platform Terms of Service review. Memo summarizing the source platform’s ToS as in force on the admission date and on every material amendment thereafter; explicit analysis of any restriction on automated collection, account creation requirements, and AI-training restrictions.
• CFAA / CDAFA risk analysis. Written analysis under 18 U.S.C. §1030 and Cal. Penal Code §502, informed by hiQ Labs, Inc. v. LinkedIn Corp., 31 F.4th 1180 (9th Cir. 2022), and successor cases. Public-data scraping is permissible where access does not require circumventing authentication; the memo documents that determination.
• robots.txt / ai.txt honoring. The ingest pipeline honors robots.txt and ai.txt directives at the source domain, with violations logged and escalated.
• EDPB scraping guidance. Where the source platform reaches EU residents, the memo references EDPB scraping/web-sourcing position statements and explains how Neuroscale’s controls align.

​

Licensed business-information vendors

• Executed DPA + SCCs (and UK IDTA where applicable). Vendor’s DPA must include (a) a no-training carve-out prohibiting the vendor’s re-use of identifiers submitted by Neuroscale for the vendor’s own model training; (b) sub-processor disclosure; (c) vendor’s own GDPR Art. 6 lawful basis documented in the vendor’s privacy posture.
• Vendor risk diligence. Per the Vendor Risk Assessment Procedure; higher tier for vendors that emit identified profile data than for vendors that emit anonymized analytics.

​

Customer-authorized integrations

• Customer instruction in DPA + scope of authorization in product UI. Customer integrations (ATS, CRM, calendar, email) are governed by the executed DPA and the customer-side authorization captured in the product UI; data flowing into the Sourcing Database from a customer-authorized integration is admitted only with Customer instruction and is subject to the Customer’s onward representations.

​

Ingest controls

The Sourcing Database ingest pipeline applies the following controls at the boundary:

• Provenance metadata. Each record captures source identifier, ingest date, source-ToS version-at-ingest, and a flag indicating whether the record was contributed by a Customer-authorized integration.
• Stage 1 redaction at ingest. Under-16 records are dropped at Stage 1 ingest (not at Stage 4 deidentification) per defense-in-depth requirements of the AI Acceptable Use Policy. Special-category data fields (within the meaning of GDPR Art. 9) are dropped at Stage 1 unless an explicit lawful basis exists.
• Suppression-list match. Each incoming record is hashed and matched against the Sourcing Database suppression list before being committed. Matched records are dropped and the suppression-list entry is incremented to record the suppressed attempt.
• Deidentification for training. Records flowing from the Sourcing Database into model-training corpora pass through the 6-stage Deidentification Standard documented in the AI Acceptable Use Policy. Raw Sourcing Database records are retained for product use only.

​

Retention

Per the Records Retention Schedule:

• Per-Candidate records: 24 months from last-verified-public-source date, unless extended for legal hold, active dispute, or a documented legitimate-interest extension signed by the General Counsel.
• Suppression list (hashed identifiers): indefinite (required to enforce the opt-out against future re-ingestion).
• Source-vetting evidence (ToS memo, CFAA/CDAFA risk note, executed DPA): life of source + 6 years post-termination.
• LIA and Art. 14 notice (current and prior versions): indefinite for the current version; superseded versions archived for 6 years.
• Removal-request log: 7 years from request resolution.

​

Art. 14 notice (Indirect Collection)

For Personal Data of EU, UK, and Swiss Candidates, the Art. 14 indirect-collection notice is satisfied through:

1. The standalone Art. 14 Indirect Collection Notice, persistently published.
2. The cross-reference at Privacy Notice §2.5.
3. At-first-contact disclosure when an outreach communication is initiated to a Candidate through the Arbi service (the AI-agent disclosure required by EU AI Act Art. 50 and SB 1001 includes a link to the Art. 14 notice, ensuring the notice is provided “at the latest at the time of the first communication to the data subject” per Art. 14(3)(b)).

Where Neuroscale relies on the disproportionate-effort exception of Art. 14(5)(b) for a discrete population of Sourcing Database records (e.g., long-archived records for which contact information is no longer in evidence), the reliance is reasoned and dated in a GC memo on file. The exception is narrow and is not used as a default.

​

Removal procedure (Candidate opt-out)

Candidates may direct Neuroscale to remove their Personal Data from the Sourcing Database — and to suppress future re-ingestion — through any of the following channels:

• Email: privacy@neuroscale.ai with the subject line “Sourcing Database — Removal.”
• In-product: the privacy controls in the Neuroscale account (Customers and Authorized Users may forward Candidate requests received outside the platform).
• At first contact: by replying to a Neuroscale-initiated outreach with a removal request; the AI-agent flow recognizes the “remove me,” “delete my information,” and equivalent intents and routes them into the removal queue.

SLA: 30 days from verified receipt of the request, prospectively. The hashed identifiers of removed Candidates are added to the suppression list to prevent re-ingestion. Records of the removal (request, verification, resolution) are retained per the Records Retention Schedule.

​

Annual LIA review and material-change triggers

The General Counsel reviews and re-signs the LIA:

• Annually, on the policy anniversary date.
• On material change to any source (new source admitted; existing source’s ToS materially amended; source removed); to the upstream-pipeline (new ingest control, new deidentification stage); or to applicable law (e.g., a CJEU judgment narrowing legitimate-interest reliance for AI sourcing; a UK ICO enforcement priority; a new state data-broker statute; a material EDPB or ICO guidance update).

The annual review reaffirms the necessity and balancing tests against then-current circumstances and updates the Art. 14 notice and Privacy Notice §2.5 if any required field has changed.

​

Data-broker analysis

Neuroscale’s posture on US state data-broker registration statutes (Cal. Civ. §1798.99.80; Tex. Bus. & Com. Ch. 509; Vt. Stat. tit. 6 §4727; Or. Rev. Stat. §646A.600; NJ Stat. §47:1B-1 — Daniel’s Law, for any judicial / law-enforcement data) is documented in the annual Data Broker Registration Analysis Memo maintained by the General Counsel. The memo is refreshed annually and on each material change to a source or productized output. Reliance on the “not a data broker” position in the Privacy Notice §9 and the AI Acceptable Use Policy is conditioned on a current memo on file.

​

Records

• Per source: ToS review memo, CFAA / CDAFA risk note, executed DPA, vendor privacy-posture summary.
• LIA: signed PDF in SharePoint — Compliance.
• Removal log: Linear “Sourcing Removals” project.
• Suppression list: hashed identifiers in the production database, replicated to the suppression-list service.

​

Cross-references

• AI Acceptable Use Policy — Deidentification Standard, GPAI determination, employment-AI obligations.
• Privacy Notice §2.5 — controller framing of the Sourcing Database.
• Art. 14 Indirect Collection Notice — standalone Art. 14 notice for EU/UK/Swiss Candidates.
• Outbound Communications Policy — TCPA / CAN-SPAM / CASL / PECR / SB 1001 / Art. 50 controls for outreach initiated through the Arbi service.
• Records Retention Schedule — retention periods.
• Vendor Risk Assessment Procedure — vendor due diligence.

​

Governance

• Policy Owner: General Counsel.
• Co-signers: CTO, CISO.
• Annual review: This policy is reviewed at least annually and on each material change to source vetting, ingest controls, the LIA, applicable law, or the Sourcing Database architecture.

​

Exceptions

Exceptions require written General Counsel approval and are documented in SharePoint — Compliance. No exception may permit ingest from a source that has not been vetted under “Source vetting” above.

​

Violations & enforcement

Violations of this policy may result in disciplinary action up to and including termination. Where a violation has caused unlawful Processing, the General Counsel will determine whether the Incident Response Plan breach-notification matrix is engaged.

​

Version history