Compliance — hiQ, ToS, GDPR, and the post-Van Buren landscape.

The premise — four overlapping regimes

The legal substrate has four distinct layers, each with its own enforcement mechanism. The first is the LinkedIn User Agreement — a contract between the platform and every account holder, enforced through account restriction and, at higher tiers, civil litigation. The second is the Computer Fraud and Abuse Act (CFAA), 18 U.S.C. §1030 — a federal criminal statute that attaches civil liability under §1030(g) and whose scope as applied to scraping of publicly available data has been substantially narrowed by hiQ Labs v. LinkedIn and Van Buren v. United States. The third is the patchwork of state-level computer-misuse statutes — California Penal Code §502 the most operator-relevant, alongside roughly thirty state analogues. The fourth is the privacy regime applicable to the personal data being processed — the GDPR for any European data subject, the CCPA as amended by the CPRA, and the growing patchwork of US state privacy statutes. The privacy regimes regulate the downstream processing of personal data regardless of how it was acquired.

The LinkedIn User Agreement, §8

Section 8 of the LinkedIn User Agreement, titled "Dos and Don'ts," contains the operative prohibition on automation. The substantive prohibitions are stable across revisions: the user agrees not to develop, support, or use software, devices, scripts, robots, or other means (including crawlers, browser plugins and add-ons) to scrape the platform or copy profile data; not to use bots or other automated methods to access the platform, add or download contacts, or send messages; and not to bypass or circumvent access controls or use limits.

Read against the automation taxonomy of the prior chapter, this is comprehensive. The browser-extension category is captured explicitly. The cloud-based session-replay category is captured under "scripts" and "automated methods." The reverse-engineered-API category is captured under "bypass or circumvent any access controls." No category in Chapter 07 is outside textual tension with §8.

§8 is enforced primarily through the platform's detection and account-restriction machinery, not through civil litigation. The litigation threshold is high and reached almost exclusively for tooling vendors, agencies operating at scale, or competitors building parallel data products. Individual operators sending fewer than a few hundred automated actions per week have not, to public knowledge, been individually targeted in §8 litigation. The enforcement that reaches them is account-level, not court-level.

The CFAA and the question of "unauthorized access"

The CFAA, codified at 18 U.S.C. §1030, criminalizes (among other things) accessing a computer "without authorization" or in a manner that "exceeds authorized access." For roughly two decades after its 1986 enactment, the federal circuits split on what these phrases meant for a public website. The broad reading held that any ToS-violating access was "without authorization," converting every breach into a potential federal crime under §1030(a)(2)(C). The narrower reading required affirmative circumvention of an access control before the statute attached.

hiQ Labs v. LinkedIn — the preliminary injunction

hiQ Labs, Inc. v. LinkedIn Corp., 938 F.3d 985 (9th Cir. 2019), brought the question into sharp focus. hiQ was a data-analytics company that scraped public LinkedIn profile data to build employee-retention prediction tools. LinkedIn issued a cease-and-desist letter and implemented technical measures to block hiQ's access. hiQ sued for injunctive relief, arguing the threatened CFAA claim was without merit because the data was publicly accessible.

The Ninth Circuit, affirming the district court's preliminary injunction, held that scraping publicly available data did not constitute access "without authorization" under the CFAA. The reasoning relied on the statutory text — "without authorization" presupposes that authorization is required, and information posted to the public web without an access-control gate is, by its nature, information for which no authorization is required. The operational period from August 2019 through mid-2021 was, in the scraping industry's understanding, a window during which scraping public LinkedIn data was treated as legally defensible under federal law.

Van Buren v. United States — the Supreme Court narrowing

Van Buren v. United States, 593 U.S. 374 (2021), did not arise from a scraping case. Nathan Van Buren was a Georgia police sergeant who accepted payment to search a law-enforcement license-plate database for a private purpose. He had authorized access; the prosecution's theory was that using it for an unauthorized purpose "exceeded authorized access." The Supreme Court, in a 6–3 decision written by Justice Barrett, rejected that theory.

The Court held that "exceeds authorized access" applies only to information the user is not entitled to access at all — files, folders, or databases off-limits under the system's access controls. It does not extend to information the user is entitled to access but obtains for a prohibited purpose. The opinion explicitly rejected the broader reading that would criminalize "a breathtaking amount of commonplace computer activity," including violation of routine website terms of service. Van Buren reinforced the hiQ reasoning that ToS violations alone could not give rise to CFAA liability when the underlying data was accessible.

hiQ on remand and the reversal of posture

Following Van Buren, the Supreme Court vacated the Ninth Circuit's hiQ decision and remanded. The Ninth Circuit, on remand in 2022, reaffirmed the preliminary injunction on substantially the same CFAA grounds. The CFAA path had narrowed; LinkedIn's prospects under that statute had not improved.

But the case did not end on the CFAA question. On remand, LinkedIn pursued its contract-law claim — that hiQ's scraping breached the User Agreement. In November 2022, the Northern District of California granted LinkedIn summary judgment on its breach-of-contract counterclaim, finding that hiQ's continued scraping after the cease-and-desist letter — and, materially, after hiQ employees logged into the platform under accounts subject to the User Agreement — constituted a breach. The matter resolved through a stipulated judgment and a permanent injunction against hiQ in late 2022. The CFAA path was narrowed to near-irrelevance; the contract-law path became the operative enforcement mechanism. LinkedIn did not lose the legal terrain; it shifted theaters.

The present-day legal posture

The synthesis, as of 2026: scraping public LinkedIn data does not, on its own, violate the federal CFAA. State-level computer-misuse statutes vary, with California §502 the most operator-relevant. The activity does, however, violate the LinkedIn User Agreement when conducted by an account holder subject to that agreement — functionally every operator who has ever logged in. The platform's remedies are account restriction, civil suit for breach of contract, and injunctive relief. Criminal CFAA prosecution is not on the table for public-data scraping in the ordinary case. Civil litigation by the platform is theoretically available but reserved for higher-volume targets. Account restriction is the routine enforcement mechanism, and it is the one the operator has to plan around.

GDPR Article 6(1)(f) — legitimate interest as the lawful basis

The GDPR applies to the processing of personal data of any data subject in the European Economic Area, regardless of where the operator is located. LinkedIn outbound at scale necessarily processes personal data — names, employers, titles, often email addresses — for prospects who are, in any sufficiently large list, EEA residents in meaningful fraction.

For B2B outbound, the operative lawful basis under Article 6 is almost always 6(1)(f) — processing necessary for the legitimate interests of the controller, except where overridden by the interests or fundamental rights of the data subject. Consent under 6(1)(a) is unavailable for cold outreach by definition; 6(1)(b) is unavailable because no contract exists.

The 6(1)(f) basis requires a three-part balancing test, documented in a Legitimate Interest Assessment (LIA). The operator identifies a legitimate interest — typically business development, market research, or recruitment. The operator demonstrates that processing is necessary to achieve that interest, constraining the data to what is actually used. The operator weighs the interest against the data subject's reasonable expectations and the potential for harm. B2B outbound to a professional's business contact information for a relevant business purpose has, in the published guidance of multiple EEA supervisory authorities, been treated as falling within 6(1)(f) — provided the contact is in a professional capacity, the message is relevant to the role, data minimization is observed, and the data subject is informed and offered an effective opt-out at first contact.

Data-subject rights and the operational requirement

The GDPR vests the data subject with rights that apply irrespective of the lawful basis. Article 15 entitles the data subject to a copy of the personal data being processed. Article 17 entitles the data subject to demand deletion. Article 21 is absolute in the direct-marketing context — once exercised, processing for that purpose must cease.

Every outbound system must be capable of honoring these requests on a prospect-by-prospect basis, within the statutory deadline of one month. This implies a documented data inventory, a suppression list keyed to data-subject identifiers, and a process for propagating erasure across CRM, sequencing tool, and enrichment provider. The maximum fine under Article 83(5) is the greater of €20,000,000 or 4% of total worldwide annual turnover. Enforcement at the maximum tier has concentrated on platform-level controllers; enforcement against individual B2B senders has been infrequent and has typically resolved in the low-five-figure range with corrective orders rather than monetary penalties.

CCPA, CPRA, and the state-level patchwork

The California Consumer Privacy Act, as amended by the California Privacy Rights Act, regulates the processing of personal information of California residents. The original CCPA contained, at §1798.145(n), a partial B2B exemption excluding most personal information collected in a business-to-business transaction. That exemption sunsetted on January 1, 2023. As of 2026, B2B contact data of California residents is subject to the full CCPA/CPRA obligations: the right to know, delete, correct, opt out of sale or sharing, and limit use of sensitive personal information. Penalties under §1798.155 are administrative — $2,500 per unintentional violation, $7,500 per intentional.

The state-level patchwork beyond California — Virginia's VCDPA, Colorado's CPA, Connecticut's CTDPA, Utah's UCPA, and roughly fifteen additional state statutes in force as of 2026 — varies in scope but converges on a common set of data-subject rights. Honoring opt-outs, providing data access, and maintaining a suppression list is sufficient for most state regimes.

The enforcement pattern in practice

Three observable tiers. At the individual-operator tier — a single salesperson sending under a few hundred connect requests per week — enforcement is essentially nonexistent; account restriction is the only realistic exposure. At the tooling-vendor tier — automation platforms, scraping-as-a-service vendors, data-broker products built on public LinkedIn data — enforcement is regular and consequential; the platform has, since 2014, pursued multiple civil actions and won injunctive relief in the majority of those cases. At the platform-controller tier — operators of data products that process EEA residents' data at scale — GDPR enforcement is the operative risk. The frequency of high-tier penalties has increased meaningfully since 2020, and the pattern has shifted from one-off complaints to coordinated supervisory-authority action across the EEA.

The risk-allocation question

The compliance frame rests on an asymmetry worth naming. The operator's risk surface is primarily commercial — account restriction, contract-law liability, reputational damage. The data subject's risk surface is privacy harm — unsolicited contact, the use of professional identity in commercial pipelines, the loss of control over personal data. The GDPR's structure, and increasingly the structure of US state privacy law, places the data subject's risk at the center. This is the structural reason operator-side enforcement has been mild and platform-side enforcement has been escalating. An outbound program that minimizes the personal-data surface — processes only business contact information, retains it only as long as necessary, honors opt-outs effectively — sits well inside the enforcement frame even if its strict-text compliance is imperfect.

The compliance-by-architecture pattern

The operationally defensible setup, synthesized across the four regimes:

• Documented Legitimate Interest Assessment per outbound program. Updated when targeting materially changes.
• Opt-out honored within 72 hours, propagated across CRM, sequencing tool, enrichment provider, and any third-party processor. The statutory GDPR deadline is one month but earlier is materially safer.
• No scraping of behind-login data through bypass of access controls. Public profile data accessed under an authenticated account is in a different posture from data accessed through bypass of a permission gate.
• No impersonation of the recipient or of other users. False sender identity converts a contract violation into a fraud question.
• No fabricated personalization. Personalization based on data not actually collected is a category of harm that data subjects, supervisory authorities, and juries all recognize quickly.
• A suppression list of permanent record, keyed to email and LinkedIn profile identifier, persisting across CRM migrations. The single most common GDPR operational failure is re-contacting a prospect who previously opted out because the suppression record did not propagate.
• Data minimization in the enrichment pipeline. Collect only the fields actually used. Exposure scales with the surface area of the data store.

The contractor and third-party question

When outbound is operated by a third party — an agency, a consultancy, a managed-services provider — the GDPR's controller and processor distinction becomes operative. The controller determines the purposes and means of processing; the processor acts on behalf of the controller. The controller bears primary responsibility for the lawful basis and the data-subject rights; the processor is constrained by the controller's instructions.

The contractual flow-down requirement under Article 28 is that any processor must operate under a written contract specifying the subject matter, duration, nature, and purpose of the processing, the personal data and data-subject categories, and the obligations of the controller. The contract must oblige the processor to maintain confidentiality, implement security measures, assist with data-subject requests, and delete or return personal data at the end of the engagement. This typically takes the form of a Data Processing Agreement (DPA). The DPA is not optional under EEA law.

Common operator failures observed in production

• Assuming hiQ remains good law on its original terms. The CFAA narrowing held; the contract-law exposure did not. An operator who reads the 2019 opinion and concludes that scraping LinkedIn is "legal" is reading half the decision.
• Treating the User Agreement as advisory. The underlying contract is enforceable, and the litigation history demonstrates that the platform will pursue civil action against tooling at scale.
• No documented LIA. The assessment exists in the operator's head and not in any retrievable document. A supervisory authority inquiry receives nothing.
• Ignoring opt-out requests. The single most common compliance violation, and the one most likely to convert into an actual complaint.
• Scraping behind-login data through deobfuscation of the platform's internal API. The distinction from public-URL access matters under both contract and CFAA analysis.
• Operating without a DPA when outbound is run by a third party. The controller remains primarily liable, with or without the contract.
• Conflating US and EEA postures. CCPA exposure is administrative and concentrated in California; GDPR exposure is administrative and distributed across the EEA. Treating one as a proxy for the other produces a posture wrong for at least one.

Pre-deployment checklist

• The LinkedIn User Agreement, current revision, has been read by the operator responsible for the program
• A Legitimate Interest Assessment is documented and stored alongside the program's operational documentation
• An opt-out mechanism is operational, propagated across all tools, and tested end-to-end with a synthetic prospect
• A suppression list of permanent record is maintained, keyed to durable identifiers and resilient to CRM migration
• Data-subject access and erasure workflows are documented, with named ownership and a response time inside the statutory deadline
• If a third party operates the outbound, a Data Processing Agreement is executed and the controller/processor allocation is explicit
• Behind-login data is not scraped through bypass of access controls; public-data access is conducted under an authenticated account
• Sender identity is accurate; personalization is grounded in data actually collected from documented sources

Where compliance fits in the broader infrastructure

The seven prior chapters describe the operational substrate of running LinkedIn outbound. This chapter describes the legal substrate underneath. The two surfaces are independent: an operationally correct program can be legally exposed, and a legally correct program can be operationally inert. The compliance posture is the floor under everything else — the most carefully provisioned multi-account architecture, the most precisely tuned residential proxy network, the most patient warmup runway, all of it presupposes that the operator is permitted to do what the operator is doing.

A program that runs cleanly under all four regimes — contract, federal statute, state computer-misuse law, and the applicable privacy framework — is one that survives both the platform's adversarial detection and the regulator's eventual attention. A program that runs cleanly under only the operational layer has a half-life measured by whichever of the four regimes notices it first.