What Article 5(1)(e) bans and why it is hard to prove
Article 5(1)(e) bans placing on the market, putting into service for this purpose, or using AI systems that create or expand facial recognition databases through untargeted scraping of facial images from the internet or CCTV footage. The prohibition has applied since 2 February 2025. If your team is building, buying or operating an AI system that touches face images collected from the web or from camera feeds, the question to answer first is not whether your policy forbids scraping but whether the database the system relies on was created or grown this way, at any point in its history. The ban binds providers and deployers alike, so a system bought from a vendor does not move the exposure off your organization.
The harm the ban targets is mass biometric profiling of people who never had a relationship with the system operator and were never singled out for a lawful purpose. The word that does the work is *untargeted*: a database built from bulk collection rather than from identified, purposeful sourcing falls inside the prohibition regardless of the stated use. That is why the difficulty is evidential. Most teams can write a no-scraping rule in an afternoon. What they cannot easily show is the provenance of training, reference or matching datasets that were assembled by a third party, enriched by a data broker, or extended by a feature that quietly ingests new images. Ask each supplier, in writing, how every image set was sourced, whether any collection was automated, and whether the database grows after deployment.
Treat provenance as a control to be evidenced, not a clause in a contract. Map every dataset and enrichment pipeline that feeds a face-matching capability, record the source and collection method for each, and keep the records current when a vendor updates its model or adds a data source. Where your system is also a remote biometric identification system that is not prohibited, it falls under the high-risk category in Annex III point 1(a) where Union or national law permits its use, which brings separate obligations. Confirm with counsel which side of the line each use case sits on before you commit to a deployment date, and read the Article 5 text on EUR-Lex alongside your own data inventory.
Which systems, data sources and third parties fall under the scraping ban
Article 5(1)(e) turns on four questions: what the system does with faces, where the images come from, whether collection is untargeted, and who in the chain touches the output. Each card below covers one of those decisions or the parties that share responsibility for them.
Database builders and expanders
The ban reaches AI systems whose purpose is to create a facial recognition database or to expand an existing one. Ask whether the system's job is to add new faces to a reference set, or only to match a face against a set you already hold for a different, permitted purpose. Document the answer per system, because a single platform can do both. Illustrative: a vendor tool that enrolls every new face it sees into a shared gallery falls on the prohibited side, while a one-time matching tool with no enrollment step does not.
Internet versus CCTV sources
The prohibition names two source types: facial images scraped from the internet and facial images taken from CCTV footage. Map every input feed and crawl target, including public social media, news sites, forums and camera networks you do not own. Record the legal basis and collection method for each source. A dataset built from a mix of sources is in scope if any part of it was gathered this way for the prohibited purpose.
Untargeted collection
The prohibition turns on untargeted scraping, meaning collection that is not aimed at specific, identified people or cases. Targeted collection, such as retrieving images of a named individual under a defined legal process, is treated differently. Review crawler configurations, search queries and camera retention rules to show how collection is scoped. Broad crawls that sweep up faces by default are the pattern the ban describes.
Vendors and dataset suppliers
Providers that place a scraping-based system on the EU market are in scope, and so are deployers that put it into service or use it. Dataset suppliers and data brokers sit in the chain when their products feed a prohibited system. Contracts should require each supplier to state how faces were collected, whether collection was targeted, and which jurisdictions were involved. Ask for these statements in writing before you buy or ingest a dataset.
Provider and deployer duties
The prohibition covers placing on the market, putting into service for this purpose, and use. A provider that builds such a system and a deployer that runs it both carry the exposure, even if the deployer did not build the database. Assign an owner for each system in your AI inventory and confirm who signs off on the purpose statement. Fines for prohibited practices reach EUR 35 million or 7% of total worldwide annual turnover for the preceding financial year, whichever is higher.
High-risk route for permitted systems
Remote biometric identification systems that are not prohibited are not free of obligations. Under Annex III point 1(a), they are high-risk where their use is permitted by Union or national law. Confirm, for each system, whether it is a prohibited database builder or a permitted identification tool, and document the reasoning. Permitted tools then face the high-risk requirements, with the dates set by the 2026 amendment.
How an assessor tests that no untargeted scraping occurs
This table sets out what an assessor examines to confirm that no facial recognition database was built or expanded by untargeted scraping, the evidence each test relies on, and the findings that most often trigger follow-up. Read each row as a test step: the left column names the area, and the other columns show what the assessor asks for and where gaps usually appear. The main takeaway is that the test depends less on a policy statement than on traceable dataset origins.
| Test area | What the assessor requests | Common finding |
|---|---|---|
| Dataset provenance review | Source register for every image set used to train, tune or expand a face-matching model, with origin, collection method and date | Image sets recorded only as 'public web' with no crawl target, domain list or collection date |
| Data supply contracts | Vendor agreements and warranties stating how facial images were collected, consent or legal basis, and audit rights | Vendor datasets with unknown origin and no contractual warranty against scraping |
| Collection logs and crawler records | Logs of any crawler, scraper or API job, showing user agent, target domains, query terms and volumes | Undocumented web crawlers run by data science teams or by third-party tools |
| Sampling of training and reference datasets | Random and risk-based sampling of images, with metadata checks for source URLs, camera IDs and capture context | Source URLs or CCTV feed identifiers missing from a material share of sampled records |
| Interviews with data engineering | Walkthroughs of pipelines, ingestion jobs and enrichment steps, with the staff who run them | Engineers describe enrichment or 'augmentation' jobs that were never entered in the inventory |
| CCTV footage reuse | Confirmation that footage from cameras was not pulled into face galleries beyond the purpose the operator documented | Gallery enrolment from camera feeds with no documented purpose or lawful basis |
| Prohibition scope check | Written determination of whether the system is a prohibited database expansion or a permitted high-risk use under Annex III point 1(a) | No documented classification, or a classification that never considered scraping as a source |
How to implement the ban in practice
The sequence below turns the Article 5(1)(e) prohibition into controls you can show an assessor: a complete picture of facial image systems, a traced source for every dataset, technical blocks on untargeted collection, contract terms with suppliers, and a written record of each decision. Each step closes with an output you can file as evidence.
Inventory every system that handles facial images
Start by listing each AI system, model, pipeline, vendor product and internal tool that stores, processes, matches or generates facial images or templates. Include systems you did not build, such as video analytics add-ons, identity verification services and search tools used by staff. Assign an owner to each entry and record whether you are acting as provider, deployer or both. The output is a dated register of facial image systems that the compliance lead signs off, which becomes the scope for every later step.
Trace each facial dataset to its source
For every dataset or database that contains facial images, record where each image came from, how it was collected, when, and under what legal basis or licence. Flag any source that was an open crawl of the internet or a bulk extraction from CCTV footage not tied to a specific, targeted purpose. Ask the data engineering team to produce lineage records that show collection method, not only storage location. The output is a provenance map per dataset, with flagged records isolated for legal review.
Quarantine datasets built from untargeted collection
Where the provenance review finds datasets created or expanded by untargeted scraping, freeze them: stop further training, matching and enrichment, and restrict access to the legal and compliance team. Counsel then decides whether the data must be deleted, and whether any model trained on it must be retrained or withdrawn. Record each decision and its reasons. The output is a quarantine log showing which datasets were frozen, who approved each decision and what remediation was chosen.
Block untargeted crawlers and scrapers in the pipeline
Configure the data pipeline so that automated collectors cannot add facial images to any repository without an approved, documented purpose. In practice this means an allowlist of sources, crawler rules that exclude image and social content from unapproved domains, and access controls that stop ingestion jobs from writing to facial datasets without a ticket. Test the controls with a red team or a scripted check that attempts a bulk crawl. The output is a configuration baseline and a test report that shows the attempted collection was blocked and logged.
Add contract warranties and audit rights for suppliers
Review every data supplier, labelling vendor, dataset broker and model provider that touches facial images. Contracts should warrant that supplied images were not obtained by untargeted scraping of the internet or CCTV footage, require provenance documentation for each delivery, and grant you audit rights to verify it. Include notice and termination terms if a warranty is breached. Legal counsel should negotiate these terms, and you should confirm the wording with them. The output is an amended supplier register and signed clauses for each in-scope vendor.
Verify monitoring and logging across the stack
Confirm that the controls from earlier steps keep working over time. Log ingestion events, dataset access and changes to crawler configuration, and send these logs to a system where compliance staff can review them. Self-hosted observability and evaluation tools can help capture this activity, but you should confirm each tool's logging behaviour in your own environment before relying on it. Set a review cadence that your governance policy defines. The output is a monitoring specification and a sample log extract that shows ingestion decisions can be reconstructed.
Document decisions and keep the evidence file
Bring the outputs of every step into one evidence file: the system register, provenance maps, quarantine log, pipeline test report, signed supplier clauses and monitoring specification, each with an owner and date. Record the reasoning behind any dataset you kept, including why its collection was targeted and lawful. Keep the file under version control so changes are traceable. The output is a single, dated evidence pack that an internal reviewer or an independent assessor can follow from the prohibition to the control that enforces it.
How the ban relates to high-risk remote biometric identification
The key point is that a facial recognition database built through untargeted scraping cannot be made compliant by adding controls. The prohibition in Article 5(1)(e) attaches to the way the database is created or expanded, so logging, access restrictions, human oversight or a strong risk assessment do not change the answer. If the database was built or is being expanded by untargeted scraping of facial images from the internet or CCTV footage, the system falls under the ban for providers who place it on the market or put it into service for that purpose, and for deployers who use it. The fix is to stop the scraping and remove the data, not to document around it.
A lawful remote biometric identification system is treated differently. Systems that are not prohibited fall under the high-risk category in Annex III, point 1(a), where Union or national law permits their use. That means the system must meet the high-risk requirements, and the permission to use it depends on the legal basis in the deployment country, not on the technology alone. A compliance lead should therefore record the boundary as a decision with three parts: how the reference dataset was sourced, which legal basis permits the use, and which provider and deployer roles the organization holds. Confirm the current legal position with counsel, because national rules on biometric identification vary.
Record the decision in the AI system inventory and the governance file, with the date, the data sources reviewed, the person who approved it and the evidence that supports each source, such as licences, collection logs or documented consent. Revisit it whenever a data source changes, a vendor supplies a new image set, the system starts ingesting images from the web or camera feeds, or a new deployment country is added. A boundary that was correct at launch can become a prohibited practice after a dataset update, and the fines for prohibited practices are the highest in the Act.
Evidence that shows no scraped facial database exists
Article 5(1)(e) is tested through records, not assertions. An assessor will ask where every facial image in a database came from, who collected it and how the organization would prove it was never harvested from the internet or CCTV footage without targeting. The artifacts below form that proof, and each one needs a refresh cycle so it still matches the systems as they run between audits.
Dataset register with provenance
Keep a register listing every image dataset, its source, the collection date, the legal basis relied on and the system that consumes it. For each entry, record whether the images were licensed, consented, generated or collected from a targeted source. Review the register whenever a dataset is added, and reconcile it against the actual contents of storage at least once a quarter so no dataset enters a model unlisted.
Supplier warranties and collection certifications
Where a vendor supplies face images or a face recognition model, obtain a written warranty that the images were not gathered by untargeted scraping and a description of the collection method. Ask for the vendor's own provenance records, not only a statement. Renew warranties at each contract renewal and whenever the vendor changes its data sourcing, and store them alongside the dataset register.
Crawler and scraper configuration records
If any internal or contracted process collects web content, keep versioned configuration files showing the target domains, allowed content types and exclusion rules that block image harvesting. Any scraper that touches image hosts or video streams should be disabled for facial data collection and documented as such. Re-check these configurations after each change to the crawl pipeline, since a small rule change can reopen the collection path.
Access logs for image stores
Retain logs of every read, write and export against storage holding face images, with user identity, timestamp and purpose. Logs show whether bulk ingestion occurred and who authorized it. Review them on a fixed schedule and set alerts for large batch writes to image buckets. Confirm the retention period with your legal team, since logs themselves may contain personal data.
Deletion records for unlawfully collected images
If an image is found to have been collected by untargeted scraping, the organization must remove it from datasets and from any model training pipeline it fed. Keep a deletion record naming the images or dataset removed, the date, the approver and the verification step. Note that removing images from a database may not remove their influence on a trained model, so document what you did to assess that question.
Dated review of data sources
Schedule a documented review of every data source feeding face-related systems, signed by a named owner and dated. Each review should confirm the source list is current, the warranties are still valid and the collection controls still operate. Pair the review with the AI system inventory so new tools that handle images are picked up. Set the review interval in your governance policy and keep prior versions for the assessor.
What meeting Article 5(1)(e) costs in money and effort
This table breaks down the cost and effort components of showing that an AI system does not build or expand facial recognition databases through untargeted scraping. Read each row for who is paid, whether the cost is one-time or recurring, and what pushes it up, then use the list to request a written scope quote.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Data provenance review | Internal legal and data teams, with outside counsel if needed | One-time, then repeated on each new dataset | Number of image sources and how many are web-scraped or CCTV-derived |
| Engineering time to audit pipelines | Internal platform engineers or an implementation partner | One-time build, plus recurring checks after changes | Number of ingestion pipelines and whether collection logs already exist |
| Legal review of supplier contracts | Internal counsel and outside lawyers | Recurring at renewal and on supplier change | Number of data vendors and whether contracts state image origin |
| Evidence upkeep | Internal compliance and security staff | Recurring | Frequency of dataset updates and how well evidence is logged by default |
| External review and auditor sampling | Independent auditor or assessor, who issues any report | Recurring at each assessment cycle | Scope of samples the assessor selects and the depth of pipeline records |
| Self-hosted open-source tooling | Organization owns the infrastructure, with a partner for setup if contracted | Setup one-time, hosting recurring | Avoids most per-seat license spend, but adds hosting and maintenance effort |
| CCTV estate size | Internal facilities and engineering teams | Recurring as cameras and feeds change | Each additional camera feed adds review and records to maintain |
Who owns the ban, who prepares evidence and who issues findings
Your organization owns the ban. Article 5(1)(e) of the AI Act applies to providers that place facial recognition systems on the market or put them into service for this purpose, and to deployers that use them. The legal entity that holds the images, runs the models and signs the contracts is accountable for whether a database was built through untargeted scraping. Fines for breaching the prohibition can reach EUR 35 million or 7% of total worldwide annual turnover, whichever is higher (Article 99(3)), so the decision cannot be delegated to a vendor or an auditor.
- Legal scope decisions: determine whether any system falls under the prohibition, whether it is a remote biometric identification system, and whether a permitted use under Union or national law applies.
- Data source approvals: decide which image sources are acceptable and record why each source is targeted, licensed or otherwise lawful.
- Policy and sign-off: approve the written prohibition policy, name the accountable owners and set the escalation path for suspected scraping.
- Supplier contracts: hold warranties, provenance statements and audit rights from vendors and dataset providers.
Confirm that a named executive can explain, with records, how each facial dataset in use was assembled and who approved it.
DeployOpen prepares systems and evidence inside your cloud accounts, data centers or air-gapped networks. It implements and configures the platforms that handle ingestion, storage and access, then documents how those controls work. DeployOpen does not decide whether a dataset is lawful, does not own the control and does not issue reports or certificates. Most engagements are fixed-scope, so the systems, log sources and deliverables are agreed in writing before work starts.
- Pipeline inventory: map the crawlers, data pipelines, CCTV feeds and dataset build jobs that could feed a facial recognition database.
- Technical controls: configure source allow-lists, access restrictions and job approvals so that every ingestion path can be shown to be targeted and authorized.
- Logging and lineage: set up retention for ingestion logs, configuration history and data lineage records that show where each image came from.
- Evidence packaging: assemble exports, change records and test results into a structured pack for your compliance team and your assessor.
- Gap reporting: describe what the systems show and which gaps remain open, without declaring the organization compliant.
Ask for a written scope that names each system, log source and evidence item, and that states which items your organization must approve before they are used.
Only an independent auditor, assessor or certification body issues reports or certificates. The assessor's value depends on its independence, so it should not design the controls it tests. Before work starts, agree in writing what it will sample, which records it will request and what form its output will take. Its findings should be issued under its own name, and the organization should not be able to edit them.
- Test design: agree the samples in advance, such as ingestion configurations, source approvals and dataset provenance files for a chosen period.
- Testing: interview staff, reperform selected checks and compare evidence against the stated criteria.
- Findings: issue written findings that identify what was tested, what was observed and what remains open.
- Scope of attestation: confirm whether the assessor can attest to the absence of prohibited scraping at all, and under which standard or engagement type.
- Independence: check that the assessor has not built or operated the pipelines it will examine.
Before you buy the assessment, ask the assessor to confirm in writing which output it will issue, what it will call that output and what it will not be able to conclude.
Some work is usually outsourced and some must stay in-house. Outsourcing does not transfer accountability, so your legal and procurement teams need to keep control of the decisions that carry legal weight. Counsel interprets the prohibition and any exception. Procurement and legal teams negotiate with dataset vendors. Your organization also remains the contact for national market surveillance authorities, which enforce the Act for AI systems.
- Usually outsourced: pipeline audit support, log retention configuration, technical testing of ingestion controls and evidence packaging.
- Must stay in-house: legal judgments on what counts as untargeted scraping, the assessment of exceptions and the decision to continue, pause or retire a dataset.
- Supplier relationships: warranties, provenance evidence, cooperation duties and termination rights with dataset and image vendors belong with your procurement and legal teams.
- Regulator contact: responses to authorities should be prepared by your organization, with counsel, and supported by the evidence pack.
- Incident handling: decide in advance who suspends an ingestion job, who notifies management and who records the decision.
Confirm which of these functions your staff can own from the start, so that outside help supports your decisions rather than replacing them.
Where organizations usually fall short on the scraping ban
Article 5(1)(e) is easy to state and easy to violate by accident. The gaps below rarely come from a deliberate decision to build a scraped face database. They come from data inherited from vendors, old projects and camera analytics that nobody reviewed against the prohibition. Each card names a gap and the action that closes it.
Face datasets from unknown origin
Vendors and data brokers sometimes supply labeled face images for training or testing without saying how the images were collected. If the collection involved untargeted scraping from the internet or CCTV footage, the organization placing that system on the market or using it may be exposed to the prohibition. Ask every dataset supplier to state the collection method, the source sites or cameras, and the legal basis, and keep that statement with the dataset record. Action: refuse any face dataset whose provenance cannot be documented.
Forgotten crawlers from earlier projects
Research prototypes, identity experiments and marketing tools often run crawlers that collect images long after the project team has moved on. A scheduled job that still harvests faces from public pages can expand a gallery without anyone deciding to. Inventory every crawler, scraper and image pipeline in source control, cloud schedulers and vendor accounts, then confirm which ones touch images of people. Action: disable or delete any job that collects faces and record the decision.
CCTV analytics that build galleries
Video analytics products sometimes extract face templates from every camera feed and store them in a searchable gallery, even when the deployment was sold for occupancy counting or access control. Untargeted extraction from CCTV footage to create or grow a facial recognition database is the conduct the prohibition names. Check the vendor configuration for any setting that saves face embeddings from general footage, and confirm with the vendor in writing whether such a feature exists and is disabled. Action: turn off gallery creation and document the configuration baseline.
No contract right to audit suppliers
Many procurement contracts give the buyer no way to verify how a supplier collected biometric training data or how its model was built. Without an audit right, the organization cannot test the supplier's claims, and it has little recourse if a dataset turns out to rest on scraping. The contract should require data provenance records, a right to inspect them on reasonable notice, and a duty to notify the buyer of changes in collection methods. Action: add provenance warranties and audit rights to every AI supplier contract before renewal.
Questions buyers ask about the scraping ban
Does the scraping ban apply if we only buy a vendor's facial recognition model?
Yes, it can. Article 5(1)(e) covers placing a system on the market, putting it into service for this purpose, and using it. A deployer that uses a bought system to create or expand a recognition database through untargeted scraping is caught by the use limb, even if someone else built the model. Purchasing a product does not move the obligation to the vendor. Ask the vendor in writing how training and enrollment data were collected, whether the product can add faces from web or CCTV sources, and what contractual limits apply. Your own data pipelines and enrollment processes remain your responsibility. Confirm this reading with counsel and, where relevant, the national market surveillance authority.
How much effort does proving we do not scrape faces take?
The effort depends on how many systems touch facial images and how many data sources feed them. The work usually includes an inventory of every system that processes facial images, a record of where each database's images came from, technical controls that block crawlers or unapproved camera feeds, and logs that show enrollment came from approved sources. The initial review is a one-time cost. Re-checking recurs whenever a vendor updates a model or a team adds a source. No public effort figure is supplied for this ban, so ask any provider for the scope, deliverables and effort in a written quote, and ask how each item will be evidenced for an independent assessor.
Can our own team assess this ban without outside help?
Yes, many organizations can run the inventory and data-source review internally, because they own their controls and evidence. The team needs someone who can read Article 5 with legal support, engineers who know how images enter each pipeline, and a person who documents decisions and keeps records. Internal reviews tend to struggle where scraping happens inside third-party tools or where nobody can see what a vendor collected. An internal review gives you a view of your own position, but it is not an independent opinion. Only independent auditors or assessors issue reports, so plan for that separately if a regulator, customer or contract asks for one.
What is the fine ceiling for breaching this prohibition?
Under Article 99(3), breaching a prohibition in Article 5, including this one, carries fines of up to EUR 35 million or, for an undertaking, 7% of total worldwide annual turnover for the preceding financial year, whichever is higher. For large groups, the turnover limb is usually the larger figure, so the cap grows with revenue. The prohibition has applied since 2 February 2025 under Article 113. National market surveillance authorities set the actual fine in each case, and the ceiling is a maximum, not a prediction. Read the full text of the regulation through the EUR-Lex text of Regulation (EU) 2024/1689 and confirm the figures with counsel.
How does this ban differ from high-risk remote biometric identification?
The two rules address different things. The ban in Article 5(1)(e) targets building or expanding facial recognition databases through untargeted scraping, and it applies whatever the system's purpose. Remote biometric identification systems that are not prohibited are high-risk under Annex III point 1(a), but only where Union or national law permits their use. A lawful system can therefore still carry the full high-risk obligations, such as risk management, documentation, logging and human oversight. If a database was built by untargeted scraping, the system is prohibited regardless of how well its high-risk paperwork is prepared. Check the Annex III text on EUR-Lex for the wording of point 1(a).
Does footage from our own CCTV cameras count as a source?
The prohibition names CCTV footage alongside images from the internet, so footage is in scope as a source for building or expanding a database. The key question is whether the collection is untargeted. Footage that a security team reviews for a defined purpose is treated differently from footage that is bulk-harvested to extract faces for enrollment. Review every feed that feeds a recognition system, including footage from sites, partners and vendors, and record the purpose and legal basis for each. Data protection rules may also apply to the same footage, so align this review with your GDPR work. Confirm the boundary between targeted and untargeted collection with counsel before you decide on the design.
When should we bring in an implementation partner for this ban?
Bring in help when the inventory covers many systems or vendors, when pipelines need technical checks, or when you need evidence packaged for an independent assessor. DeployOpen plans, implements and documents systems and evidence inside your own infrastructure, under a fixed scope agreed in writing before work starts. The organization still owns its controls and decisions, and DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that. Ask any partner for the written scope, the named deliverables, and which evidence will be produced in your environment.
What technical evidence can our engineers produce for enrollment sources?
Start by logging the source of every image added to a recognition database, including the system, timestamp, approval reference and purpose. General observability tools can help with the surrounding workflow. For example, Langfuse's observability documentation describes how traces capture inputs, outputs, timing and metadata for LLM calls, retrieval steps and tool executions. Those traces suit LLM and agent pipelines, but a facial recognition pipeline needs its own enrollment records. Restrict access to these logs, minimize the personal data they hold, and check the retention rules under data protection law. Confirm with each tool's documentation which fields it captures before you rely on it as evidence.
How DeployOpen scopes and evidences the scraping ban
DeployOpen approaches Article 5(1)(e) by first establishing whether your systems build or expand facial recognition databases from scraped images, then documenting that answer for the people who must check it. We plan, implement and document self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and we prepare the evidence. We do not issue audit reports or certifications; independent auditors and certification bodies do.
How we scope
- A written scope names each AI system, data source and collection method covered by the ban review.
- Scope also records which systems never scrape images, so the negative finding is documented.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We map every data pipeline that could feed face images into training, indexing or matching stores.
- We configure collection controls such as allowlisted sources, denylisted crawlers and ingestion gates, and document each one.
- We integrate logging of data source and provenance so each ingested image can be traced.
How we hand over
- We hand over a written inventory of data sources, collection methods and the controls that block scraping.
- Security test results for the collection pipeline are documented with findings and remediation notes.
- Your counsel decides whether the evidence supports a compliance position.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover re-running collection tests when scraping sources, crawlers or models change.
- Pricing follows from the written scope; confirm response expectations and renewal terms in the agreement.
