When an enterprise scraping project stalls, it usually isn't the technology under question.

It's the procurement review.

Legal wants to know whether the data is lawful to collect, security wants to know how the vendor handles it, and the project sits frozen until someone can answer both. That's the reality of web scraping compliance in 2026: the technical work is often the easy part, and the due diligence is where deals are won or lost.

The confusion comes from the fact that "compliance" bundles two very different questions into one word. The first is about the vendor: does this company operate securely, and can an independent auditor vouch for that?

That's where SOC 2 and ISO 27001 come in. The second is about the data itself: is it legal to collect and use, particularly when personal information is involved? That's where GDPR and its counterparts apply.

This post untangles the two layers, explains what each framework actually proves, and gives you a practical way to verify a vendor's claims. One note before we start: this is educational content to support your due diligence, not legal advice, and specific decisions about your data should involve your counsel.

What Does Web Scraping Compliance Actually Cover?

A useful mental model is two layers that must both hold.

Layer one: is the vendor's operation secure?

Your scraping provider will collect, process, store, and deliver data that feeds your business decisions, and in many engagements they'll also hold credentials, target lists, and commercially sensitive requirements that reveal your strategy. Security frameworks like SOC 2 and ISO 27001 exist to answer whether that vendor's internal controls (access management, encryption, incident response, personnel security) actually work, verified by an independent auditor rather than a marketing page.

A perfectly secure vendor can still deliver data you shouldn't have. Privacy regulations like GDPR govern what may be collected in the first place, especially when the scraped content includes information about identifiable people. Certifications don't answer this layer; data governance does. A compliant scraping program needs both layers, because each one fails independently of the other.

SOC 2 for Web Scraping Vendors: What the Report Actually Tells You

SOC 2 is the framework North American enterprise buyers ask about most, and it's also the most misunderstood.

The five Trust Services Criteria

SOC 2 was developed by the AICPA, the American accounting standards body, and it evaluates a service organization's controls against five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy, with security as the mandatory criterion. For a scraping vendor, the interesting criteria beyond security are availability (relevant if you depend on scheduled data deliveries) and confidentiality (relevant because your target lists and datasets are competitively sensitive). Ask which criteria a vendor's report actually covers, because the scope is chosen by the vendor, not fixed by the framework.

Type I vs. Type II, and why Type II is the one that matters

There are two report types, and the difference is significant. A Type I report assesses whether controls are properly designed at a single point in time, while a Type II report tests whether those controls operated effectively over a sustained period, typically six to twelve months. A Type I report says the vendor built the right machinery. A Type II report says the machinery actually ran. For an ongoing data relationship, Type II is the meaningful evidence, and a vendor offering only a Type I report is early in their compliance journey.

How to read a vendor's SOC 2 report

One more correction to a common assumption: there is no such thing as a SOC 2 "certification." The audit produces an attestation report containing the auditor's opinion, and that report is a document you should actually read, not a logo to glance at. Check the scope (which systems and criteria were tested), check the period covered, and check the exceptions section, where the auditor lists controls that failed testing. Exceptions aren't automatically disqualifying, but a vendor who won't share the report under NDA is asking you to trust a claim they won't substantiate.

ISO 27001: The International Security Benchmark

If SOC 2 is the North American default, ISO 27001 is its global counterpart, and enterprises operating internationally often ask for it instead or in addition.

What an ISMS is and what certification proves

ISO 27001 takes a broader approach than SOC 2. Rather than testing selected controls, it requires the organization to establish and maintain an information security management system (ISMS): a formal, risk-based program covering risk assessment, treatment, and continuous improvement, documented against the 93 controls in the standard's Annex A. Unlike SOC 2, ISO 27001 does produce an actual certification, issued by an accredited certification body after a two-stage audit, with surveillance audits in following years to keep it valid. In plain terms: SOC 2 attests that specific controls worked during a window; ISO 27001 certifies that the organization runs an ongoing security management program.

SOC 2 vs. ISO 27001: which should your vendor have?

For a scraping vendor, either framework is a strong signal, and the honest answer is that the choice usually reflects the vendor's customer base rather than their security quality: SOC 2 dominates among North American buyers, ISO 27001 among international ones. The frameworks overlap heavily in their underlying controls, so a vendor with either has done most of the work for both.

It's also worth knowing what these audits are and aren't. They're expensive, standardized processes built primarily for high-volume SaaS platforms, and many specialized service vendors demonstrate the same underlying controls through direct evidence instead: documented security policies, access logs, encryption standards, and contractual audit rights. What actually protects you is the substance of the controls and your ability to verify them, whichever form the evidence takes. A certificate from a vendor who won't show scope documentation is weaker evidence than detailed, verifiable practices from a vendor without one.

Now the second layer. Security frameworks tell you the vendor won't leak your data; GDPR determines whether the data should have been collected at all.

Public data is still personal data

The single most expensive misconception in web scraping is that publicly available information is free to collect. Under GDPR, personal data is personal data regardless of whether it sits behind a login or on a public profile page. Names, email addresses, usernames, photos, and even IP addresses all qualify, and collecting them triggers obligations around lawful basis, transparency, and data subject rights. Plenty of high-value scraping involves no personal data at all: product catalogs, prices, availability, reviews stripped of identifying details, the raw material of a competitive pricing analysis. The compliance question sharpens the moment people become the subject of the data.

Lawful basis and the legitimate interest test

When scraping does involve personal data, GDPR requires a lawful basis for the processing. Of the six bases the regulation offers, legitimate interest is generally the only one that fits scraping, since obtaining consent from individuals before collecting their data is impractical, and relying on it requires a documented balancing test weighing the business interest against the rights of the people involved. Regulators have made this concrete: France's CNIL has published guidance specifically on scraping under legitimate interest, expecting controllers to build in measures like excluding sensitive data categories and excluding sites likely to contain them, and to be able to demonstrate those measures. The theme across regulator guidance is consistent: documentation and demonstrable safeguards are what separate defensible scraping from violations. For the full legal detail, see our dedicated guide: Is Web Scraping GDPR Compliant? What Enterprises Need to Know.

What enforcement looks like in practice

This isn't theoretical risk. Cumulative GDPR fines reached roughly €5.88 billion by early 2025, and scraping has produced one of the regulation's most persistent enforcement targets: Clearview AI, which built a facial recognition database from scraped images and has accumulated around €100 million in EU fines, including a €30.5 million penalty from the Dutch regulator, which is also exploring whether the company's directors can be held personally liable. Clearview is an extreme case involving biometric data, but the enforcement logic applies broadly: scraping personal data without a lawful basis, transparency, or regard for data subject rights is a violation regardless of how public the source was.

How Do You Verify a Web Scraping Vendor's Compliance?

Claims are cheap. Here's how to test them during due diligence.

Documentation to request before signing

If the vendor holds a formal audit, ask for the SOC 2 report (under NDA) or the ISO 27001 certificate with its scope statement, and confirm it's current. If they don't, ask for the equivalent direct evidence: written security policies, access control and encryption documentation, incident response procedures, and a contractual right to security review. On the data side, ask every vendor for their data protection documentation: how they assess targets for personal data, their process for legitimate interest assessments when personal data is in scope, their data retention and deletion policies, and their sub-processor list. A mature vendor has these ready because every enterprise client asks, certified or not.

Questions that separate real compliance from marketing claims

Three questions do most of the work. First: "Walk me through what happens when a target site contains personal data we didn't request." The answer reveals whether data minimization is a practice or a slogan. Second: "Who in your organization can access our delivered data, and how is that access logged?" Third: "Have you ever declined a scraping project on legal grounds?" A vendor who has never said no to a project has no compliance function, just a sales function.

Put it in the contract

Verified claims should become contractual obligations: data handling terms, breach notification timelines, deletion on termination, and audit rights. This is the same discipline as the SLA terms that make performance enforceable, applied to security and legal posture. If a vendor resists writing their compliance claims into the agreement, treat the claims as unwritten.

Compliance by Design: Building It Into the Scraping Process

The strongest compliance posture isn't documentation layered on top of scraping; it's scraping designed so violations are hard to commit.

Data minimization and source vetting

Compliance-by-design starts before the first request: define exactly which fields the business purpose requires and collect nothing else, vet each target source for personal and sensitive data exposure, and configure extractors to skip fields and pages that carry legal weight without business value. Collecting less isn't just legally safer; it's operationally cheaper, since every unnecessary field is storage, processing, and risk with no return.

Security through the pipeline

The same rigor applies downstream: encryption in transit and at rest, role-based access to delivered datasets, audit logs on data handling, and defined retention periods with actual deletion at the end. Reliability practices belong here too, since the monitoring and recovery processes that catch broken scrapers are the same ones that catch anomalous data collection before it becomes a compliance incident.

Conclusion

Web scraping compliance is two layers, and both have to hold. SOC 2 and ISO 27001 answer whether your vendor's operation is secure, with an auditor's signature behind the answer. GDPR and its counterparts answer whether the data itself is lawful to collect, and that answer lives in lawful basis, minimization, and documented safeguards rather than in any certificate. A vendor should be able to show you evidence on both layers without flinching.

DataHen approaches enterprise projects with that scrutiny in mind: source vetting, data minimization, and documented handling practices are part of how engagements are scoped, not afterthoughts. If your legal and security teams have questions a scraping vendor should be able to answer, request a quote and bring the questions with you.

Frequently Asked Questions

Web scraping itself is legal in most jurisdictions, and courts have repeatedly declined to treat the technique as inherently unlawful. Legality depends on what is scraped and how it's used: personal data triggers privacy regulations like GDPR, copyrighted content raises IP questions, and site terms of service can create contractual risk. The practical answer is that scraping is a regulated activity, not a prohibited one.

Q: Does GDPR apply to publicly available data?

Yes. GDPR applies to personal data based on what it is, not where it was found. A name or email address on a public webpage carries the same protections as one in a private database, so scraping it still requires a lawful basis, transparency measures, and respect for data subject rights. "It was public" is not a recognized defense under the regulation.

Q: What is the difference between SOC 2 and ISO 27001?

SOC 2 is a North American framework that produces an auditor's attestation report on a vendor's controls against selected Trust Services Criteria. ISO 27001 is an international standard that certifies an organization's entire information security management system after a formal audit. SOC 2 tests whether specific controls worked over a period; ISO 27001 certifies an ongoing security program. Their underlying controls overlap heavily, and either is a credible security signal.

Q: Does a web scraping vendor need to be SOC 2 certified?

Strictly speaking, no vendor is "SOC 2 certified," since SOC 2 produces an attestation report rather than a certificate. Whether a formal audit is necessary depends on your risk profile and the vendor's model: these audits were designed for high-volume SaaS platforms, and many specialized data vendors demonstrate equivalent security through documented policies, verifiable controls, and contractual audit rights. What matters is that the vendor can evidence their controls in a form your security team can verify.

Q: What is legitimate interest under GDPR?

Legitimate interest is one of GDPR's six lawful bases for processing personal data, and the one most scraping programs rely on. It permits processing that is necessary for a genuine business interest, provided that interest isn't overridden by the rights of the individuals involved. Relying on it requires a documented balancing test, called a legitimate interest assessment, plus safeguards like data minimization and exclusion of sensitive data.

Q: What compliance documents should I request from a web scraping vendor?

Request the vendor's security evidence in whatever form they hold it: a current SOC 2 report or ISO 27001 certificate if they're audited, or written security policies, access control documentation, and contractual audit rights if not. Then request the data protection documentation every scraping vendor should have: personal data assessment procedures, legitimate interest assessment templates, retention and deletion policies, breach notification commitments, and the sub-processor list. Mature vendors provide these quickly; hesitation is itself due diligence information.

Q: Can web scraping be GDPR compliant?

Yes, and much of it trivially so, since scraping that avoids personal data entirely (prices, product specs, availability) sits largely outside GDPR's scope. When personal data is involved, compliance is achievable through a documented lawful basis, data minimization, exclusion of sensitive categories, defined retention, and respect for data subject rights. What GDPR punishes is indiscriminate collection without safeguards, not scraping as a technique.