# Veracly — full text of the public English pages

Generated 2026-09-11 from the published pages (regenerated on each release, not
hand-written). The URL index is at https://veracly.app/llms.txt. Localized versions of
posts and pages live at https://veracly.app/<locale>/... for de, fr, es, it, nl, pl.
Nothing here is legal advice; a clean scan result means no client-side
evidence was found on the pages crawled, not that a site is compliant.

---

## Website Accessibility & Cookie Compliance Scanner
URL: https://veracly.app

 Veracly
Sign in Start free scan
EAA · GDPR · ADA · UK Equality Act · AODA · DDA (AU) · EU AI Act
# Compliance monitoring
you can actually prove.
Continuous WCAG, GDPR cookie, and tracking-pixel scanning for SMB websites, delivered as a cryptographically signed report your lawyer, auditor, or buyer can independently verify. Plain English, with copy-paste fixes for your developer.
No URL to hand? Paste your code and check it here — free, no signup.
No credit card Compliance report in 5 minutes GDPR compliant · EU-hosted Independently verifiable
Certificate of scan 004182
veracly-demo.com
Issued 18.07.2026
Framework EAA / BFSG
Pages examined 32
Findings 11
Manual review 4
KEY 4f9c a028 71bd e35a
SIG 9d41f6e2c8b70a5539ee1c4d
Under
seal Signature checkable against our published key. No account needed.
The report
## A report your team can
actually act on.
Multi-page, severity-ranked, in your language. Copy-paste developer fixes for the top priorities, a complete inventory of every remaining issue, and a clear per-jurisdiction compliance score you can hand to your counsel. White-label with your logo on the Agency tier.
- Executive summary, plain language
- Per-regulation compliance scoring
- Full violation inventory with affected-page counts
- Copy-paste developer fix snippets for top priorities
- White-label option for agencies
Download the sample report (PDF) Real reports carry a live, independently verifiable ID. This sample uses illustrative data.
Independently verifiable
## Don’t take our word
for it.
Every Veracly report is cryptographically signed (Ed25519) and anchored in a public audit ledger. Anyone holding it, your lawyer, an auditor, a buyer, a regulator, can confirm who issued it, when, and that it hasn’t been altered. Verification runs entirely in their browser, with no Veracly account and no Veracly server on the trust path. That independence is something a tool that also sells the fix can’t offer.
- Signed with Ed25519
- Anchored in a public ledger
- Checked in your browser, no account
Verify a report See our own scorecard →
Independently verifiable
issuer Veracly · RR Sols Pty Ltd
signature Ed25519 · valid
ledger anchor confirmed
document hash SHA-256 · matches
trust path in-browser · no server
Technical checks relevant to these frameworks
WCAG 2.1 AA · GDPR + ePrivacy · EAA (EN 301 549) · ADA Title III · UK Equality Act · AODA
Why Veracly
## Four things every other
compliance tool gets wrong.
### Multi-jurisdiction by default
One scan reports against EAA, GDPR, ADA, UK Equality Act and AODA. Your visitors come from more than one country; we score against every jurisdiction that applies.
### Plain English, copy-paste fixes
Not ’aria-required-children missing.’ We say ’Your contact form is invisible to screen readers.’ Then we give your developer the three-line fix.
### Honest. No widgets, no lies.
We don’t inject magic JavaScript that ’fixes’ your site. The FTC fined that approach $1M. We scan honestly and tell you what to fix.
### Independent by design
We audit your compliance but don’t sell the fixes, so our signed report carries no conflict of interest. Anyone can verify it cryptographically, without trusting us. A tool that also sells the remediation can’t say that.
How it works
## From signup to first report
in under five minutes.
01
### Add your domain
Enter the URL, pick your country and the countries your visitors come from. We’ll automatically adjust the technical specifications relevant to you depending on the website location and the customer location.
02
### We scan continuously
Up to 500 pages, every week, for accessibility, cookie, pixel, and policy issues. New violations alert you within 4 hours.
03
### Get a localized PDF
A multi-page report in your language, with severity-ranked fixes and per-jurisdiction scores. Forward to your developer; we handle the rest.
What we monitor
## Seven modules. One scan.
Each module applies a standardised set of technical and content-based checks derived from published requirements and specifications. Findings are generated through automated rule-based analysis and are provided for informational purposes.
New: EU AI Act, Article 50 transparency rules apply 2 Aug 2026. Every scan now includes a free readiness check.
Accessibility
### WCAG 2.1 AA
Automated checks across all four principles (WCAG 2.1 A/AA plus 2.2 target size), with a criterion-by-criterion inventory of every WCAG 2.2 A/AA criterion showing what is automated and what still needs a person. AI-explained fixes for top priorities; full inventory with selector and severity for the rest.
Privacy
### Cookies & consent
GDPR, ePrivacy, UK PECR. Pre-consent capture, reject-all parity, banner accessibility.
Tracking
### Tracking pixels
Meta, Google, TikTok, LinkedIn and the other major ad & analytics platforms. PHI/PII risk mapping included.
Policies
### Privacy policy clauses
Required clauses by jurisdiction. Last-updated checks. Missing-section alerts.
Statements
### Accessibility statements
Required by EAA in most member states. We check presence, content, and freshness.
UX
### Cookie banner UX
Granularity, parity, accessibility, the things regulators are now actively fining.
AI Act
### AI transparency
Detect undisclosed chatbots and missing AI-use notices, mapped to EU AI Act Article 50, effective 2 Aug 2026.
Standards & legislation
## Every check traces back to its source.
Veracly provides a technology-assisted review based on a structured catalogue of predefined criteria derived from relevant statutes, standards, and technical specifications, rather than relying on a one-size-fits-all checklist. The assessment follows a standardised, rule-based methodology designed to systematically identify accessibility and data-protection issues. For transparency, each criterion is linked to its underlying source document, so you can trace individual findings back to the relevant provision or standard.
### European Accessibility Act
- Directive (EU) 2019/882: European Accessibility Act
- Barrierefreiheitsstärkungsgesetz (BFSG): German transposition
- EN 301 549 v3.2.1: harmonised ICT accessibility standard
- WCAG 2.2 (W3C Recommendation)
- WCAG 2.1 (W3C Recommendation)
### GDPR & ePrivacy
- Regulation (EU) 2016/679: GDPR
- Directive 2002/58/EC: ePrivacy Directive (Art. 5(3))
- § 25 TDDDG: German cookie-consent transposition
- EDPB Guidelines 03/2022: deceptive design patterns
- CJEU Planet49 (C‑673/17): consent / pre-ticked boxes
### Americans with Disabilities Act
- ADA Title II web rule: DOJ final rule (2024)
- ADA.gov: web & mobile accessibility rule (fact sheet)
- WCAG 2.2 (W3C Recommendation)
- WCAG 2.1 (W3C Recommendation)
### UK Equality Act 2010
- Equality Act 2010
- Privacy and Electronic Communications Regulations 2003 (PECR)
- WCAG 2.2 (W3C Recommendation)
- WCAG 2.1 (W3C Recommendation)
### Canada — web accessibility (AODA, Ontario)
- Accessibility for Ontarians with Disabilities Act, 2005 (Ontario)
- Accessible Canada Act, S.C. 2019, c. 10 (federally regulated entities)
- Accessible British Columbia Act, SBC 2021, c. 19
- Integrated Accessibility Standards Regulation, O. Reg. 191/11 (Ontario)
- WCAG 2.0 (W3C Recommendation)
### Australia (DDA + Privacy Act)
- Disability Discrimination Act 1992 (Cth)
- AHRC: Guidelines on equal access to digital goods and services (April 2025)
- Privacy Act 1988 (Cth)
- OAIC: Australian Privacy Principles (APP) Guidelines
- WCAG 2.2 (W3C Recommendation)
- WCAG 2.1 (W3C Recommendation)
Scope: the AHRC’s April 2025 Guidelines name WCAG 2.2 Level AA as the minimum for the Disability Discrimination Act s 24 duty. They are guidance, not a binding standard. Veracly automates the WCAG 2.1 A/AA rule set plus SC 2.5.8 Target Size, so five of the six criteria WCAG 2.2 adds at Level A/AA are not tested: 2.4.11 Focus Not Obscured (Minimum); 2.5.7 Dragging Movements; 3.2.6 Consistent Help; 3.3.7 Redundant Entry; 3.3.8 Accessible Authentication (Minimum). None can be verified from a single automated page inspection: they turn on focus and pointer interaction states, multi-step processes, authentication, or consistency across a set of pages. Every Australian report repeats this.
### EU AI Act: Transparency (Art. 50)
- Article 50: Transparency obligations (EU AI Act)
- Regulation (EU) 2024/1689: Artificial Intelligence Act
- Code of Practice on marking and labelling AI-generated content (EC)
Links point to official government and standards-body sources. Veracly is a compliance-monitoring tool, not a law firm, reports are not legal advice.
Continuous monitoring
## More than a one-time scan
Free scanners give you a snapshot. Veracly is the programme that keeps the snapshot accurate as your site changes.
Criterion With Veracly DIY with free tools
Cadence Weekly automated re-scans, alerts on regressions Re-run a scanner manually whenever you remember
Coverage EAA · GDPR · ADA · UK Equality · AODA in one report One regulation per tool, merged in a spreadsheet
Categories Accessibility, cookies, pixels, policy docs in one scan Separate tool per category, separate workflow
Audit trail Timestamped, jurisdiction-tagged PDFs in 7 languages Screenshots, exports, manual translation
Comparison describes general DIY workflows using free or freemium scanners. Specific tool capabilities vary by vendor.
Pricing
## Less than the cost of one demand letter.
Annual billing saves 2 months. Cancel anytime.
Starter
For solo practices and indie sites
€79/mo
- 1 site · 50 pages
- Monthly scan
- EAA, GDPR, ADA, UK, AODA, AU — whichever apply, up to 3 markets
- Email alerts
- Signed PDF + dashboard
Most popular
Growth
For most growing SMBs
€199/mo
- 3 sites · 250 pages each
- Weekly scan
- EAA, GDPR, ADA, UK, AODA, AU — whichever apply, up to 8 markets
- Email + Slack alerts
- Signed PDF + dashboard
Pro
For multi-location practices
€399/mo
- 10 sites · 500 pages each
- Daily, weekly, or monthly
- EAA, GDPR, ADA, UK, AODA, AU — whichever apply, unlimited markets
- Email + Slack alerts
- Signed PDF + dashboard
Agency
White-label for agencies
€599/mo
- 25 sites · 1,000 pages each
- Daily, weekly, or monthly
- EAA, GDPR, ADA, UK, AODA, AU — whichever apply, unlimited markets
- Email + Slack alerts
- White-label PDFs
- Client sub-accounts
All prices exclude VAT. VAT is added at checkout based on your billing address; EU businesses with a valid VAT ID are reverse-charged.
Need unlimited sites, custom SLA, or DPA negotiation? Talk to us about Enterprise .
Veracly vs. overlays
## Honest scanner, not magic widget.
Aspect Veracly Overlay tools
Approach Honest scan + fix guidance Inject JavaScript, claim ’compliance’
FTC verdict No regulator action $1M settlement (Jan 2025)
Multi-jurisdiction EAA · GDPR · ADA · UK · CA · AU US-only, accessibility-only
Lawsuits avoided Yes, you actually fix things 800+ users still sued
Questions
## Things people ask before signing up.
What is Veracly? +
Veracly is a website compliance monitoring service for small and medium businesses. Using a deterministic, rule-based engine, it scans your site against a structured set of technical specifications relevant to accessibility (European Accessibility Act / BFSG, ADA, UK Equality Act, AODA), privacy (GDPR and the ePrivacy cookie rules), and AI transparency (EU AI Act Article 50), then gives you a plain-English, severity-ranked report with a copy-paste fix for each finding.
How does a Veracly scan work? +
Veracly crawls your pages, runs the axe-core accessibility engine against the rendered DOM, and records every network request, cookie, and storage write that happens before a visitor interacts with your cookie banner. It then traces the applied criteria back to the regulatory frameworks relevant to each client and visitor location and gives you a compliance score based on those locations. Every finding is reproducible by you in your own browser’s DevTools, the report shows you exactly how.
What is the difference between the free scan and a paid report? +
The free scan checks a single page and emails you a signed PDF in about five minutes, same engine, same scoring, same cryptographic signature as the paid tier. Paid plans add continuous multi-page monitoring, all jurisdictions in one report, scheduled re-scans, regression alerts, and a dated attestation history you can share.
Can Veracly make my website compliant? +
No, and that is deliberate. Veracly is an independent monitoring and reporting service: it tells you precisely what to fix and how, but it does not sell the remediation. Compliance is achieved when your developer fixes the identified issues; no tool can make a website compliant on its own. Staying independent is what lets Veracly’s findings be credible to a regulator, auditor, or counsel.
Is a Veracly report legal advice? +
No. A Veracly report is a technical compliance scan generated by automated software. It is informational only, not legal advice, not a regulatory opinion, and not a § 317 HGB / ISA audit. The analysis is based on predefined rule sets using a deterministic engine and does not claim completeness or exhaustiveness of applicable legal requirements. Results may vary depending on jurisdiction and interpretation. The report is intended to support qualified legal counsel in reviewing and acting upon the findings within the relevant legal framework.
Can someone verify my report without a Veracly account? +
Yes. Anyone holding the PDF can visit the verify link and reconcile the signature against Veracly’s public key, published at veracly.app/.well-known/veracly-signing-key.json. Verification runs in their browser, no Veracly account and no Veracly server in the trust path, which is what makes it credible to a third party.
Compliance questions, answered →
Keep reading
- GDPR cookie compliance
- WCAG 2.1 AA accessibility check
- EAA compliance for SMBs
- ADA website compliance check
- Website compliance scans explained
Blog →
## See your first report
in five minutes.
Free scan, now including the EU AI Act (Art. 50) transparency check. No card. No overlay.

---

## Compliance FAQ: EAA, GDPR, ADA & EU AI Act
URL: https://veracly.app/faq

 Veracly
Sign in Start free scan
Help center
# Compliance questions, answered
Plain-English answers on website accessibility, privacy and cookies, and EU AI Act transparency, and how Veracly’s independent, cryptographically verifiable reports work.
## Veracly basics
### What is Veracly?
Veracly is a website compliance monitoring service for small and medium businesses. Using a deterministic, rule-based engine, it scans your site against a structured set of technical specifications relevant to accessibility (European Accessibility Act / BFSG, ADA, UK Equality Act, AODA), privacy (GDPR and the ePrivacy cookie rules), and AI transparency (EU AI Act Article 50), then gives you a plain-English, severity-ranked report with a copy-paste fix for each finding.
### How does a Veracly scan work?
Veracly crawls your pages, runs the axe-core accessibility engine against the rendered DOM, and records every network request, cookie, and storage write that happens before a visitor interacts with your cookie banner. It then traces the applied criteria back to the regulatory frameworks relevant to each client and visitor location and gives you a compliance score based on those locations. Every finding is reproducible by you in your own browser’s DevTools, the report shows you exactly how.
### What is the difference between the free scan and a paid report?
The free scan checks a single page and emails you a signed PDF in about five minutes, same engine, same scoring, same cryptographic signature as the paid tier. Paid plans add continuous multi-page monitoring, all jurisdictions in one report, scheduled re-scans, regression alerts, and a dated attestation history you can share.
### Can Veracly make my website compliant?
No, and that is deliberate. Veracly is an independent monitoring and reporting service: it tells you precisely what to fix and how, but it does not sell the remediation. Compliance is achieved when your developer fixes the identified issues; no tool can make a website compliant on its own. Staying independent is what lets Veracly’s findings be credible to a regulator, auditor, or counsel.
### Is a Veracly report legal advice?
No. A Veracly report is a technical compliance scan generated by automated software. It is informational only, not legal advice, not a regulatory opinion, and not a § 317 HGB / ISA audit. The analysis is based on predefined rule sets using a deterministic engine and does not claim completeness or exhaustiveness of applicable legal requirements. Results may vary depending on jurisdiction and interpretation. The report is intended to support qualified legal counsel in reviewing and acting upon the findings within the relevant legal framework.
## Accessibility law (EAA, ADA, UK, AODA)
### What is the European Accessibility Act (EAA / BFSG)?
The European Accessibility Act, Directive (EU) 2019/882, requires a wide range of digital products and services sold to EU consumers to be accessible. Each member state transposes it into national law; in Germany that is the Barrierefreiheitsstärkungsgesetz (BFSG). In practice, conformance is measured against EN 301 549, which points to WCAG 2.1 AA success criteria.
### When did the European Accessibility Act take effect?
The EAA’s national rules apply from 28 June 2025. From that date, in-scope businesses selling to EU consumers are expected to meet the accessibility requirements. Some member states allow limited transition periods for existing service contracts, but new digital services are covered now.
### Does the European Accessibility Act apply to my business?
It applies to businesses offering covered products and services to EU consumers, including e-commerce, banking, e-books, transport, and telecoms. There is a microenterprise relief for service providers with fewer than 10 staff and annual turnover or balance sheet at or below €2 million, but it is narrow and does not cover products. If you sell online to EU consumers, assume you are likely in scope and confirm with counsel.
### What is WCAG 2.1 / 2.2 AA?
WCAG (Web Content Accessibility Guidelines) is the W3C standard for accessible web content, organised into A, AA, and AAA levels. AA is the bar most laws point to. Veracly assesses your site against WCAG 2.2 AA, the current version, and also reports the legal-floor score (WCAG 2.1 AA for the EAA, ADA and UK Equality Act; WCAG 2.0 AA for AODA) so you can see both.
### Does the ADA apply to my website?
For most private businesses, US courts have applied the Americans with Disabilities Act (Title III) to websites through case law such as Robles v. Domino’s and Gil v. Winn-Dixie, generally measuring against WCAG 2.1 AA. For state and local government sites, the 2024 DOJ Title II rule sets WCAG 2.1 AA explicitly. If you have US visitors, the ADA is a real exposure.
### What does the UK Equality Act require for websites?
The UK Equality Act 2010 (§20) places a duty on service providers to make reasonable adjustments so disabled people can use a service, which courts and the EHRC treat as including websites. WCAG 2.1 AA is the practical benchmark used to demonstrate those adjustments have been made.
### What is AODA and who must comply?
The Accessibility for Ontarians with Disabilities Act (AODA) requires Ontario organisations to make their web content accessible. Its Integrated Accessibility Standards Regulation (O. Reg. 191/11, §14) references WCAG 2.0 AA as the legal floor. Veracly scores AODA against that 2.0 floor while also showing the broader 2.2 view for comparison.
## Privacy & cookies (GDPR / ePrivacy)
### What do the GDPR and ePrivacy rules require for cookies?
Under the ePrivacy Directive (Art. 5(3)) and the GDPR, non-essential cookies and trackers, analytics, advertising pixels, and similar, may only be set after the visitor gives prior, informed, freely-given consent. Strictly necessary cookies are exempt. The most common failure Veracly detects is trackers that fire on page load, before any banner interaction.
### What is § 25 TDDDG?
§ 25 TDDDG (Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz) is the German transposition of the ePrivacy Directive’s Art. 5(3). It requires consent before storing or reading information on a user’s device, i.e. before setting non-essential cookies or using local/session storage for tracking. Unlike the BFSG, it has no microenterprise exemption.
### What are "pre-consent" trackers and why do they matter?
A pre-consent tracker is a cookie, storage entry, or third-party request that fires before the visitor accepts the cookie banner. Because consent must come first, these are among the clearest and most reproducible privacy issues, you can confirm them yourself in DevTools (e.g. F12 → Network, then reload and watch which requests fire before any click).
### Does my cookie banner need a "Reject all" button?
Regulators (including the EDPB and several national authorities) take the position that rejecting non-essential cookies must be as easy as accepting them, typically an equally prominent "Reject all" alongside "Accept all" on the first layer. A banner that only offers "Accept" or buries the reject option is a common, reproducible finding.
### Which trackers and pixels does Veracly detect?
Veracly’s scanner currently fingerprints 74 third-party trackers, pixels and embeds, and flags any that load or fire before the visitor gives consent. This list is generated directly from the scanner, so it always matches exactly what the engine checks: Advertising & ad pixels: AdRoll, Criteo, DoubleClick, Google Ads, LinkedIn Insight, Meta Pixel, Microsoft Bing Ads, Outbrain, Pinterest Tag, Reddit Pixel, Snapchat Pixel, Taboola, TikTok Pixel, Twitter Pixel. Analytics: AB Tasty, ActiveCampaign, Adobe Analytics, Amplitude, Brevo (Sendinblue), Cloudflare Insights, Drip, Google Analytics 4, Heap, Hotjar, HubSpot, Klaviyo, Mailchimp, Marketo, Matomo, Microsoft Clarity, Mixpanel, Optimizely, Pendo, Plausible, Quantcast, Salesforce Pardot, Segment, Snowplow, VWO, Yandex Metrika. Session replay & heatmaps: Crazy Egg, FullStory, Inspectlet, LogRocket, Lucky Orange, Mouseflow, Plerdy, SessionStack, Smartlook, UXCam. Social media embeds: Instagram embed, Twitter widgets, Vimeo embed, Wistia, YouTube embed (no-cookie variant missing). Other trackers & services: Adobe Launch, Calendly, Crisp, Datadog RUM, Drift, Google Tag Manager, Intercom, LiveChat, New Relic Browser, Olark, Sentry, Tawk.to, Typeform, Userlike, Zendesk Chat. CDN & web fonts: Google Fonts (live), jsDelivr CDN. Bot detection & fingerprinting: Cloudflare Turnstile, Google reCAPTCHA v3. It is not a list of every tool in existence, and no scan can promise it caught everything, but it covers the services most often found on EU small-business sites.
## EU AI Act (Article 50)
### What is Article 50 of the EU AI Act?
Article 50 of the EU AI Act sets transparency obligations: you must tell people when they are interacting with an AI system (such as a chatbot), and AI-generated or manipulated content (text, images, audio, video) must be marked as such. It is a transparency duty, separate from the Act’s high-risk AI rules.
### When does EU AI Act Article 50 apply?
The Article 50 transparency obligations have applied EU-wide since 2 August 2026. If your site uses a chatbot or publishes AI-generated content for EU visitors, the duty already applies.
### Do I have to tell visitors they are talking to an AI chatbot?
Yes, under Article 50(1), when a visitor interacts with an AI system such as a chatbot or AI assistant, you must make it clear they are not talking to a human (unless it is obvious from the context). Veracly detects common chat/assistant widgets and checks whether a clear AI disclosure is present.
### Does Veracly check AI Act "compliance"?
Veracly runs a transparency check, it flags an undisclosed chatbot or a missing AI-use notice so you can address them now that Article 50 applies. It is a readiness signal, not a determination that your site is "AI Act compliant", and it does not cover the Act’s high-risk AI governance requirements. Transparency in AI use is an important issue addressed, for example, by Art. 50 of the EU AI Act.
## Reports & independent verification
### How is a Veracly report verified?
Every report is cryptographically signed (Ed25519) and anchored in Veracly’s audit ledger. The signature covers the exact PDF, so any tampering is detectable. The report carries a Verification ID and a verify URL so its provenance can be confirmed independently.
### Can someone verify my report without a Veracly account?
Yes. Anyone holding the PDF can visit the verify link and reconcile the signature against Veracly’s public key, published at veracly.app/.well-known/veracly-signing-key.json. Verification runs in their browser, no Veracly account and no Veracly server in the trust path, which is what makes it credible to a third party.
### How long is my report available?
A free-scan report stays downloadable for 60 days, and its cryptographic verification record is kept for the same window; the report itself never expires once you have saved the PDF. Paid reports remain available for your account, and their audit-ledger anchors persist so the report stays independently verifiable over time.
### Can I give my report to a regulator, lawyer, or buyer?
Yes, that is what it is built for. Because the report is independently verifiable without trusting Veracly, you can hand it to counsel, an auditor, a regulator, or a buyer doing due diligence, and they can confirm it is genuine and unaltered. Paid sites can also share a live, dated attestation timeline.
## Plans & pricing
### How much does Veracly cost?
A one-page scan is free. Paid plans are billed monthly per site and scale with how many pages and sites you monitor; current tiers and prices are on the pricing section of veracly.app. There is no charge to run the free scan and see a full signed report first.
### What is included in a paid plan?
Paid plans add continuous, scheduled monitoring across multiple pages; every jurisdiction we monitor plus the EU AI Act check in a single report; regression alerts when a new issue appears; a dated, independently verifiable attestation history; and signed PDF reports you can share with counsel or buyers.
### Does Veracly offer an agency or reseller plan?
Yes. The Agency plan is built for agencies and consultants who look after compliance for several clients. It adds white-label PDF reports and client sub-accounts, so each client’s sites, scans, and reports stay separate under one Veracly subscription. It currently covers up to 25 sites shared across all your sub-accounts.
### How do I set up and manage client sub-accounts?
Once you are on the Agency plan, open Sub-accounts in your dashboard and add one per client, just a name and country to start. Then use Manage sites on that sub-account to add the client’s websites; each one draws from your shared site allowance and keeps its own scans and reports. You can rename a sub-account or change its country at any time, and deleting one removes its sites, scans, and reports for good. There is no extra charge per sub-account.
### How does billing work across agency sub-accounts?
You pay a single Agency subscription; your clients do not pay Veracly. The plan’s site allowance, currently 25 sites, is shared across your agency and all of its sub-accounts, so adding a site for any client draws from the same pool. Your dashboard shows how much of the shared allowance is in use.
### Can my clients log in to Veracly to see their own reports?
Today the Agency plan is managed by your team: you run the scans and share the signed PDF reports with each client, who can verify them independently without an account. Direct read-only client logins are on our roadmap, if that would help your workflow, tell us at support@veracly.app.
## Data, security & trust
### What data does Veracly collect when it scans my site?
Veracly scans only what a normal visitor’s browser would load: public page content, the third-party requests your pages make, and the cookies and storage they write. It detects client-side tracking; server-side data flows (such as server-to-server pixel APIs) are out of scope and noted as such in the report.
### How long does Veracly keep my data?
Scan results and generated reports are kept only as long as needed for the service and then deleted on a fixed schedule, free-scan reports for 60 days, with longer windows for paid scan data and the audit-ledger anchors that keep reports verifiable. The full, current retention periods are published in Veracly’s privacy notice.
### Why is Veracly "independent", and why does that matter?
Veracly checks compliance but does not sell the fix, so its findings carry no conflict of interest. A tool that also sold you the remediation could not credibly certify it. That independence is what makes a Veracly report something you can put in front of a regulator, auditor, or buyer.
## Still have a question?
Run a free one-page scan and see a full signed report in minutes, or get in touch.
Run a free scan Contact us

---

## About: why we built an honest compliance scanner
URL: https://veracly.app/about

 Veracly
Sign in Start free scan
About
# An honest scanner. Not a magic widget.
We build website-compliance monitoring that tells SMBs what is broken and how to fix it, across every regulation that applies, in plain English, at a price that does not require a procurement cycle.
Why we exist
## Three regulatory waves are hitting the same websites at once.
Since June 2025 the European Accessibility Act has applied to every consumer-facing service in the EU, with per-country fines reaching €1 million. Every business that ships a product to EU residents, including non-EU companies, is in scope.
On top of that, GDPR cookie enforcement, US state privacy laws, and ADA-style accessibility lawsuits have all accelerated. The buyer is rarely a developer. It is usually an office manager or owner who Googles "is my website compliant" the morning after a demand letter arrives.
The existing options for that buyer are either widgets that the FTC has explicitly sanctioned (overlay tools), or enterprise compliance reviews priced at five figures a year. Veracly is the third path: a continuous, plain-English compliance scan at a self-serve price, covering every regulation that matters for the visitors you actually have.
What we believe
## Four principles that decide what we will and will not ship.
### Honest, not magical.
We do not "fix" your site for you. We tell you exactly what is broken and what to change, so you can repair the site and ensure accessibility and data protection for your customers. Overlay tools that promise one-click compliance are discredited; we will not build one even if it would be easier to sell.
### Multi-jurisdiction by default.
One scan checks for technical issues relating to multiple frameworks simultaneously, EAA, GDPR, ADA, UK Equality Act, AODA, plus the country-level overlays relevant to your visitors. No "only if you upgrade" gating on whole frameworks.
### Plain English, and six other languages.
Findings come out in the language your team actually reads. No "aria-required-children" jargon, "your contact form’s name field is invisible to screen readers; here is the three-line fix."
### Built for the office manager, not the developer.
Every report is a PDF, every fix is copy-paste, every email is something a non-technical owner can forward to their agency or their dev. Our buyer does not have a security team.
Founder
## Built by the team behind Veracly.
PP
Purushotham Reddy Pamuluru
Founder and Director, RR Sols Pty Ltd
Purushotham started RR Sols Pty Ltd in Sydney to build SMB-friendly compliance and analytics tools. After running the RR Sols Pty Ltd product, he saw the same pattern repeating across European customers in 2025, three regulatory deadlines colliding, no affordable option in the middle of the market, and built Veracly to close that gap.
puru@rrsols.com.au LinkedIn
Company
## The procurement-team facts.
Legal entity
RR Sols Pty Ltd
Trading as
Veracly
Country of registration
Australia
Founded
2026
ABN
56 672 722 486
ACN
672 722 486
Registered office
136 Arthur Allen Drive, Bardia NSW 2565, Australia
Primary data residency
Helsinki, Finland (Hetzner · EU)
Article 27 EU representative
Prighter EU Rep GmbH, Vienna
## See it on your own site.
A free scan returns a real PDF report in under five minutes. No credit card, no account.
Run a free scan Talk to us

---

## Free HTML compliance checker
URL: https://veracly.app/tools/code-check

 Veracly
Sign in Start free scan
Free tool, no signup
# Paste your code. See what breaks.
We read your markup with the same rules engine behind our signed reports, and hand back every issue with a fix you can paste straight in. Nothing is held back.
Your HTMLA full page gives the most complete result. A fragment works too — page-level rules are skipped and listed as not checked.
Your markup is analysed and discarded. It is never executed, never stored, and never sent anywhere else. We keep only the number of issues found, the size of the paste, the language you are reading in, and a one-way fingerprint used to spot duplicate submissions — never the markup itself.
Paste some markup and hit “Run the check”. Results appear here.
## How this works, exactly
Your markup is parsed into a real DOM, then graded by axe-core against WCAG 2.2 A and AA plus the axe best-practice set — the same engine and the same rule set our paid scans use. Note that best-practice rules (landmarks, heading order, list structure) are good practice rather than legal requirements.
Your code is never executed. Scripts, inline event handlers and external resources are all inert: the parser is configured to build the document and nothing else, so pasting a page with tracking tags in it cannot cause anything to run or to phone home.
That safety is also the limit. Because nothing runs, we can see that a tracking tag is present but not whether it fires before consent; we can see a heading order but not a colour contrast, which depends on layout. Those checks need a live page, which is what a full scan does.

---

## Trust Center: report verification and scan methodology
URL: https://veracly.app/trust

Veracly
# Don’t trust us. Verify us.
A compliance report is only worth anything if you can check it. So Veracly is built so you don’t have to take our word for a single thing: every report is cryptographically signed and independently verifiable, findings distinguish reproducible observations from contextual signals that require review, and we run exactly the same scan on ourselves.
Veracly, scanned by Veracly
## Our own compliance scorecard
veracly.app run through the same engine we sell, on 16 August 2026. This is a real, Ed25519-signed report anchored in our audit ledger, so you don’t have to believe the numbers, you can verify the report they came from.
0 violations across 59 pages · 0 critical · 1 best-practice issue no jurisdiction scores
100
EAA
100
GDPR
100
ADA
100
UK Equality
100
AODA
100
AU
Verify this signed report → Download the report (PDF)
## Every report is independently verifiable
When Veracly issues a report, it doesn’t just make a PDF. Each report is signed with an Ed25519 digital signature and its hash is written to an append-only audit ledger , a tamper-evident record that the report existed, unchanged, at that moment.
Anyone holding a report can confirm all of that at veracly.app/verify without trusting us: the page checks the signature against our public key (published at /.well-known/veracly-signing-key.json) and confirms the ledger anchor. A tampered PDF, or a report we never issued, fails the check. That is the difference between “a vendor says you’re non-compliant” and “here is a signed record you can put in front of a regulator or a buyer.”
See how verification works →
## Deterministic engine, reproduce any finding yourself
Veracly’s detection is a rule-based engine, not an AI guess. Accessibility uses the open-source axe-core ruleset; cookies, trackers and pre-consent firing are analysed deterministically; policy pages and jurisdiction rules are fixed logic. The same site always produces the same findings and the same score.
Every finding maps to a specific, citable rule, a WCAG success criterion, a GDPR Article, an ePrivacy/§ TDDDG clause, an EAA requirement, and most are reproducible in your browser’s DevTools in seconds (open F12, watch the tracker fire before the banner, or the element with no alt). You never have to take “because the tool said so” on faith.
AI is used only to phrase the report, the plain-English explanations, summary, and suggested fixes, never to detect or score anything, and always with a hand-written fallback. The full breakdown is on how Veracly uses AI .
## We have no reason to inflate a finding
Veracly checks compliance but does not sell you the fix. We don’t install a widget, we don’t bill by the issue, and we don’t profit from a scary number. A tool that also sold you the remediation couldn’t credibly certify it; our findings carry no such conflict of interest. That independence is the whole point of an outside check.
## We stand behind every finding
If you believe a specific finding is wrong, the rule didn’t reproduce, the cookie isn’t there, a value is miscomputed, tell us at corrections@veracly.app with the report ID. We respond within 5 business days , and if we’re wrong we correct or retract the report, the verify page then serves a public retraction. If a report is being misused against a site, that’s veracly.app/abuse . Standing behind accuracy, in public, is part of the product, not the fine print.
## A real, accountable company
Veracly is operated by RR Sols Pty Ltd (ABN 56 672 722 486), Sydney, Australia. There’s a named team behind it, a full legal imprint, a published privacy notice and sub-processor list, and a data-processing agreement available to customers. Where your data is processed and stored, and every third party that touches it, is disclosed, not buried.
About us · Imprint · Privacy notice · Sub-processors

---

## Verify a compliance report
URL: https://veracly.app/verify

Independent verification
# Verify a compliance report
Every report Veracly issues is cryptographically signed (Ed25519) and anchored in a public audit ledger. Anyone holding a report can confirm who issued it, when, and that it has not been altered since signing, without a Veracly account, and without trusting Veracly.
Ed25519 signature Public audit ledger Verified in your browser
## Enter the verification ID
On the final page of the PDF, look for Verification ID . It looks like123e4567-e89b-12d3-a456-426614174000.
## Why this is independent
Verification runs entirely in your browser against a public key, no Veracly server sits on the trust path, and no login is required. Veracly audits compliance but does not sell the fixes, so the attestation has no conflict of interest: a tool that also sold you the remediation could not certify it credibly. That is the point of an independent signature.
## How verification works
- Enter the Verification ID printed on the final page of the PDF, above. We look up the anchor in our public ledger.
- We return the canonical signed record: scan ID, issued-at timestamp, the SHA-256 of the PDF, the signing key fingerprint, and the Ed25519 signature.
- Your browser verifies the signature against the public key published at /.well-known/veracly-signing-key.json . Verification runs entirely in your browser, no Veracly server is on the trust path.
- (Optional) Paste the SHA-256 of the PDF in your hands. We’ll compare it against the recorded hash to confirm the file you have is the one we issued.
Retention: paid reports are retained for long-horizon verification; free-scan anchors are retired on a published schedule. The rules in force are documented at /.well-known/veracly-retention.json .

---

## How Veracly uses AI
URL: https://veracly.app/how-veracly-uses-ai

Veracly
# How Veracly uses AI
Short version: the part that decides whether your site is compliant uses no AI at all . Veracly’s scan is a deterministic, rule-based engine, the same input always produces the same findings and the same score, and anyone can reproduce them. AI is used only to write the report up in plain language. This page sets out exactly what that means, and exactly what data does and doesn’t go to the model.
## What the AI does, and what it doesn’t
Once the deterministic engine has produced its findings, Veracly uses a large language model (Mistral AI, based in France) for four wording tasks only:
- plain-English explanations of each finding;
- the report’s executive summary;
- suggested remediation snippets (how to fix a finding); and
- translating that copy into your report language.
The AI has no role in any of the following:
- Detection. Accessibility checks (axe-core), the cookie / tracker and pre-consent analysis, policy-page presence, and the jurisdiction rule packs are all deterministic code. The AI never decides that something is a violation.
- Scoring. Every per-jurisdiction score and severity comes from the rules engine, not the model. Turn the AI off entirely and the findings and scores are identical.
- Decisions about people. No automated individual decision-making within the meaning of Article 22 GDPR is performed on any person.
If the AI is ever unavailable, a provider outage, or a per-scan/per-day cost cap is reached, the report still generates using Veracly’s own hand-written fallback copy. The scan result never depends on the AI.
## Does Veracly send your website or your visitors’ data to AI?
A limited, finding-scoped slice, never your whole site, and never anything your visitors do. Here is precisely what is and isn’t sent to the model when a report is written.
What is sent , and only to phrase the report:
- the markup of the specific element that triggered a finding , for example the <img> tag missing its alt attribute, truncated to roughly one kilobyte, never the surrounding page;
- the finding type (e.g. “image-alt”, “pre-consent-tracker”);
- the URLs of the affected pages ;
- aggregate verdict data, the counts per jurisdiction, plus your site’s country and (if you set one) industry, so the summary is written in context.
What is never sent to the AI:
- your pages’ content at large, or your site as a whole;
- anything your visitors enter, view, or generate, form submissions, account data, session content;
- the cookies, trackers, and storage the scan observes. Those are the evidence for the findings, and they are analysed entirely on Veracly’s own servers, they are not forwarded to the model.
Two further points that reduce what leaves our systems at all: explanations and fixes are cached by finding type , so once the text for “image-alt in German” exists, every later report reuses it and sends nothing new; and the AI calls run at report-writing time, after the scan , the crawl itself never talks to any AI provider.
## Who processes it, and under what terms
The model is operated by Mistral AI , a provider based in France (EU), which acts as a contractual sub-processor for Veracly under a data-processing agreement. Mistral processes the finding-scoped data solely to return the requested text and, under its commercial terms, does not use it to train its models. Mistral AI is listed on our sub-processors page , and the full AI-processing disclosure, including retention and your rights, is in our privacy notice .
The same disclosure appears on every signed report Veracly issues, so a recipient holding a PDF can see the AI’s role without visiting this page.
## Why we built it this way
A compliance report is only useful if you can trust the verdict. Keeping detection and scoring deterministic means a Veracly finding is reproducible , you, or a regulator, or your own developer can confirm it from the page itself, with no “because the AI said so.” The AI earns its place only where a black box is harmless: turning a terse rule ID into a sentence a non-specialist can act on. That division, deterministic where it counts, AI only for words, is deliberate.
Questions about our AI use or data handling: privacy@veracly.app .

---

## Changelog
URL: https://veracly.app/changelog

Veracly
# Changelog
Notable changes to the scanner, the web app and the report pipeline, newest first. Dates are the day a change reached production. Anything that changes how a finding is graded names the rule, so you can compare an older report with a newer one.
12 September 2026
## Coverage inventory in every report, review items, and rule changes
### Reports
- Every report now carries a version-labelled inventory of all 55 WCAG 2.2 Level A and AA criteria, marking each as partly automated, an automated review signal, or not automated. The same inventory is saved with the report, so an older report keeps the inventory it was issued with. Per-criterion detail is on the coverage page .
- Each scorecard lists, in one sentence in the report language, the findings that jurisdiction treated as review items rather than graded failures.
- A page that returns an error is skipped; the score covers the pages that were assessed.
### Grading changes
- Cookies and browser storage written before consent: entries from recognised tracking vendors keep their severity. Entries the scanner cannot classify by name are now reported as two new low-severity review findings, pre-consent-cookies-unclassified and pre-consent-storage-unclassified, until their purpose is established.
- missing-cookie-banner now requires an observed tracker request on the page; cookie or storage names alone do not trigger it.
- tracker-not-disclosed is graded low and flagged for review, because GDPR Art. 13(1)(e) allows categories of recipients. css-orientation-lock is graded low as a review signal.
- landmark-one-main, landmark-complementary-is-top-level, tabindex and empty-heading are still reported but no longer scored by any jurisdiction; they are axe best-practice rules with no WCAG success criterion.
- Ontario (AODA) legal-floor comparison: rule types for WCAG 2.0 criteria, such as frame-title, select-name, meta-refresh and media-missing-captions, now count toward the legal-floor score; autocomplete-valid remains a 2.1 comparison only.
- media-missing-captions now reviews every video without a caption track, not only those with controls, as a low-severity review item. meta-refresh is graded low as a review item and honours the 20-hour exception in WCAG 2.2.1. Checks axe cannot decide are listed as accessibility-review-required and are not scored.
- missing-accessibility-statement (EAA) and autoplay-audio are graded low as review items: the scanner can see the pattern but not whether the duty applies or an exception is met.
- EU AI Act chatbot check: a known chat vendor without a disclosure is now a warning (medium), not a failure.
- Australia: a reported annual turnover at or below AUD 3,000,000 still applies the Privacy Act s6D small-business exemption. When no turnover is given, missing-privacy-policy is graded low with a note that applicability needs review.
10 September 2026
## Isolated scan browser, newer Chromium, fair-use limits on the free scan
### Scanning
- Each scan runs in its own isolated browser, which is discarded when the scan ends.
- Scanning and PDF rendering moved to a newer Chromium (Playwright 1.63). No rule or grading changed in this release.
### Free scan
- Fair-use limits. On top of the existing one scan per email address every 7 days, the free scan now limits submissions per network address and across the site as a whole. Most visitors will not notice them. When a limit applies, the form says which one: a site-wide busy limit, or the one-scan-per-week rule for your email address.
- If the free-scan service is unavailable, the form shows an error instead of accepting the request.
### Web app
- The web app moved to Next.js 15.
- “Start free scan” in the navigation now takes you straight to the scan form.
- Each language homepage now has search-specific title and description text, written separately from the page copy. The Trust Center , Verify, Corrections, Abuse and “How we use AI” pages are listed in the sitemap.
### Under the hood
- Third-party dependencies updated.
Something in a report looks wrong after an update? Use the corrections process . For anything else, write to support@veracly.app .

---

## Dispute a finding in a Veracly compliance report
URL: https://veracly.app/corrections

Veracly
# Dispute a finding in a Veracly report
Veracly issues signed technical compliance reports produced by automated scanning. If you believe a specific finding in a report is factually wrong, the rule did not reproduce, the cookie is not there, the contrast value is computed incorrectly, this page documents the intake channel and the response you can expect from us.
## What this channel is for
Use corrections@veracly.app if you are the operator (or representative of the operator) of a site that is the subject of a Veracly report, and you believe a specific finding is a false positive. Specifically:
- A rule is flagged but does not reproduce when you verify it independently, for example, the cookie is not set before a consent gesture in your own browser session, or the contrast ratio is within the WCAG AA threshold when measured with a reference tool.
- The finding is attributed to the wrong domain, a tracker or cookie belongs to a third-party service pre-loaded by your hosting provider, not to your own integration.
- The element selector in the report is stale, you fixed the issue before the scan ran, and the scan appears to have captured a cached or pre-deploy version of the page.
- A rule was applied to a page that is out of scope, for example, a private login portal that should not have been accessible to a public crawl.
If the report is accurate but you believe it is being used inappropriately against your site, as the basis of a cease-and-desist (Abmahnung) without independent legal review, or republished in a way that implies a regulatory verdict, that is the abuse channel, not the corrections channel. Email abuse@veracly.app instead. That channel is also documented at veracly.app/abuse .
## What to include in your dispute
To process your request quickly, include:
- The Verification ID (UUID) printed on the final page of the PDF, or the URL of the /verify/<id> page if you have it. This lets us locate the exact scan version you are disputing.
- The domain the report is about.
- Which specific finding you are disputing, the rule name (e.g. color-contrast , pre-consent-cookie ) and, if shown, the element selector or page URL.
- What you observed when you tried to reproduce the finding independently, and any supporting evidence (screenshot, DevTools export, contrast-ratio tool output).
- Whether you are the site operator, their counsel, or an authorised third party. We can act most quickly when the request comes from the operator or counsel of record.
You do not need to prove you control the domain to open a case. If a remedy requires confirming domain control (for example, reissuing the report to a different requester), we will ask for a DNS TXT record or equivalent at that point.
## Response SLA
We commit to the following response times, measured from receipt at corrections@veracly.app during Sydney business hours (Mon–Fri, public holidays excluded):
1 business day
Acknowledgement of receipt with a case number and the name of the responder.
5 business days
Initial response with our finding and proposed remedy (see below). For straightforward reproductions where the finding clearly does not fire in an independent session, this is typically faster.
Ongoing
If the case requires a re-scan or coordination with the original requester, we will keep you updated at least weekly until closed.
## Possible remedies
Depending on the outcome of our review, the remedies we can apply include:
- Re-scan and reissue. We run a fresh scan of the relevant pages, apply the same engine version, and issue a corrected report. The original verify URL is retired and a new one issued; the audit ledger records both scan IDs and the relationship between them.
- Retract. If the finding was a clear false positive, the rule did not reproduce on re-scan, we retract the original report. The verify URL serves a public retraction notice. The proof-of-existence entry stays on the audit ledger (we do not fabricate history), but the signature material for the original report is scrubbed.
- Partial correction. If the report contained multiple findings and only one is disputed and confirmed as wrong, we reissue with that finding removed and the score recalculated.
- No action. If our re-scan reproduces the finding independently, we will explain the reproduction steps and close the case without changing the record. We will share the reproduction evidence with you.
## What this channel is not
corrections@veracly.app is an accuracy-dispute channel, not a legal-services intake. A reissue or retraction from Veracly is not a substitute for the operator’s own legal review of any demand they have received based on the original report. Veracly accepts no liability for decisions made in reliance on a corrected or retracted report without independent legal advice.
We do not adjudicate disputes between the original requester and the site operator. Veracly’s obligation is to the accuracy of its own technical output, if the scan found what it says it found, the report stands.
For security vulnerabilities in Veracly’s own infrastructure, email security@veracly.app instead — that is a separate channel with a separate SLA.

---

## Report misuse of a Veracly compliance report
URL: https://veracly.app/abuse

Veracly
# Report misuse of a Veracly report
Veracly issues signed technical compliance reports to identified requesters. If a Veracly report is being used inappropriately against your site, for example as a basis for a cease-and-desist (Abmahnung) without independent legal review, in litigation without your operator being contacted first, or republished in a way that implies a regulatory verdict, this page documents the intake channel and the response you can expect from us.
## What this channel is for
Use abuse@veracly.app if you are the operator (or representative of the operator) of a site that is the subject of a Veracly report, and you believe the report is being weaponised rather than used as the technical scan output it is. Specifically:
- The report is being cited as a legal verdict, audit certification, or regulator finding. A Veracly report is none of those, it is an automated technical scan with statute cross-references. The cover-page disclaimer says so.
- The report was used as the basis of a cease-and-desist or formal demand sent to you without the sender having engaged with you first, and you would like Veracly to be on record that this was not the intended use.
- The report has been republished publicly (a “wall of shame”, a press article, a social-media thread) in a way that makes Veracly the author of an allegation about your business.
If you instead believe a specific finding in a report is factually wrong — the rule didn’t reproduce, the cookie isn’t there, the contrast value is computed incorrectly — that is the corrections channel, not the abuse channel. Email corrections@veracly.app with the report ID and the disputed finding. Corrections are handled on the same 5-business-day SLA described below.
## What to include in your report
To process your request quickly, include:
- The Verification ID (UUID) printed on the final page of the PDF, or the URL of the /verify/<id> page if you have it.
- The domain the report is about.
- A short description of how the report is being used against you, with a copy of the communication or link if you have one.
- Whether you are the site operator, their counsel, or a third party. We can act most quickly when the request comes from the operator or counsel of record.
You do not need to provide identification documents to open a case — we’ll review the report and the misuse evidence first. If a remedy requires confirming you control the subject domain, we’ll ask for a DNS TXT record or equivalent at that point.
## Response SLA
We commit to the following response times, measured from receipt at abuse@veracly.app during Sydney business hours (Mon–Fri, public holidays excluded):
1 business day
Acknowledgement of receipt with a case number and the name of the responder.
5 business days
Initial response with our position and proposed remedy (see below). For straightforward retraction requests where the requester email on the report confirms misuse, this is typically faster.
Ongoing
If the case requires re-scanning the site or coordinating with the original requester, we’ll keep you updated at least weekly until closed.
## Possible remedies
Depending on the facts of the case, the remedies we can apply include:
- Retire the verify anchor. The /verify/<id> page is moved to a retired state, so the report can no longer be presented as “independently verifiable” from our infrastructure. The proof-of-existence record stays on the audit ledger (we don’t fabricate history), but the signature material is scrubbed.
- Reissue with corrections. If the underlying scan was accurate but findings were misinterpreted, we can reissue a clarified version and retire the original.
- Retract. If the scan itself was wrong (rule did not reproduce, stale data, mis-attributed domain), we retract the report. The verify URL serves a public retraction notice referencing this page.
- Suppress requester. If the requester email anchored on the cover is the same party using the report against you, we’ll add their address to a block list for future free scans, on top of whichever remedy applies to the specific report.
- No action. If the report is being used inside its documented purpose — an operator’s own counsel reviewing it, a customer asking their own team to fix the findings — we’ll explain that and close the case without changing the record.
## What this channel is not
abuse@veracly.app is not a legal-services intake. We do not give legal advice to either side of a dispute, and a retraction or reissue from Veracly is not a substitute for the operator’s own legal review of any demand they have received. We will, on request, provide a short factual statement (case number, the action we took, the date) that an operator can cite back to the sender of the demand.
For security vulnerabilities in Veracly’s own infrastructure, please email security@veracly.app instead — that’s a separate channel with a separate SLA.

---

## How Veracly handles your data
URL: https://veracly.app/privacy

 Veracly
Sign in Start free scan
Privacy
# How Veracly handles your data.
RR Sols Pty Ltd (trading as Veracly) is the data controller for personal data processed through veracly.app and the Veracly platform. This notice sets out five processing activities with their Art. 13/14 GDPR records, plus your rights, retention windows, and international-transfer safeguards.
Last updated: 2026-08-21
This document is being finalized by our counsel.
The structure and intent below reflect what each section will cover. Until counsel signs off the final wording, treat this as informational only, not as a legally-binding policy. For specific questions in the interim, write to legal@veracly.app.
Veracly is a B2B SaaS that scans publicly accessible web pages for compliance issues. We process limited personal data, names, work emails, billing addresses, and audit logs, to deliver the service. We do not sell your data, and we do not share it with advertisers. We process personal data in five distinct activities described below.
- 01
## Who we are
RR Sols Pty Ltd (ABN 56 672 722 486, ACN 672 722 486), trading as Veracly. Registered office: 136 Arthur Allen Drive, Bardia, NSW 2565, Australia. Director and authorized representative: Purushotham Reddy Pamuluru.
- 02
## EU and UK GDPR representative
Because RR Sols Pty Ltd is established outside the EU and the UK, we have appointed representatives under Article 27 GDPR and Article 27 UK GDPR. EU residents may contact our EU representative: Prighter EU Rep GmbH, Schellinggasse 3/10, 1010 Vienna, Austria. UK residents may contact our UK representative: Prighter Ltd, 20 Mortlake High Street, London, SW14 8JN, United Kingdom. To exercise your data subject rights or to lodge a complaint, you can submit a request through Prighter’s portal at https://app.prighter.com/portal/11399422438. Please reference ID-11399422438 in any correspondence.
- 03
## How we use personal data, five activities
We process personal data in five distinct activities, each with its own legal basis, data categories, and retention window. The numbered sections below are the Art. 13/14 GDPR records for each activity, together with a note, among them, on personal data that appears on the sites we scan. Cross-cutting matters, automated processing, retention, your rights, international transfers, and security, come after those.
- 04
## Activity 1, veracly.app visitors
Data processed: daily-rotated hashed IP address (not stored raw), browser metadata, page views, referrer, and contact-form submissions (name, email, message, only if you use the form). Purpose: serve the site, respond to enquiries, and monitor performance. Legal basis: Art. 6(1)(f) legitimate interest (site operation and cookieless aggregate analytics). We use first-party, server-side request logging only, no third-party analytics, no cookies, no device fingerprinting, no consent required. Our legal pages (this page, the imprint, and the DPA) display a certificate-of-representation badge loaded from app.prighter.com, so viewing one of them discloses your IP address and browser metadata to our Article 27 representative; no cookie is set. Contact-form data retained 24 months then deleted; performance logs rotated within 30 days. Recipients: Hetzner Online GmbH (hosting, Helsinki, Finland, EU); Prighter EU Rep GmbH and Prighter Ltd (our Article 27 representatives, Vienna and London), for that badge request and for anything you send through their portal. Complaint right: your national supervisory authority or the Austrian DSB (competent for our EU representative).
- 05
## Activity 2, free-scan requesters
Data processed: email address you enter at scan time, scanned domain, scan timestamp, IP address at request time, and scan findings (public page content only, no account is created). Purpose: run the requested scan, enforce the one-free-scan-per-email-per-7-days rate limit, detect and prevent abuse. Legal basis: Art. 6(1)(f) legitimate interest in providing the scanning service you requested, for the scan itself; Art. 6(1)(f) legitimate interest for rate-limiting and abuse prevention. Retention: the ledger that enforces the rate limit (your email address and the request timestamp) is deleted after 30 days; the free PDF report and its verification record after 60 days; the scan record and its findings age out on the same 12-month window as any other scan. Recipients: Hetzner Online GmbH (hosting and worker compute, Helsinki, Finland, EU); Mistral AI (plain-English explanations for a limited number of findings, France, EU; we send only technical violation data and a short HTML snippet); Resend, Inc. (delivery of the report email, US, SCCs). If, and only if, you tick the optional marketing box when you request the scan, we send you one follow-up email about our paid plans, on the basis of your consent (Art. 6(1)(a)); you can withdraw at any time via the unsubscribe link or by emailing privacy@veracly.app, and nothing further is sent. We do not sell your data and we do not share it for advertising purposes.
- 06
## Activity 3, outbound prospects (Art. 14 disclosure)
If you receive an outreach email from puru@veracly.app: your contact details were collected from your organisation’s own website or from a publicly accessible business directory, not from you. We contact business addresses only — a named work address at an organisation, or a generic inbox such as info@ or office@. We do not send outreach to personal email addresses, and we do not send outreach to recipients in Germany. Data processed: business email address, organisation name, publicly visible domain, and one or more compliance findings from a crawl of your publicly accessible pages. Legal basis: Art. 6(1)(f) UK GDPR, and Art. 6(1)(f) GDPR where EU law applies — our legitimate interest in telling a business operator about a technical compliance finding on their own public website. Because we write to you at a business address for which your organisation, not you personally, is the subscriber, regulation 22 of the UK Privacy and Electronic Communications Regulations does not require your prior consent. Balancing test: the finding is self-verifiable in your browser’s developer tools; you are contacted in your business capacity, not as a private individual; and the processing is limited to publicly available contact details and the findings themselves. Recipients: Microsoft (our mailbox provider, which carries the message); Hetzner Online GmbH (the unsubscribe endpoint and the suppression list, Helsinki, Finland, EU); and Prighter, if you raise your objection as a data-subject request through our Article 27 representative. Right to object (Art. 21): reply with any refusal wording, use the unsubscribe link carried in every outreach email, or email privacy@veracly.app. We stop immediately and remove you from the working list for that campaign. To make that permanent we add you to a suppression list we keep indefinitely. If you use the unsubscribe link, that list holds only a one-way cryptographic fingerprint of your address, not the address itself — enough to recognise it and drop it from every future list, but not enough for us to read it back or to contact you. If you object by reply or by email, we also keep the address, so that we can evidence that your objection was honoured. If you would like the rest of what we hold about you erased, or written confirmation, email privacy@veracly.app and we will do it. Retention: prospect records are held until you object, or 6 months from collection, whichever is earlier. That window is enforced by us purging the campaign working files, not by an automated job — prospect details are not stored in the Veracly application. Suppression-list entries are kept indefinitely, as described above. No profiling; no automated decision-making with legal or similarly significant effects. Historical note: an earlier outreach campaign to German recipients ceased on 11 June 2026; the prospect database and working files for it were erased on 11–12 June 2026, and the sent messages themselves are retained in our mailbox as a legal-defence record.
- 07
## Activity 4, account holders and paid customers
Data processed: name, work email, organisation name, billing address, VAT ID, subscription tier, scan history, PDF reports, invoices, and payment-method metadata (Stripe handles card data; we never store raw card numbers). Purpose: deliver the scanning service, bill you, send service notifications, comply with tax obligations. Legal basis: Art. 6(1)(f) legitimate interest in providing our service to our customers; Art. 6(1)(c) legal obligation (tax records, Australian Corporations Act 2001). Retention: account data for the life of the account (you can delete at /account/profile); scan results 12 months after each scan; billing records 7 years (Australian tax-record obligation). Recipients: Hetzner Online GmbH (hosting, database, and object storage, Helsinki, Finland, EU); Mistral AI (report text generation, France, EU); Clerk, Inc. (authentication, US, SCCs); Resend, Inc. (transactional email, US, SCCs); Stripe Payments Europe, Ltd. (billing, Ireland/US, SCCs); Revenue Commissioners, Ireland (VAT OSS reporting, name, country, transaction amount only, no scan content). When you verify ownership of a domain we look up its DNS TXT record, and if our own resolver has not yet seen the record we repeat the query against the public resolvers operated by Cloudflare (1.1.1.1) and Google (8.8.8.8); those queries disclose the domain name you are verifying, and nothing else. If you enable Slack alerts on a Growth, Pro, or Agency plan, we post scan results to the Slack webhook you configure, and they are received by Slack Technologies LLC in the United States under Standard Contractual Clauses. The post contains the scanned domain, its per-jurisdiction scores and any drop since the last scan, and a time-limited link to the full PDF report — so anyone with access to that Slack channel can open the report, including any personal data the scanned pages contained. We stop posting as soon as you clear the webhook or your plan no longer includes Slack alerts. Complaint right: your national DPA or the Austrian DSB.
- 08
## Personal data on the sites we scan
When you instruct the Service to scan a URL, the crawler reads publicly accessible pages and may incidentally encounter personal data published there — for example the names and contact details of employees on a contact page. We do not seek out personal data, and we do not build profiles from it. Be aware that we do retain part of what we find. Where a page fails a check, the finding keeps the offending HTML snippet and a CSS selector, and on paid scans sometimes a cropped screenshot of the element, because that evidence is what makes the report reproducible and independently verifiable. Where we cannot find a cookie banner, we also store a short diagnostic extract of those elements on the page whose markup or text mentions consent or a known consent tool, so a missed detection can be investigated. All of this is stored with the scan record and deleted on the same 12-month window. While a scan is running we capture page images so you can watch its progress; those are deleted as soon as the scan finishes. We do not retain a general copy of the pages we crawl. Where you are our customer and the scanned site is yours, we process this category of data as your processor under the Data Processing Addendum. Legal basis: Art. 6(1)(f), our legitimate interest in producing reports that are reproducible and independently verifiable. Source of the data: the publicly accessible page that was scanned. You may object at any time under Art. 21 by emailing privacy@veracly.app.
- 09
## Activity 5, subprocessor list
Current subprocessors: Clerk, Inc. (authentication, US, DPA, SCCs); Hetzner Online GmbH (compute, database, and object storage, Helsinki, Finland, EU, processed in the EEA only); Mistral AI (AI text generation in scan reports, France, EU; we send only technical violation data and a short HTML snippet, no account or billing data); Prighter EU Rep GmbH and Prighter Ltd (our Article 27 GDPR and UK GDPR representative, Vienna and London; receives data-subject requests and hosts the certificate-of-representation badge shown on our legal pages); Resend, Inc. (transactional email, US, DPA, SCCs); Stripe Payments Europe, Ltd. (payment processing, Ireland/US, DPA, SCCs). Separately, and not as a subprocessor, we report your name, country, and transaction amount to the Revenue Commissioners in Ireland for OSS VAT filing, because a legal obligation requires it. Full list with effective dates is published at veracly.app/subprocessors. Changes to this list are published there and reflected in this policy; see “Changes to this policy” below. Contractual notice and objection rights for subprocessor changes are set out in the Data Processing Addendum, which forms part of our Terms of Service.
- 10
## Automated processing and AI
Some text in your compliance report, plain-English explanations of violations, the executive summary, suggested remediations, and translations into the languages we support, is generated by an AI model run by Mistral AI (based in France, EU) acting as a sub-processor on our instructions. We send the AI the technical violation data and a short HTML snippet of the offending element; we do not send your organisation name, contact details, or any other personal data we hold about you. AI-generated text is reviewed against deterministic fallback copy, and if the AI is unavailable we fall back to that copy automatically. We are not making decisions that produce legal or similarly significant effects about you (GDPR Art 22), and you can ask for human review of any AI-written passage by emailing privacy@veracly.app.
- 11
## How long we keep it
We keep personal data only as long as it’s needed for the purpose it was collected. Scan results, including findings, the underlying raw data, jurisdiction verdicts, and generated PDF reports, are deleted 12 months after the scan completed. Free-scan PDF reports and their cryptographic verification record are kept for 60 days (2 months) from issuance, then removed. AI-usage records (model name, token counts, cost) are kept for 24 months so we can answer billing or audit questions. Free-scan history (used to enforce the one-free-scan-per-email-per-7-days limit) is kept for 30 days. Public contact-form submissions are kept for 24 months for sales follow-up, then deleted. Account data, your profile, your organization, and the link to your authentication provider, is kept for the life of the account; you can delete it yourself any time from /account/profile or by emailing privacy@veracly.app. Billing records held by Stripe and our accounting software are retained for 7 years to meet Australian tax-record obligations on RR Sols Pty Ltd. A daily automated job enforces these windows. One record deliberately outlives them: the verification anchor for an issued paid report, which holds the report’s hash, its language, the issue date, and our signing-key identifier, but no page content and no personal data. It is kept with no expiry so that a report you have already shared stays independently verifiable, and it survives erasure of the underlying scan. Closed accounts: if you close your account rather than delete it, we keep its data so you can reopen, and erase it 12 months after closure. We email you before that happens.
- 12
## Your rights (Art. 15 to 22 GDPR)
Access (Art. 15): obtain a copy of personal data we hold about you. Rectification (Art. 16): correct inaccurate data. Erasure (Art. 17): delete your data where no legal obligation requires retention, self-serve at /account/profile for account data. Restriction (Art. 18): pause processing while a dispute is resolved. Portability (Art. 20): receive account data in a machine-readable format. Object (Art. 21): object to processing on legitimate-interest grounds; we will cease unless we demonstrate compelling overriding grounds. Withdraw consent (Art. 7(3)): where consent is the legal basis, withdraw at any time without affecting prior processing. No solely automated decisions (Art. 22): we do not make decisions about you based solely on automated processing with legal or similarly significant effects. Lodge a complaint: contact your national supervisory authority, or for EU subjects the Austrian DSB (Datenschutzbehörde) as the authority competent for our EU representative Prighter EU Rep GmbH. To exercise any right, email privacy@veracly.app or use the self-service tools at /account. We respond within one month, extendable by two months for complex requests.
- 13
## International transfers and safeguards
Veracly’s application, API, background processing, database, object storage, and AI text generation all run within the European Union on infrastructure provided by Hetzner Online GmbH (Helsinki, Finland) and Mistral AI (France), both EU-based providers. EU customer data is stored in the EU. Australia does not have an EU adequacy decision. Where personal data of EEA data subjects is transferred outside the EEA to a third country lacking adequate data protection laws (including to RR Sols Pty Ltd’s systems in Australia, for engineering access, audit, and finance), we use data processing and data sharing agreements that include the European Commission’s Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), supplemented where necessary by further safeguards following a transfer impact assessment. Where personal data of UK data subjects is transferred outside the UK, we use data processing and data sharing agreements that include either the UK International Data Transfer Addendum to the EU SCCs or the UK International Data Transfer Agreement (IDTA), in either case supplemented where necessary by further safeguards following a transfer risk assessment. The remaining US-based subprocessors, Clerk (authentication) and Resend (transactional email), are covered by controller-to-processor SCCs under 2021/914 Module 2; payments contract through Stripe Payments Europe, Ltd. in Ireland, whose onward US transfers are covered by Module 3 of the same clauses. Our UK representative, Prighter Ltd, receives data in the United Kingdom, which benefits from a European Commission adequacy decision. Transfer impact assessments are conducted before engaging each non-adequate-country subprocessor. Copies of applicable SCCs and IDTAs are available on request from legal@veracly.app. For EU VAT compliance, RR Sols Pty Ltd is registered under the Non-Union OSS scheme in Ireland (EU372098920); transaction records required for VAT returns are reported to the Irish Revenue Commissioners as the OSS Member State of Identification.
- 14
## How we protect data
Encryption in transit and at rest, role-based access control, audit logging, and routine penetration testing. SOC 2 Type II is in progress.
- 15
## Changes to this policy
Material changes will be announced by email at least 30 days before they take effect. Non-material changes will be reflected in the Last updated date above.
## Verified representation
Click a badge to verify our Article 27 EU and UK representative appointment via Prighter.
powered by Prighter
Questions about this document?
## Talk to our legal contact.
If you’re a customer, prospect, or DPO with a specific question, or you’ve spotted something we should fix, drop a line and we’ll route it to the right team.
legal@veracly.app Open the contact form →

---

## The companies we trust with customer data
URL: https://veracly.app/subprocessors

 Veracly
Sign in Start free scan
Subprocessors
# The companies we trust with customer data.
A complete, public list of every third-party service that processes personal data on Veracly’s behalf, what they do, where they run, and the data they touch.
Last updated: 2026-08-21
Under GDPR Article 28, we are required to tell you, in advance, who we engage as a sub-processor and to give you a fair chance to object before a new one starts processing your data. The table below is the canonical list. We update it whenever we add, replace, or remove a vendor, and we email everyone subscribed to the change list at least 14 days before any new vendor goes live.
Vendor Purpose Data categories Infrastructure region Transfer mechanism Effective date DPA
Clerk, Inc. Authentication, session management, MFA, and the user profile UI. Name, email, password hash, MFA factors, login IP, device fingerprint. United States (multi-region) · EU residency on request EU Standard Contractual Clauses (Module 2 / 3, 2021) plus the EU, US Data Privacy Framework where the vendor is self-certified. Supplementary measures: encryption in transit (TLS 1.3) and at rest (AES-256), access logging, and contractual data-residency commitments where offered. 2026-04-27 View DPA ↗
Hetzner Online GmbH Cloud infrastructure, application, API, background workers, PostgreSQL database, and S3-compatible object storage. All service data at rest and in transit (account data, scan findings, generated reports), hosted in the EU. Helsinki, Finland (EU) Processing within the EEA, no cross-border transfer. 2026-07-18 View DPA ↗
Mistral AI SAS AI text generation for plain-language finding explanations, summaries, remediation suggestions, and translations in scan reports. Technical violation data and a short HTML snippet of the flagged element only, no account, contact, or billing data. France (EU) Processing within the EEA, no cross-border transfer. 2026-07-18 View DPA ↗
Resend, Inc. Transactional email delivery, verification emails, scan-complete notifications, billing alerts, and privacy responses. Recipient name, email, the message body and headers, delivery telemetry (bounces, opens). United States · Frankfurt edge processing EU Standard Contractual Clauses (Module 2 / 3, 2021) plus the EU, US Data Privacy Framework where the vendor is self-certified. Supplementary measures: encryption in transit (TLS 1.3) and at rest (AES-256), access logging, and contractual data-residency commitments where offered. 2026-04-27 View DPA ↗
Stripe Payments Europe, Ltd. Payment processing, subscription billing, invoicing, and tax-document generation. Billing address, name, email, VAT/ABN, card last-4, payment method tokens, transaction history. Ireland (EU) · United States (cross-border for fraud detection) EU Standard Contractual Clauses (Module 2 / 3, 2021) plus the EU, US Data Privacy Framework where the vendor is self-certified. Supplementary measures: encryption in transit (TLS 1.3) and at rest (AES-256), access logging, and contractual data-residency commitments where offered. 2026-04-27 View DPA ↗
Prighter EU Rep GmbH · Prighter Ltd Article 27 GDPR and UK GDPR representative. Receives data-subject requests and correspondence from supervisory authorities on our behalf, and hosts the certificate-of-representation badge shown on our legal pages. Identity and contact details you provide in a data-subject request, and the content of that request. Because the representation badge is loaded from their domain, your IP address and browser metadata are also disclosed to them when you view one of our legal pages. Vienna, Austria (EU) · London, United Kingdom EEA (no transfer) · UK — adequacy 2026-04-30 On request
Clerk, Inc. Purpose Authentication, session management, MFA, and the user profile UI.
Data categories Name, email, password hash, MFA factors, login IP, device fingerprint.
Infrastructure region United States (multi-region) · EU residency on request
Transfer mechanism EU Standard Contractual Clauses (Module 2 / 3, 2021) plus the EU, US Data Privacy Framework where the vendor is self-certified. Supplementary measures: encryption in transit (TLS 1.3) and at rest (AES-256), access logging, and contractual data-residency commitments where offered.
Effective date 2026-04-27
View DPA ↗
Hetzner Online GmbH Purpose Cloud infrastructure, application, API, background workers, PostgreSQL database, and S3-compatible object storage.
Data categories All service data at rest and in transit (account data, scan findings, generated reports), hosted in the EU.
Infrastructure region Helsinki, Finland (EU)
Transfer mechanism Processing within the EEA, no cross-border transfer.
Effective date 2026-07-18
View DPA ↗
Mistral AI SAS Purpose AI text generation for plain-language finding explanations, summaries, remediation suggestions, and translations in scan reports.
Data categories Technical violation data and a short HTML snippet of the flagged element only, no account, contact, or billing data.
Infrastructure region France (EU)
Transfer mechanism Processing within the EEA, no cross-border transfer.
Effective date 2026-07-18
View DPA ↗
Resend, Inc. Purpose Transactional email delivery, verification emails, scan-complete notifications, billing alerts, and privacy responses.
Data categories Recipient name, email, the message body and headers, delivery telemetry (bounces, opens).
Infrastructure region United States · Frankfurt edge processing
Transfer mechanism EU Standard Contractual Clauses (Module 2 / 3, 2021) plus the EU, US Data Privacy Framework where the vendor is self-certified. Supplementary measures: encryption in transit (TLS 1.3) and at rest (AES-256), access logging, and contractual data-residency commitments where offered.
Effective date 2026-04-27
View DPA ↗
Stripe Payments Europe, Ltd. Purpose Payment processing, subscription billing, invoicing, and tax-document generation.
Data categories Billing address, name, email, VAT/ABN, card last-4, payment method tokens, transaction history.
Infrastructure region Ireland (EU) · United States (cross-border for fraud detection)
Transfer mechanism EU Standard Contractual Clauses (Module 2 / 3, 2021) plus the EU, US Data Privacy Framework where the vendor is self-certified. Supplementary measures: encryption in transit (TLS 1.3) and at rest (AES-256), access logging, and contractual data-residency commitments where offered.
Effective date 2026-04-27
View DPA ↗
Prighter EU Rep GmbH · Prighter Ltd Purpose Article 27 GDPR and UK GDPR representative. Receives data-subject requests and correspondence from supervisory authorities on our behalf, and hosts the certificate-of-representation badge shown on our legal pages.
Data categories Identity and contact details you provide in a data-subject request, and the content of that request. Because the representation badge is loaded from their domain, your IP address and browser metadata are also disclosed to them when you view one of our legal pages.
Infrastructure region Vienna, Austria (EU) · London, United Kingdom
Transfer mechanism EEA (no transfer) · UK — adequacy
Effective date 2026-04-30
On request
Effective date is the date the vendor began processing personal data on our behalf. For vendors already engaged when Veracly was first built, we show 27 April 2026, the date of the earliest record in our source history. Prighter EU Rep GmbH and Prighter Ltd were added to this list on 21 August 2026; they have acted as our Article 27 representatives since 30 April 2026 and were omitted from earlier versions of this page in error.
## Former subprocessors
Vendors we have stopped using. We keep this record rather than deleting the row, because a controller needs to establish when a vendor stopped processing their data and when that vendor’s stored copy was destroyed. A decommissioned service that still holds a database is still a subprocessor, so the deletion date is the one that matters.
Vendor Role Traffic ceased Copy deleted
Amazon Web Services, Inc. United States Object storage (report PDFs, evidence) 2026-07-18 Deletion in progress
Anthropic, PBC United States AI inference (report wording) 2026-07-18 Deletion in progress
Railway Corp. United States API and worker hosting 2026-07-18 2026-07-19
Supabase, Inc. United States Managed PostgreSQL (application database) 2026-07-18 2026-07-19
Upstash, Inc. United States Managed Redis (job queue) 2026-07-18 Deletion in progress
Vercel Inc. United States Web hosting and edge network 2026-07-18 2026-07-19
## How we notify you about changes
When we plan to add a new sub-processor we will: (1) update this page, (2) email everyone on the subprocessor-changes mailing list, and (3) wait at least 14 calendar days before the new vendor begins processing your data, so customers have a meaningful window to object. If you object, we will work with you in good faith to find an alternative; if no alternative is feasible, you may terminate the affected service with a pro-rata refund of prepaid fees, as set out in the Data Processing Addendum.
Stay informed
## Get notified when this list changes.
Email privacy@veracly.app and ask to be added to the subprocessor-changes list. We will email you at least 14 days before any new vendor begins processing your data.
Email privacy@veracly.app Read the DPA →

---

## Accessibility statement
URL: https://veracly.app/accessibility

 Veracly
Sign in Start free scan
Accessibility
# Accessibility statement.
Our commitment to make Veracly usable for everyone, including users of assistive technologies, with the conformance, feedback, and enforcement details required by the EAA and the BFSG.
Last updated: 2026-04-29
This document is being finalized by our counsel.
The structure and intent below reflect what each section will cover. Until counsel signs off the final wording, treat this as informational only, not as a legally-binding policy. For specific questions in the interim, write to legal@veracly.app.
This statement applies to veracly.app and the signed-in Veracly platform. It explains which accessibility standards we target, where we currently fall short, how to give us feedback, and how to escalate if we don’t respond.
- 01
## Our commitment
Veracly is committed to making veracly.app and the Veracly platform accessible to everyone, including users with disabilities. Accessibility is a continuous practice, not a one-time audit.
- 02
## Conformance status
We target Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. veracly.app is partially conformant: most content meets the standard, but some recently shipped components are still being reviewed.
- 03
## Applicable standards
EAA (EU 2019/882) Article 13(2) and Annex V · EN 301 549 v3.2.1 §9 (mapping WCAG 2.1 AA) · BFSG (Germany) · UK Equality Act 2010 §20 · ADA Title III via U.S. case law · AODA / IASR (Ontario, WCAG 2.0 AA baseline).
- 04
## Preparation of this statement
This statement was prepared on 2026-04-29 based on a self-assessment plus an automated scan of the site using axe-core. The next review is scheduled within 12 months.
- 05
## Known limitations
We are tracking the following non-conformances and have remediation work underway: text contrast on a small number of legacy marketing components, missing programmatic language attributes on a handful of pages, and heading-order regressions on the blog index. Each item is in our backlog with an owner and a target date.
- 06
## Feedback and contact
If you encounter an accessibility barrier, please tell us so we can fix it. Email accessibility@veracly.app. We aim to acknowledge feedback within two business days and to provide a substantive response within fifteen business days.
- 07
## Enforcement procedure
If you are not satisfied with our response, you can escalate to the supervisory authority for your jurisdiction. EU residents may contact the market surveillance authority designated under the EAA in their member state. UK residents may contact the Equality Advisory and Support Service (EASS). Ontario residents may contact the Ministry for Seniors and Accessibility. U.S. residents may contact the U.S. Department of Justice.
- 08
## Technical information
veracly.app relies on HTML, CSS, JavaScript, ARIA, and SVG. It is built to work with assistive technologies, including current versions of NVDA, JAWS, VoiceOver, and TalkBack, on the latest two major versions of Chrome, Firefox, Safari, and Edge.
- 09
## Compatibility
The site is designed to be compatible with current and recent assistive technologies, modern browsers, and operating systems. If a configuration we do not yet support is blocking you, write to accessibility@veracly.app and we will help.
Questions about this document?
## Talk to our legal contact.
If you’re a customer, prospect, or DPO with a specific question, or you’ve spotted something we should fix, drop a line and we’ll route it to the right team.
legal@veracly.app Open the contact form →

---

## Contact: sales, support and press
URL: https://veracly.app/contact

 Veracly
Sign in Start free scan
Contact
# Real people, real email replies.
We’re an email-first team, no phone trees, no chatbots. Send a note and someone on the team writes back, in plain English, within one business day. Add a phone number below if you’d like a callback.
## Prefer email?
Skip the form and reach the right team directly.
Sales
sales@veracly.app Plans, custom pricing, demos, procurement.
Support
support@veracly.app Existing scans, account issues, billing questions.
We reply to every message within one business day.
## Visit or call
We are an email-first team, but the office details are public for procurement, regulators, and anyone who likes to know who they are talking to.
Office
136 Arthur Allen Drive, Bardia NSW 2565, Australia Australian-registered. Mail and physical post both reach us here.
Phone
+61 2 7813 2060 Sydney business hours, AEST. Email is faster outside those hours.
ABN 56 672 722 486
ACN 672 722 486
Quick answers
## Self-serve first?
These cover most of what people ask before they reach out.
- Frequently asked questions
Compliance, data residency, scope, and the overlay debate.
→
- Pricing & plans
Starter, Growth, Pro, Agency, and what’s in each.
→
- Run a free scan
Compliance report in 5 minutes. No card.
→

---

## EAA Accessibility Checker for Dentists
URL: https://veracly.app/eaa-checker-dentists

 Veracly
Sign in Start free scan
EAA
# EAA accessibility checker for dental practices
A 5-minute audit of your booking site against the European Accessibility Act, EN 301 549, and the WCAG 2.1 AA standard German and Dutch dental regulators are now actively enforcing.
## What this scan covers
- WCAG 2.1 AA scan via axe-core, every success criterion, with screenshots
- EN 301 549 v3.2.1 mapping, the harmonized EU standard
- Country-specific overrides (Germany BFSG, France RGAA 4.1, Italy Legge Stanca)
- Accessibility statement detection, required by EAA Article 7
- Localized PDF report your developer can act on the same day
## Frequently asked
Does the EAA apply to my dental practice?
Yes. The European Accessibility Act has applied to private-sector consumer-facing websites and apps since 28 June 2025 across all EU member states. A booking site that lets patients book appointments is squarely in scope.
What is the penalty if I do nothing?
In Germany the daily fine threshold under §3 BFSG is €100,000. In France, missing an accessibility statement alone is a €25,000 annual penalty. Most dental practices receive a complaint-driven warning first; the second incident usually triggers the fine.
Will Veracly fix my site automatically?
No, and any tool that promises this is being investigated by the FTC. Veracly identifies every violation, ranks it by severity, and gives your developer the exact fix to apply.
## See your first report
in five minutes.
Free scan, now including the EU AI Act (Art. 50) transparency check. No card. No overlay.

---

## EAA Accessibility Checker for Law Firms
URL: https://veracly.app/eaa-checker-lawyers

 Veracly
Sign in Start free scan
EAA
# EAA accessibility checker for law firms
Boutique law firms and solo practitioners are squarely in EAA scope from June 2025. Audit your client portal, contact forms, and document uploader against WCAG 2.1 AA before a complaint becomes a fine.
## What this scan covers
- WCAG 2.1 AA scan via axe-core, every success criterion, with screenshots
- EN 301 549 v3.2.1 mapping, the harmonized EU standard
- Country-specific overrides (Germany BFSG, France RGAA 4.1, Italy Legge Stanca)
- Accessibility statement detection, required by EAA Article 7
- Localized PDF report your developer can act on the same day
## Frequently asked
Are law firms exempt from the EAA?
No. The EAA applies to private-sector consumer-facing websites; law firms whose clients are individual consumers are in scope. Firms exclusively serving B2B clients have a narrower exposure but the underlying GDPR + ePrivacy rules still apply.
What about client confidentiality?
Veracly only scans publicly accessible pages by default. Authenticated client-portal pages are scanned only when you supply a test login; we never store or transmit document contents.
Will the report stand up in regulator review?
Yes, every finding cites the underlying axe-core rule, the WCAG success criterion, and the country-specific transposition (BFSG §3 in DE, RGAA 4.1 in FR, Tijdelijk besluit in NL).
## See your first report
in five minutes.
Free scan, now including the EU AI Act (Art. 50) transparency check. No card. No overlay.

---

## EAA Accessibility Checker for E-commerce
URL: https://veracly.app/eaa-checker-ecommerce

 Veracly
Sign in Start free scan
EAA
# EAA accessibility checker for e-commerce
Your checkout, cart, and product pages must meet WCAG 2.1 AA under the EAA. Veracly audits every step of the buyer journey and flags the violations regulators are now actively complaining about.
## What this scan covers
- WCAG 2.1 AA scan via axe-core, every success criterion, with screenshots
- EN 301 549 v3.2.1 mapping, the harmonized EU standard
- Country-specific overrides (Germany BFSG, France RGAA 4.1, Italy Legge Stanca)
- Accessibility statement detection, required by EAA Article 7
- Localized PDF report your developer can act on the same day
## Frequently asked
Does the EAA apply to my online store?
Yes. E-commerce is explicitly listed in EAA Annex I as in scope. The June 2025 effective date applied immediately to existing stores; the 2030 grace period only covers self-service terminals (kiosks), not websites.
Will Veracly scan my Shopify / WooCommerce / Shopware store?
Yes. We test the rendered DOM, so any platform works, Shopify, WooCommerce, Shopware, Magento, Prestashop, BigCommerce, Centra, Lightspeed.
Are there cookie/tracking-pixel rules I need to worry about?
Yes, Veracly bundles GDPR + ePrivacy scanning into the same report. Pre-consent Meta Pixel firing is the most common violation we see on EU stores.
## See your first report
in five minutes.
Free scan, now including the EU AI Act (Art. 50) transparency check. No card. No overlay.

---

## EAA Accessibility Checker for SaaS
URL: https://veracly.app/eaa-checker-saas

 Veracly
Sign in Start free scan
EAA
# EAA accessibility checker for SaaS companies
B2B SaaS reaching consumer-facing surfaces (sign-up, marketing, embedded widgets) is in EAA scope. Veracly audits both your marketing site and authenticated dashboards on a single timeline.
## What this scan covers
- WCAG 2.1 AA scan via axe-core, every success criterion, with screenshots
- EN 301 549 v3.2.1 mapping, the harmonized EU standard
- Country-specific overrides (Germany BFSG, France RGAA 4.1, Italy Legge Stanca)
- Accessibility statement detection, required by EAA Article 7
- Localized PDF report your developer can act on the same day
## Frequently asked
Is my B2B SaaS in EAA scope?
Your marketing site is, it is consumer-facing. Your authenticated product is in scope only if you sell to individual consumers (B2C SaaS). Most B2B SaaS still face WCAG 2.1 AA pressure from enterprise customers in their procurement reviews.
How do you handle authenticated app pages?
You provide a test login. We run a separate scan run with that session and produce a second PDF for the authenticated surface, same format, same i18n, same severity scoring.
What about my embedded widget?
Pro and Agency tiers can scan an embedded widget on a customer site. We render the host page, instantiate the widget, and audit the resulting DOM, including focus order across the widget boundary.
## See your first report
in five minutes.
Free scan, now including the EU AI Act (Art. 50) transparency check. No card. No overlay.

---

## Free EU AI Act Checker (Article 50), Chatbot & AI Disclosure Scan
URL: https://veracly.app/eu-ai-act-checker

 Veracly
Sign in Start free scan
AI ACT
# EU AI Act checker, Article 50 transparency readiness
A free scan of your website for transparency signals relevant to the EU AI Act’s Article 50, undisclosed chatbots and missing AI-use notices, now that Article 50 has applied EU-wide since 2 August 2026. It’s a transparency check, not a determination that your site is “AI Act compliant”.
## What this scan covers
- Chatbot disclosure check (Art. 50(1)), detects Intercom, Crisp, Tidio, Drift, Zendesk and 12+ other widgets, and whether visitors are told they are talking to an AI
- AI-use notice check, looks for an AI / automated-decision clause in your privacy policy
- Readiness score with copy-paste fixes, a disclosure banner and a policy clause your developer can ship the same day
- Bundled into every Veracly scan, no separate tool, no account needed for the free scan
- Honest by design, we report “detected / not detected” and “readiness”, never “AI Act compliant”
## Frequently asked
Does the EU AI Act apply to my website?
Article 50 transparency obligations have applied EU-wide since 2 August 2026 to anyone whose site uses AI that interacts with people in the EU, chatbots, AI-generated content, synthetic media. There is no general SME exemption, but for most SMBs the duty is light: a clear chatbot notice and an AI-use clause.
What does the free AI Act scan check?
It detects conversational-AI / chatbot widgets and whether an AI disclosure is present, and looks for an AI-use clause in your privacy policy. You get a readiness score and copy-paste fixes. It does not cover high-risk AI governance (risk classification, conformity assessments), that is outside Article 50.
Does this make my site "AI Act compliant"?
No. This is a transparency check related to Article 50, not legal advice and not a compliance certification. Detection is best-effort from a public scan; disclosures shown only at runtime may not be observable. Have your counsel confirm.
## See your first report
in five minutes.
Free scan, now including the EU AI Act (Art. 50) transparency check. No card. No overlay.

---

## Cookie consent in Australia: what the law actually requires
URL: https://veracly.app/blog/australia-cookie-consent-law
Published: 2026-08-20

Cookies
# Cookie consent in Australia: what the law actually requires
Australian businesses install consent banners because European advice tells them to. There is no Australian rule requiring one for ordinary analytics. But sensitive information is a real exception, and the Privacy Commissioner enforced it against tracking pixels in June 2026.
By Veracly Compliance Team · 2026-08-20· 6 min read
General information, current at the date above. This describes what the cited sources say; it is not legal advice and no lawyer has reviewed it. Australian privacy and discrimination law turns heavily on your specific circumstances — what you collect, from whom, and which carve-outs apply — so treat this as orientation and verify your own position before acting on it.
If you run an Australian website and you have been told you need a cookie consent banner, you were probably told by something written for Europe. Australia has no prior-consent rule for cookies. There is no Australian Article 5(3), no Australian “reject all” parity requirement, and no Australian regulator issuing penalties simply because an analytics cookie fired before a click. There is a significant exception for sensitive information, which we come to below.
This is the single biggest structural difference between Australian and European web compliance, and getting it wrong costs money in both directions: businesses buy consent platforms they do not need, and then fail the obligation they actually have.
## Where the EU rule comes from, and why it has no Australian twin
Every cookie banner in Europe traces to Article 5(3) of the ePrivacy Directive (2002/58/EC). It says that storing information on, or gaining access to information already stored in, a user’s terminal equipment requires that user’s consent, unless it is strictly necessary to provide a service they requested.
The important thing about that provision is what it regulates: it regulates the act of writing to the device . It applies whether or not the cookie contains personal data. That is why a European banner has to appear before anything non-essential is written, and why analytics cookies need opt-in even when the operator argues they are anonymous, though some regulators exempt narrowly scoped first-party audience measurement.
Australia never enacted an equivalent. The Privacy Act regulates the handling of personal information , not access to terminal equipment. If a cookie does not collect personal information, the Privacy Act has nothing to say about it. If it does, the Act attaches transparency duties for ordinary non-sensitive data — not a general consent gate. Sensitive information is the exception, and it is a big one; see below.
## What Australian law does require
Assume you are an APP entity — that is, your annual turnover exceeded AUD 3,000,000 last financial year or in any year since you started trading, or one of the section 6D carve-outs applies to you. Two Australian Privacy Principles are then relevant to tracking:
- APP 5 — notification of collection. At or before the time you collect personal information — or, if that is not practicable, as soon as practicable afterwards — you must take reasonable steps to notify the individual of a list of matters, including who you are, why you are collecting, who you usually disclose to, and whether you disclose overseas.
- APP 1 — open and transparent management. You must have a clearly expressed and up-to-date privacy policy, available free of charge, describing what you collect and hold, how, for what purposes, how someone can access and correct it, how they complain, and whether you disclose overseas.
For ordinary non-sensitive analytics, that is a documentation obligation rather than a consent obligation. The overseas disclosure point is the one Australian sites most often get wrong. Google Analytics, Meta Pixel and most advertising and session-replay tools involve disclosure to recipients outside Australia. APP 1 and APP 5 both expect that to be stated. A policy that says nothing about overseas recipients while the site runs a US-hosted analytics stack is inaccurate, and inaccuracy is the failure mode that actually attracts regulator attention.
## Where Australian law does require consent
Australia has no general prior-consent rule for cookies, but it does have consent obligations that bite on tracking in specific circumstances, and they have been enforced recently enough that no honest post can leave them out.
APP 3.3 requires express consent before collecting sensitive information — health, sexuality, race, religion, political opinions, trade-union membership. APP 7 requires consent to use or disclose sensitive information for direct marketing. On 11 June 2026 the Privacy Commissioner applied both to tracking pixels: in Medmate Australia Pty Ltd [2026] AICmr 41 and Monash IVF Pty Ltd [2026] AICmr 40, pixels on health-related websites were held to collect sensitive information about visitors, in breach of APP 3.3, 5.1 and 7.1. The Commissioner rejected Medmate’s generic cookie pop-up as consent: consent had to be express, informed and specific to the pixel and the platforms involved.
The OAIC’s November 2024 tracking-pixel guidance goes further, warning that collecting personal information covertly is likely to be an unfair means of collection under APP 3.5, and adtech is on the Commissioner’s stated enforcement priorities.
So the accurate statement is narrower than “no consent required in Australia”. It is: writing to the device does not require consent, and for ordinary non-sensitive analytics the duties are transparency duties. But if your site is about health, or your tracking otherwise reveals sensitive information, or you are disclosing to advertising platforms for matching and retargeting, consent obligations do apply — and a generic banner will not discharge them.
## When EU and UK rules reach an Australian site anyway
The GDPR applies extraterritorially where you offer goods or services to individuals in the EU, or monitor their behaviour there. The ePrivacy consent rule travels with it in practice. So an Australian business that sells to European customers, or runs European ad campaigns, is doing EU-facing processing and the banner requirement is real — for those visitors.
What that does not mean is that every Australian site should adopt EU defaults just in case. Ask a concrete question instead: do you have EU or UK visitors you are actually trying to reach? If the honest answer is no, an EU-style consent flow is imposing friction on your Australian customers for no legal benefit.
## How we grade this, and why
Veracly’s Australian rule set deliberately does not treat pre-consent cookies or trackers as Australian violations. The finding types exist in our engine — they are exactly what we grade an EU site on — but they are not mapped into the Australian pack, because flagging them under Australian law would be an overclaim.
If your site is scored against multiple markets, a tracker firing before consent appears under the EU or UK scorecard and not under the Australian one. The same scan, the same evidence, graded against the law that actually applies in each place.
We would rather tell you that a finding does not apply to you than inflate a score report. A compliance tool that reports EU violations against Australian law is selling anxiety, and it is trivially falsifiable by anyone who reads the statute.
## How to work out your own position
None of the below is a recommendation about your site. It is the order in which the questions are usually worth asking.
- Work out whether the Privacy Act binds you at all. At or under the AUD 3,000,000 turnover threshold, never above it since you started trading, and outside the carve-outs — it does not.
- Ask whether any of your tracking touches sensitive information. If your site is about health or any other sensitive category, APP 3.3 requires express, specific consent and a generic banner will not do it.
- Inventory what your site actually loads. Open DevTools, go to the Network tab, reload, and look at the third-party hosts. Most operators are surprised.
- Make the privacy policy match that inventory, including overseas disclosure.
- If you have EU or UK visitors, implement consent properly for them — genuine prior consent with an equally prominent reject path, not a cosmetic notice bar.
- Weigh accessibility alongside it. Australian website liability has an actual litigation history there, and the duty has no turnover threshold.
That last point is worth dwelling on. Australia has a leading case in which an inaccessible website was held to be unlawful discrimination — Maguire v Sydney Organising Committee for the Olympic Games (No 2) [2000] HREOCA 31, a determination of the Commission rather than a court judgment. If you are allocating a fixed compliance budget, the Disability Discrimination Act is where the accessibility risk sits — and, since June 2026, sensitive-data tracking is where the privacy risk sits.
## Common questions
Is a cookie banner legally required in Australia? +
Not as a general rule. Australia has no equivalent of Article 5(3) of the EU ePrivacy Directive, which is the provision that requires consent before storing or reading information on a user’s device. Without it there is no general Australian requirement to obtain consent before setting a cookie, and no requirement that rejecting be as easy as accepting. There is an important exception: APP 3.3 requires express consent to collect sensitive information, and in June 2026 the Privacy Commissioner applied that to tracking pixels on health-related websites in Medmate Australia Pty Ltd [2026] AICmr 41 and Monash IVF Pty Ltd [2026] AICmr 40, holding that a generic cookie pop-up was not valid consent.
So why do so many Australian sites have one? +
Three reasons, only one of which is a legal requirement. First, many Australian sites genuinely serve EU or UK visitors, and those visitors bring their own law with them. Second, consent management platforms are sold globally with EU defaults, so the banner arrives with the tool. Third, a great deal of Australian compliance content is European content with the place names changed. If you have no EU or UK visitors, the banner is very likely doing nothing for you legally.
What does the Privacy Act actually require for tracking? +
If a cookie or pixel collects personal information and you are an APP entity, Australian Privacy Principle 5 requires you to notify the individual at or before the time of collection — or as soon as practicable afterwards if that is not practicable — and APP 1 requires a clearly expressed, up-to-date privacy policy describing what you collect, why, and to whom you disclose it, including overseas recipients, which covers most analytics and advertising vendors. For ordinary non-sensitive data those are documentation obligations. If the tracking collects sensitive information, APP 3.3 adds an express consent requirement on top.
Is an IP address personal information in Australia? +
Less settled than in the EU. In Privacy Commissioner v Telstra Corporation Limited [2017] FCAFC 4 the Full Federal Court considered whether certain network metadata was information "about an individual" — though it was construing the pre-2014 definition. Australian courts have not simply adopted the European position that an IP address is personal data in most circumstances, but the OAIC’s 2026 tracking-pixel determinations treated IP addresses, device data and full URLs as personal information where a visitor could be singled out. The practical answer is unchanged: if your stack can single out an individual, treat the data as personal information and describe it in your privacy policy.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Cookies
### What is a cookie banner audit? (2026 checklist)
A cookie banner audit checks design, defaults, dark patterns, and what loads before any consent gesture. The Accept and Reject paths themselves have to be walked by hand. Here is the 2026 checklist.
- Cookies
### GDPR vs ePrivacy: which one actually governs cookies?
GDPR did not invent the cookie banner. ePrivacy did, nine years earlier. Understanding which framework requires what is the difference between a defensible CMP setup and a banner that fails on first inspection.
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.

---

## The Privacy Act small business exemption — and the date everyone gets wrong
URL: https://veracly.app/blog/privacy-act-small-business-exemption
Published: 2026-08-20

Multi-jurisdiction
# The Privacy Act small business exemption — and the date everyone gets wrong
A widely repeated claim says the small business exemption dies on 10 December 2026. That date is real, but it belongs to another provision. Here is what section 6D actually does, who it does not protect, and why we know the mistake well.
By Veracly Compliance Team · 2026-08-20· 6 min read
General information, current at the date above. This describes what the cited sources say; it is not legal advice and no lawyer has reviewed it. Australian privacy and discrimination law turns heavily on your specific circumstances — what you collect, from whom, and which carve-outs apply — so treat this as orientation and verify your own position before acting on it.
Australia does something no European privacy regime does: it exempts most small businesses from its privacy law entirely. Not a lighter-touch tier, not reduced record-keeping — out of scope. If you run an Australian SMB, this is probably the single most consequential fact about your privacy obligations, and it is routinely misreported.
## What section 6D actually says
The Australian Privacy Principles bind APP entities . Section 6D of the Privacy Act 1988 (Cth) removes a “small business operator” from that definition. The headline test is annual turnover for the previous financial year:AUD 3,000,000 or less and you are outside the Act.
The test only runs one way, and this is the part almost every summary drops. Under section 6D(4)(a) a business is not a small business operator if it has had an annual turnover above AUD 3,000,000 in any financial year since it started trading. A business that turned over four million two years ago and two million last year is not exempt. You cannot drop back under the threshold in a lean year and become exempt again.
The statutory wording in section 6D(1) is “$3,000,000 or less”, so the boundary is inclusive — a business at exactly three million is still exempt. An exempt operator owes no APP duties. No privacy policy obligation under APP 1, no collection notice under APP 5, no access-and-correction machinery.
Compare the GDPR, which has no turnover threshold at all. Articles 13 and 14 bind a sole trader in the same terms as a bank. Australian and European privacy law start from genuinely different premises, which is why advice written for one travels badly to the other.
## The 10 December 2026 confusion
You will find a lot of material asserting that the exemption disappears on 10 December 2026. The date is real. The claim attached to it is not.
10 December 2026 is the commencement of new Australian Privacy Principles 1.7 to 1.9, introduced by the Privacy and Other Legislation Amendment Act 2024. Those provisions require an APP entity’s privacy policy to disclose where automated decision-making is used in ways that significantly affect an individual. The delayed start is 24 months from Royal Assent, which is where the date comes from.
The 2024 Act did not repeal the small business exemption. That reform was deferred to a further tranche. As at 20 August 2026, no Bill implementing it has been introduced and no commencement date exists.
The date carries one other thing, which adds to the confusion: 10 December 2026 is also the deadline by which the OAIC must register the Children’s Online Privacy Code.
Two things follow. Section 6D stands until a repeal is actually enacted. And both of those obligations bind APP entities — so an exempt small business is not brought into scope by either.
## We made this mistake, which is how we know it well
Our own Australian rule set once carried a gate that switched itself off on 10 December 2026, on exactly the mistaken belief described above. It would have failed in a particularly unpleasant way: on that date the exemption would have stopped being applied, and every exempt Australian customer would have been told they were in breach of a duty they do not have — with no test failing to signal it.
We removed the date. The exemption now stands with no expiry, and a scheduled review forces a human to check the legislative position rather than letting code guess at it. A gate that expires silently on an assumption is worse than one that asks.
We mention this because the error is easy to make and hard to notice, and because a compliance vendor that quietly corrects its own mistakes is not being much use to anyone.
## Where the exemption stops
Turnover is necessary but not sufficient. The main ways a small business is pulled into the Act anyway — this list is not exhaustive — are:
- you provide a health service and hold health information (s 6D(4)(b)) — this catches a great many small clinics and allied-health practices;
- you disclose personal information about another individual for a benefit, service or advantage, or provide a benefit, service or advantage in order to collect it from someone else (ss 6D(4)(c)–(d)) — broadly, trading in personal information. Note the statutory exception: a disclosure made with the individual’s consent, or required or authorised by law, does not knock you out of the exemption (ss 6D(7)–(8));
- you are a contracted service provider for a Commonwealth contract (s 6D(4)(e));
- you are a credit reporting body (s 6D(4)(f));
- you are a reporting entity under the Anti-Money Laundering and Counter-Terrorism Financing Act 2006 (s 6E(1A)) — since the AML/CTF reforms commencing 1 July 2026 this catches many real-estate agents, accountants, conveyancers and lawyers, for the personal information they handle in connection with those obligations;
- you hold a Consumer Data Right accreditation, are a registered employee association, or are otherwise prescribed by regulation (s 6E);
- you are related to a body corporate that carries on a business that is not a small business (s 6D(9)); or
- you have opted in to coverage under section 6EA.
The health services limb deserves particular attention, because Veracly’s own customer base includes clinics. A dental or physiotherapy practice turning over well under three million is still an APP entity if it holds health records. For that business the privacy policy obligation is real.
## Other law does not go away
The exemption is specific to the Privacy Act. It does not touch:
- The Disability Discrimination Act. Section 24 has no turnover threshold. Accessibility obligations apply to a one-person business.
- The Spam Act 2003. Consent rules for commercial electronic messages apply regardless of size.
- Australian Consumer Law. Misleading statements about how you handle data are still misleading conduct — including a privacy policy that describes practices you do not follow.
- Foreign law. The GDPR and UK GDPR apply on their own terms if you target or monitor individuals there. No Australian threshold affects that.
That last one is the common trap. An exempt Australian business selling to European customers has full GDPR obligations for those customers, including a privacy notice and a lawful basis, while owing nothing under the Privacy Act domestically.
## How we handle it in a scan
A missing privacy policy is graded differently depending on which market a site is scored against. Under EU and UK rules it is a serious finding, because those regimes have no equivalent exemption. Under the Australian rule set we suppress it for businesses at or below the section 6D threshold, because reporting a breach of a duty that does not bind you is simply an incorrect finding.
That means we need to know your turnover band to grade the Australian privacy rule honestly. It is the only question of its kind we ask, and this is why.
## Common questions
What is the small business exemption? +
Section 6D of the Privacy Act 1988 (Cth) excludes a "small business operator" from the definition of an APP entity. The core test is annual turnover for the previous financial year: section 6D(1) says "$3,000,000 or less", so a business at exactly AUD 3,000,000 is still within the exemption. But the test runs one way only — under s 6D(4)(a), a business that has exceeded the threshold in any financial year since it started trading is not a small business operator, and cannot regain the exemption by having a lean year.
Was the exemption repealed on 10 December 2026? +
No. That claim conflates two different parts of the Privacy and Other Legislation Amendment Act 2024. 10 December 2026 is the commencement date for new Australian Privacy Principles 1.7 to 1.9, which require privacy policies to explain automated decision-making — a 24-month delayed start from Royal Assent. The repeal of the small business exemption was not part of that Act; it was deferred to a further tranche of reform, and as at 20 August 2026 no Bill implementing it has been introduced.
Which small businesses are covered anyway? +
Turnover is not the only test, and the carve-outs are broader than most summaries suggest. A small business operator is still an APP entity if it provides a health service and holds health information, trades in personal information, is a contracted service provider under a Commonwealth contract, is a credit reporting body, is a reporting entity under the AML/CTF Act 2006 — which since the reforms commencing 1 July 2026 catches many real-estate agents, accountants, conveyancers and lawyers — holds a Consumer Data Right accreditation, or is related to a body corporate that is not a small business. Businesses can also opt in under section 6EA. This list is not exhaustive, and if any limb applies the AUD 3,000,000 threshold does not help you.
If I am exempt, do I still need a privacy policy? +
Not as a matter of Australian law. Australian Privacy Principle 1.3 is what requires a privacy policy, and it binds APP entities — which an exempt small business is not. There are still good reasons to publish one: it is expected by customers and partners, some platforms require it, and it is mandatory if you have EU or UK visitors, since the GDPR has no turnover threshold. But it is a commercial or foreign-law reason, not an Australian legal duty.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- Multi-jurisdiction
### Multi-jurisdiction website compliance: one site, many laws
EU, UK, US, and Canadian visitors trigger different laws. Here is the practical playbook for satisfying GDPR, EAA, ADA, UK Equality Act, and AODA with one programme.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## Website compliance in Australia: the DDA, the Privacy Act and WCAG
URL: https://veracly.app/blog/website-compliance-australia
Published: 2026-08-20

Multi-jurisdiction
# Website compliance in Australia: the DDA, the Privacy Act and WCAG
Australian web compliance is not a translated version of the GDPR. There is no statute naming WCAG, no prior-consent rule for cookies, and a small-business exemption that excuses most SMBs from the privacy-policy duty entirely. Here is what actually applies.
By Veracly Compliance Team · 2026-08-20· 8 min read
General information, current at the date above. This describes what the cited sources say; it is not legal advice and no lawyer has reviewed it. Australian privacy and discrimination law turns heavily on your specific circumstances — what you collect, from whom, and which carve-outs apply — so treat this as orientation and verify your own position before acting on it.
Most compliance advice an Australian business finds online is European advice with the place names changed. That is a problem, because Australian web law differs from the EU model in three structural ways: there is no statute that names WCAG for private websites, there is no prior-consent rule for cookies, and a turnover-based exemption removes most small businesses from the privacy regime altogether.
None of that means an Australian website has no obligations. It means the obligations have a different shape, and copying a GDPR checklist will leave you doing work you do not need to do while missing the thing that actually creates liability.
## The two Commonwealth frameworks that apply
- Accessibility — Disability Discrimination Act 1992 (Cth). Section 24 makes it unlawful to discriminate against a person on the ground of disability in the provision of goods, services and facilities. A website is a service. The duty is not absolute: section 21B excuses discrimination where avoiding it would impose an unjustifiable hardship, assessed under section 11. SOCOG ran that defence in Maguire and lost. Enforcement is complaint-driven through the Australian Human Rights Commission.
- Privacy — Privacy Act 1988 (Cth). The Australian Privacy Principles govern how APP entities handle personal information. Regulated by the Office of the Australian Information Commissioner, which has real investigation and enforcement powers — but only over entities the Act actually binds.
Note what is missing from that list: there is no Australian ePrivacy Directive, and no Australian equivalent of the European Accessibility Act with a compliance deadline attached to it.
State and territory law sits alongside both. Every state and territory has its own anti-discrimination statute with a goods-and-services limb, and New South Wales, Victoria and the ACT have health-records legislation that binds small health providers regardless of the Commonwealth turnover exemption. The AHRC Guidelines say as much at page 14: they should be read together with the whole of the DDA and state and territory anti-discrimination laws.
## Accessibility: the duty is the DDA, not WCAG
This distinction matters more than it sounds. The obligation you can be taken to court over is section 24 of the DDA — unlawful discrimination. WCAG is not the law; it is the yardstick the regulator points at when explaining what the law expects.
That yardstick was updated recently, and a lot of Australian guidance is still citing the old one. In April 2025 the Australian Human Rights Commission published Guidelines on equal access to digital goods and services , which expressly updates the World Wide Web Access: Disability Discrimination Act Advisory Note ver 4.1 from 2014. The new Guidelines name WCAG 2.2 Level AA as the minimum. If a checklist you are following still says WCAG 2.0 or cites the 2014 Advisory Note, it predates the current guidance.
The Guidelines are issued under section 67(1)(k) of the DDA and section 11(1)(n) of the Australian Human Rights Commission Act 1986, and they are candid about their own status. Page 14 states that an organisation “may not be protected from a finding of unlawful discrimination” by having relied on them. Conformance is evidence of good faith, not a safe harbour.
The decision that anchors all of this is Maguire v Sydney Organising Committee for the Olympic Games (No 2) [2000] HREOCA 31, in which the Sydney Olympics website was found to have unlawfully discriminated against a blind user. It is a determination of the Commission (then HREOC) rather than a court judgment, so it is not binding precedent in the way it is often described — but it is the case everyone cites, and the AHRC relies on it in the 2025 Guidelines.
## Cookies: Australia is not the EU
There is no Australian rule requiring consent before a cookie is set. Article 5(3) of the EU ePrivacy Directive — the provision that produces every cookie banner you have ever clicked — has no Australian counterpart. Neither does the “reject must be as easy as accept” parity requirement that EU regulators have built on top of it.
What does apply is the Privacy Act, and only when a cookie collects personal information . Then Australian Privacy Principle 5 requires notification at or before collection — or, if that is not practicable, as soon as practicable afterwards — and APP 1 requires a privacy policy describing what you collect and why. For ordinary, non-sensitive analytics those are transparency duties rather than consent duties.
There is an important exception, and it has teeth. APP 3.3 requires express consent before collecting sensitive information — health, sexuality, race, religion, political or trade-union affiliation. In June 2026 the Privacy Commissioner applied that to tracking pixels in Medmate Australia Pty Ltd [2026] AICmr 41 and Monash IVF Pty Ltd [2026] AICmr 40, finding that pixels on health-related websites collected sensitive information about visitors, and rejecting a generic cookie pop-up as consent: consent had to be express, informed and specific to the pixel. The OAIC’s November 2024 tracking-pixel guidance also warns that collecting personal information covertly is likely to be an unfair means of collection under APP 3.5.
Whether an online identifier is “personal information” is also more contested in Australia than in the EU. In Privacy Commissioner v Telstra Corporation Limited [2017] FCAFC 4 the Full Federal Court considered whether certain network metadata was information about an individual . Australian courts have not simply adopted the EU position that an IP address is personal data in most circumstances — though note the Full Court was construing the pre-2014 definition, and the OAIC’s 2026 tracking-pixel determinations treated IP addresses, device data and full URLs as personal information where a visitor could be singled out. The practical answer is unchanged: if your stack can single out an individual, treat the data as personal information and describe it in your policy.
The practical consequence for an Australian SMB: for ordinary analytics you probably do not need an EU-style consent banner for Australian visitors — unless your tracking touches sensitive information, in which case APP 3.3 requires express consent and a generic banner will not supply it. You very likely do need an accurate privacy policy, and you need it to actually describe the tracking you run. And if you serve EU or UK customers, EU and UK rules apply to those visitors no matter where your business sits.
## Privacy: the small business exemption
Section 6D of the Privacy Act excludes a small business operator from the definition of an APP entity. The headline test is annual turnover for the previous financial year: section 6D(1) says AUD 3,000,000 or less , so the boundary is inclusive and a business at exactly three million is still exempt.
The test only runs one way, though, and this is the part most summaries drop. Under section 6D(4)(a) a business is not a small business operator if it has had an annual turnover above AUD 3,000,000 in any financial year since it started trading. You cannot fall back under the threshold in a lean year and become exempt again.
An exempt business owes no APP obligations — including no obligation to publish a privacy policy at all. This is genuinely different from the EU, where the GDPR has no turnover threshold and Articles 13 and 14 bind a sole trader the same as a multinational.
The carve-outs matter, though. You are an APP entity regardless of turnover if you are a health service provider holding health records, if you disclose personal information about someone for a benefit or service, if you provide a service under a Commonwealth contract, or if you are a credit reporting body. A business can also opt in to APP coverage.
One correction worth making, because it circulates widely: the Privacy and Other Legislation Amendment Act 2024 did not repeal the small business exemption. Repeal was deferred to a further tranche of reform. We have written a separate post on that date , because the confusion has a specific and traceable source.
## What we check, and what we do not
Veracly grades an Australian site against the DDA accessibility duty and the APP 1 privacy-policy duty. Being precise about the limits is part of the point:
- Accessibility. We run axe-core against the rendered page, plus our own checks for criteria axe does not cover. The AHRC Guidelines name WCAG 2.2 AA, and no automated tool reaches all of it. Of the six A and AA success criteria WCAG 2.2 adds, we automate one — 2.5.8 Target Size (Minimum). The other five we do not test: 2.4.11 Focus Not Obscured (Minimum, AA), 2.5.7 Dragging Movements (AA), 3.3.8 Accessible Authentication (Minimum, AA), 3.2.6 Consistent Help (A) and 3.3.7 Redundant Entry (A). Some turn on interaction states or sit behind authentication; others are simply hard to detect reliably. Every Australian report we issue names them on its face.
- Privacy policy. We check that one exists and is reachable. Under the AU rule set we suppress that finding for businesses at or below the section 6D threshold, because asserting a statutory breach against a business that owes no duty would be wrong. If you have not told us your turnover we still score it, but we attach a note saying the duty may not apply — claiming a breach we cannot establish is the failure we are avoiding in both directions.
- Cookies. We do not report pre-consent cookies or trackers as Australian violations, because under Australian law a pre-consent cookie is not, by itself, a violation. If your site is also scored against EU or UK rules, they appear there.
Automated scanning also cannot tell you whether your privacy policy is accurate . It can tell you the policy exists and that a tracker is present; whether the policy honestly describes that tracker is a human judgement.
## A practical order of work
- Establish whether you are an APP entity. Turnover over AUD 3,000,000 last financial year, or any carve-out applies? Then the Privacy Act binds you.
- If it does, publish an APP 1 compliant privacy policy: clearly expressed, current, free, and describing what you collect, why, who you disclose it to including overseas recipients, and how someone accesses, corrects or complains.
- Fix accessibility against WCAG 2.2 AA. Start with the machine-detectable failures — missing alternative text, unlabelled form fields, insufficient contrast, heading order — because they are the cheapest and the most commonly cited.
- Have a human review the five criteria automation cannot reach, and check that your privacy policy matches the tracking you actually run.
- If you serve EU or UK visitors, treat those obligations separately. That is where consent banners and their parity rules become real.
The Australian position is, on the whole, less onerous than the European one. It is also less well documented, which is why so much local advice is imported and wrong. The DDA duty is the one with a litigation history behind it, and it is the one worth spending your budget on.
## Common questions
Is WCAG legally required in Australia? +
Not by statute, for the private sector. No Australian law names WCAG as a requirement for private websites. The legal duty is section 24 of the Disability Discrimination Act 1992 (Cth), which makes it unlawful to discriminate in the provision of goods, services and facilities. WCAG enters through guidance: the Australian Human Rights Commission publishes Guidelines on equal access to digital goods and services (April 2025) under section 67(1)(k) of the DDA, and those Guidelines name WCAG 2.2 Level AA as the minimum at page 43. The Guidelines are explicitly not legally binding — page 14 says an organisation "may not be protected from a finding of unlawful discrimination" by having relied on them. In practice WCAG 2.2 AA is the benchmark a complaint will be measured against, without being a statutory standard.
Does Australian law require a cookie banner? +
No — not in the way EU law does. Australia has no equivalent of Article 5(3) of the ePrivacy Directive, so there is no general rule that you must obtain consent before storing or reading a cookie. What does apply is the Privacy Act 1988 if the cookie collects personal information: for ordinary non-sensitive analytics those are transparency duties under Australian Privacy Principles 1 and 5, not a consent gate. The exception matters, though: APP 3.3 requires express consent to collect sensitive information, and in June 2026 the Privacy Commissioner applied that to tracking pixels on health-related sites in Medmate Australia Pty Ltd [2026] AICmr 41 and Monash IVF Pty Ltd [2026] AICmr 40, rejecting a generic cookie pop-up as consent. If your site also serves EU or UK visitors, their rules apply to those visitors regardless of where you are based.
Does the Privacy Act apply to my small business? +
Often not. Section 6D of the Privacy Act 1988 excludes a "small business operator" from the definition of an APP entity. Section 6D(1) sets the threshold at annual turnover of AUD 3,000,000 or less for the previous financial year. Two qualifications matter. First, the test runs one way only: under s 6D(4)(a), a business that has exceeded the threshold in any financial year since it started trading is not a small business operator, and cannot become exempt again in a lean year. Second, the carve-outs are broad and not exhaustive — health service providers holding health records, businesses trading in personal information, Commonwealth contracted service providers, credit reporting bodies, and reporting entities under the AML/CTF Act 2006, which since the reforms commencing 1 July 2026 catches many real-estate agents, accountants, conveyancers and lawyers. A business can also opt in under s 6EA. As at 20 August 2026 the exemption has not been repealed.
Who enforces these rules in Australia? +
Two different bodies, through two different routes. Accessibility runs through the Australian Human Rights Commission: an individual lodges a complaint, the Commission attempts conciliation, and an unresolved complaint can proceed to the Federal Court or the Federal Circuit and Family Court. There is no regulator that audits websites and issues accessibility fines. Privacy runs through the Office of the Australian Information Commissioner, which does have investigation and enforcement powers over APP entities.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- Multi-jurisdiction
### Multi-jurisdiction website compliance: one site, many laws
EU, UK, US, and Canadian visitors trigger different laws. Here is the practical playbook for satisfying GDPR, EAA, ADA, UK Equality Act, and AODA with one programme.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## Which rules apply to your website, and what an automated scan can actually check
URL: https://veracly.app/blog/coverage-by-country
Published: 2026-08-15

Multi-jurisdiction
# Which rules apply to your website, and what an automated scan can actually check
A country-by-country map of what Veracly monitors, what the automated scan detects, and the requirements that still need manual verification. Including the parts we cannot check.
By Veracly Compliance Team · 2026-08-15· 7 min read
Two questions come up before anyone reads a compliance report: which rules actually apply to me , and how much of this can a scanner really tell me?
This page answers both, honestly, including the parts where the answer is that we cannot help. Pick a market below.
Where are your visitors? Selected markets choose comparison frameworks. Legal applicability also depends on establishment, targeting, business activity and statutory exceptions.
### Frameworks compared for Germany
- European Accessibility Act
- Directive (EU) 2019/882: European Accessibility Act
- Barrierefreiheitsstärkungsgesetz (BFSG): German transposition
- EN 301 549 v3.2.1: harmonised ICT accessibility standard
- WCAG 2.2 (W3C Recommendation)
- WCAG 2.1 (W3C Recommendation)
- GDPR & ePrivacy
- Regulation (EU) 2016/679: GDPR
- Directive 2002/58/EC: ePrivacy Directive (Art. 5(3))
- § 25 TDDDG: German cookie-consent transposition
- EDPB Guidelines 03/2022: deceptive design patterns
- CJEU Planet49 (C‑673/17): consent / pre-ticked boxes
### What the automated scan checks for Germany
- Trackers firing before consent
A request to a known tracking endpoint made before any consent gesture. We match the receiving host, and we separate a data-firing hit from a loader script that may never send anything.
- Cookies set before consent
Cookies observed before any banner interaction. Known tracker cookies (Google Analytics, Meta Pixel and other recognised vendors) are reported as observed evidence at full severity. Cookies we cannot classify by name are flagged for review at low severity, because a name alone does not establish purpose or an exemption.
- Web Storage / IndexedDB writes before consent
localStorage, sessionStorage and IndexedDB entries written before any banner interaction. Keys written by recognised tracking SDKs are reported as observed evidence; keys we cannot classify are flagged for review at low severity until their purpose is established.
- No consent banner at all
No banner DOM detected on a page with a recognized tracking network signal. Cookie/storage names alone do not trigger this check. Banner timing, consent purpose and exceptions remain subject to review.
- No reject option
No reject path recognized among the banner controls inspected. Nested settings, custom controls and the effect of rejecting require manual verification.
- Reject harder to find than accept
A visual-weight heuristic flags a recognized reject control as less prominent than accept. This does not establish equal ease of refusal across the complete interaction.
- Pre-ticked consent boxes
Category controls classified as non-essential appear selected on initial render. Verify actual category purpose, prior consent state and what the controls authorize.
- Google Fonts loaded from Google
A request to fonts.googleapis.com or fonts.gstatic.com rather than self-hosting.
- reCAPTCHA on pages without a detected form
A reCAPTCHA request on pages with no form to protect.
- Trackers absent from your privacy policy
A detected vendor name absent from discovered policy text. This is a review prompt: sufficiently specific recipient categories may satisfy disclosure requirements.
- Privacy policy present and reachable
Same-host links or guessed paths returning HTML with policy keywords. This is a discovery heuristic; it does not verify operator relevance, completeness or external-host notices.
- Accessibility statement present
Same-host accessibility information discovered through links, paths and keywords. Verify EAA scope, exemptions, equivalent information in terms and the accuracy of any claims.
- Imprint / legal notice present
Same-host legal-notice discovery by links, paths and keywords. The finding is triggered only for a primary market of Germany or Austria; legal applicability and required contents need review.
## Coverage and manual verification
This inventory describes scanner capabilities, not which checks ran or passed in this scan. Automated signals and manual review overlap. No entry establishes full conformance. Review the applicable requirements, complete processes and relevant page states; newer WCAG criteria may be comparison guidance rather than a legal duty for your organization.
Criterion names and detailed technical guidance are provided in English. Follow the official links for the complete requirements and exceptions.
Coverage inventory version: 2026-09-11
WCAG 2.0 / 2.1 / 2.2 - A / AA
4.1.1 Parsing is obsolete in WCAG 2.2. Current W3C notes consider it satisfied for HTML/XML in WCAG 2.0 and 2.1; it is not counted as automated coverage or a manual failure.
- 1.1.1 Non-text Content A · WCAG 2.0 · Partial automated check
Automated observation: Missing or invalid text-alternative markup for supported elements.
Manual verification: Review whether alternatives convey the purpose of meaningful content and whether decorative content is appropriately ignored.
- 1.2.1 Audio-only and Video-only (Prerecorded) A · WCAG 2.0 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: For prerecorded audio-only, verify an equivalent text alternative; for video-only, verify an equivalent text alternative or audio track. Check clearly labelled media-alternative exceptions.
- 1.2.2 Captions (Prerecorded) A · WCAG 2.0 · Automated review signal
Automated observation: Video markup without a caption/subtitle track; media content is not verified.
Manual verification: Review caption accuracy, synchronization and meaningful sounds for prerecorded synchronized audio; verify media-alternative exceptions and open/custom-player captions.
- 1.2.3 Audio Description or Media Alternative (Prerecorded) A · WCAG 2.0 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: For prerecorded synchronized media, review audio description or a full media alternative, subject to the clearly labelled media-alternative exception.
- 1.2.4 Captions (Live) AA · WCAG 2.0 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Review captions for live audio in synchronized media. Audio-only live content is not the same criterion.
- 1.2.5 Audio Description (Prerecorded) AA · WCAG 2.0 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Review audio description of necessary visual information in prerecorded synchronized video.
- 1.3.1 Info and Relationships A · WCAG 2.0 · Partial automated check
Automated observation: Selected structural, table and form relationships.
Manual verification: Verify that structure and relationships conveyed visually are also available programmatically or in text, including tables and form groups.
- 1.3.2 Meaningful Sequence A · WCAG 2.0 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Check whether meaningful reading sequence is programmatically available. Keyboard focus order needs its own review under 2.4.3.
- 1.3.3 Sensory Characteristics A · WCAG 2.0 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Verify instructions do not rely solely on sensory characteristics such as shape, color, size, visual location, orientation or sound.
- 1.3.4 Orientation AA · WCAG 2.1 · Automated review signal
Automated observation: Orientation-query/transform patterns; actual restriction is not established.
Manual verification: Use the content in portrait and landscape; verify any restriction is essential. An orientation-related CSS transform alone proves neither failure nor conformance.
- 1.3.5 Identify Input Purpose AA · WCAG 2.1 · Partial automated check
Automated observation: Selected autocomplete attribute checks.
Manual verification: Review fields collecting user information for applicable standardized input purposes and correct programmatic identification.
- 1.4.1 Use of Color A · WCAG 2.0 · Partial automated check
Automated observation: Selected inline links distinguished by color alone; other uses of color need review.
Manual verification: Colour is not the only means of conveying information (e.g. links, errors).
- 1.4.2 Audio Control A · WCAG 2.0 · Automated review signal
Automated observation: Autoplay, sound and visible native-control signals; actual duration/custom controls are not verified.
Manual verification: Check actual audio playback, duration and available pause/stop or independent volume controls when automatic audio lasts more than three seconds.
- 1.4.3 Contrast (Minimum) AA · WCAG 2.0 · Partial automated check
Automated observation: Measurable text/background contrast in the inspected state.
Manual verification: Check text contrast in relevant states and backgrounds, including content that automation cannot measure; apply the criterion thresholds and exceptions.
- 1.4.4 Resize Text AA · WCAG 2.0 · Partial automated check
Automated observation: Viewport settings that may restrict zoom; no complete 200% resize test.
Manual verification: Resize text to 200% and verify usable content and controls without loss, accounting for the criterion exceptions.
- 1.4.5 Images of Text AA · WCAG 2.0 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Prefer text over images of text where the technology can achieve the presentation; check customization or essential-presentation exceptions, including logos.
- 1.4.10 Reflow AA · WCAG 2.1 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Check vertical content at 320 CSS pixels wide and horizontal content at 256 CSS pixels high, without two-dimensional scrolling or loss; account for content requiring a two-dimensional layout.
- 1.4.11 Non-text Contrast AA · WCAG 2.1 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Check required visual information for controls, states and meaningful graphics against adjacent colors; account for inactive, unmodified user-agent and essential-presentation exceptions.
- 1.4.12 Text Spacing AA · WCAG 2.1 · Partial automated check
Automated observation: Inline spacing styles that can prevent user text-spacing overrides; actual resizing and content loss require review.
Manual verification: Apply the specified line, paragraph, letter and word spacing overrides without loss of content or functionality; account for language and markup conditions.
- 1.4.13 Content on Hover or Focus AA · WCAG 2.1 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Verify additional hover/focus content can be dismissed, hovered and kept visible as required; review applicable exceptions.
- 2.1.1 Keyboard A · WCAG 2.0 · Partial automated check
Automated observation: Selected markup and focusability failures; not complete keyboard workflows.
Manual verification: Complete all applicable functions by keyboard, including custom controls and workflows; verify essential path-dependent input exceptions.
- 2.1.2 No Keyboard Trap A · WCAG 2.0 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Verify focus can leave every component by keyboard; if exit needs more than standard arrow/tab or other standard methods, verify users are advised of the exit method.
- 2.1.4 Character Key Shortcuts A · WCAG 2.1 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: For character-key shortcuts, verify they can be disabled, remapped to include a non-character key, or are active only while the relevant component has focus.
- 2.2.1 Timing Adjustable A · WCAG 2.0 · Automated review signal
Automated observation: Certain timed meta-refresh patterns; not session or process time limits.
Manual verification: Review time limits throughout tasks, including sessions and forms. Check turn-off, adjustment or extension mechanisms and applicable essential, real-time or longer-than-20-hour exceptions.
- 2.2.2 Pause, Stop, Hide A · WCAG 2.0 · Partial automated check
Automated observation: Selected obsolete blinking/scrolling markup; not all dynamic content.
Manual verification: Check moving, blinking, scrolling and auto-updating content for the required pause, stop, hide or update controls and applicable conditions/exceptions.
- 2.3.1 Three Flashes or Below Threshold A · WCAG 2.0 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Assess whether flashing stays at no more than three flashes in any one-second period OR remains below the general/red flash thresholds. Use suitable analysis for suspect media.
- 2.4.1 Bypass Blocks A · WCAG 2.0 · Automated review signal
Automated observation: Landmark advice only, unscored; absence of a landmark does not prove missing bypass mechanisms.
Manual verification: Verify an operable mechanism bypasses blocks repeated across pages; check actual skip links, landmarks or heading navigation with appropriate assistive technology.
- 2.4.2 Page Titled A · WCAG 2.0 · Partial automated check
Automated observation: Missing page title; descriptive quality needs review.
Manual verification: Confirm each page title describes its topic or purpose; existence of a title alone is insufficient.
- 2.4.3 Focus Order A · WCAG 2.0 · Automated review signal
Automated observation: Positive-tabindex advice only, unscored; meaningful focus order is not verified.
Manual verification: Navigate complete tasks by keyboard and confirm focus order preserves meaning and operation, including dialogs and dynamically inserted content.
- 2.4.4 Link Purpose (In Context) A · WCAG 2.0 · Partial automated check
Automated observation: Selected missing link names; purpose in context needs review.
Manual verification: Review whether each link purpose can be determined from its text or programmatically associated context, subject to the criterion exception.
- 2.4.5 Multiple Ways AA · WCAG 2.0 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Verify more than one way to locate pages in a set, except pages that are a result of, or a step in, a process.
- 2.4.6 Headings and Labels AA · WCAG 2.0 · Automated review signal
Automated observation: Empty-heading advice only, unscored; descriptive quality is not verified.
Manual verification: Confirm headings and labels describe their topic or purpose. An empty-heading check does not evaluate their quality or meaning.
- 2.4.7 Focus Visible AA · WCAG 2.0 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: A visible focus indicator appears on every keyboard-focusable element.
- 2.4.11 Focus Not Obscured (Minimum) AA · WCAG 2.2 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Move keyboard focus through relevant states; confirm author-created content does not entirely hide the focused component, considering criterion notes.
- 2.5.1 Pointer Gestures A · WCAG 2.1 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Verify single-pointer operation without path-based gestures unless the gesture is essential; check the criterion scope and user-agent exception.
- 2.5.2 Pointer Cancellation A · WCAG 2.1 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: For single-pointer input, review no-down-event activation, abort/undo, up-reversal or essential-down-event alternatives; up-event activation is not the only allowed route.
- 2.5.3 Label in Name A · WCAG 2.1 · Partial automated check
Automated observation: Selected visible-label and accessible-name mismatches; verify speech-input operation and all controls.
Manual verification: The accessible name of a control contains its visible label text.
- 2.5.4 Motion Actuation A · WCAG 2.1 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Review alternatives to motion-based operation and ability to disable motion response, subject to supported-interface and essential exceptions.
- 2.5.7 Dragging Movements AA · WCAG 2.2 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Verify a single-pointer alternative without dragging for drag-based functions, unless dragging is essential or an applicable user-agent exception applies.
- 2.5.8 Target Size (Minimum) AA · WCAG 2.2 · Partial automated check
Automated observation: Supported target-size/spacing checks in the inspected viewport/state.
Manual verification: Check pointer target dimensions or sufficient spacing against the 24 CSS pixel criterion and its equivalent, inline, user-agent and essential exceptions.
- 3.1.1 Language of Page A · WCAG 2.0 · Partial automated check
Automated observation: Presence and syntax of the document language.
Manual verification: Confirm the programmatically identified page language matches the actual content; a syntactically valid language code is not enough.
- 3.1.2 Language of Parts AA · WCAG 2.0 · Partial automated check
Automated observation: Language-attribute syntax; actual language changes are not identified.
Manual verification: Review language changes in passages and phrases for correct programmatic identification and applicable exceptions.
- 3.2.1 On Focus A · WCAG 2.0 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Verify receiving focus does not itself initiate a change of context.
- 3.2.2 On Input A · WCAG 2.0 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Verify changing a user-interface setting does not automatically change context unless the user was advised of that behavior before using the component.
- 3.2.3 Consistent Navigation AA · WCAG 2.0 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Within a set of pages, verify repeated navigation mechanisms keep the same relative order unless a change is initiated by the user.
- 3.2.4 Consistent Identification AA · WCAG 2.0 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Within a set of pages, verify components with the same functionality are identified consistently.
- 3.2.6 Consistent Help A · WCAG 2.2 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Across pages sharing help mechanisms, verify their relative order remains consistent unless the user initiated a change.
- 3.3.1 Error Identification A · WCAG 2.0 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: For automatically detected input errors, verify the item in error is identified and the error is described in text.
- 3.3.2 Labels or Instructions A · WCAG 2.0 · Partial automated check
Automated observation: Selected missing/placeholder-only labels; instruction adequacy needs review.
Manual verification: Verify appropriate labels and instructions for required user input; accessible-name presence alone does not establish sufficient instructions.
- 3.3.3 Error Suggestion AA · WCAG 2.0 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Where input errors are detected and correction suggestions are known, provide suggestions unless doing so would compromise security or purpose.
- 3.3.4 Error Prevention (Legal, Financial, Data) AA · WCAG 2.0 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: For legal commitments, financial transactions, changes/deletions of user-controlled stored data, or test-response submissions, verify reversibility, error checking with correction, or review and confirmation before finalizing.
- 3.3.7 Redundant Entry A · WCAG 2.2 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Complete multi-step processes; previously supplied information should be populated or selectable when required again, subject to essential, security and validity exceptions.
- 3.3.8 Accessible Authentication (Minimum) AA · WCAG 2.2 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Test authentication for cognitive-function tests and available alternatives or assistance; verify the object-recognition and personal-content exceptions where relevant.
- 4.1.2 Name, Role, Value A · WCAG 2.0 · Partial automated check
Automated observation: Selected accessible-name, ARIA and control markup failures.
Manual verification: Inspect custom and native controls with assistive technology; verify names, roles, states, values and updates throughout interactions.
- 4.1.3 Status Messages AA · WCAG 2.1 · Not automated by Veracly
Automated observation: No criterion-specific automated check is implemented in this scanner.
Manual verification: Trigger success, error and progress messages and verify that assistive technology can announce appropriate status updates without moving focus.
### Assessment limits
- Server-side tracking is invisible to us. Conversions API, server-side tag managers, hashed-email backend sends and anything firing only inside a logged-in area cannot be observed from a public crawl.
- We see one moment in time. A/B tests, geo-targeted tags and consent state all change what loads, so a scan is a sample rather than a proof.
- We check that required documents exist, not whether they are correct. A privacy policy that is present but wrong passes this check.
- No detected issues is not proof of compliance. This inventory describes capabilities, not completed tests. Check scan findings, unsuccessful assessments, applicable business facts and manual results separately.
- Country selection triggers comparison frameworks; it does not establish territorial, sector, size or exemption conditions. WCAG versions and applicable legal requirements may differ.
- Consent checks inspect supported UI patterns and observed initial state. They do not verify complete accept/reject journeys, granular choices, later withdrawal, preference persistence or downstream vendor behavior.
- AI transparency checks use limited vendor and page-text signals. They do not establish actual AI use, all disclosure obligations, or full AI Act compliance.
- The numeric score prioritizes findings; it is not a percentage of requirements passed. A signed report proves document integrity, not the truth of every legal conclusion.
## Selected markets and legal scope
Veracly uses your configured primary market and visitor countries to choose comparison frameworks. This does not determine legal applicability: establishment, targeting, service type, business size and exceptions may all matter. A jurisdiction marked not evaluated has not been assessed by this scan; that label does not mean its laws cannot apply.
## What “automated” means
Our versioned inventory covers the 55 current WCAG 2.2 A/AA criteria, identifies when each was introduced, and separates partial automated checks, review signals and criteria we do not automate. The obsolete Parsing criterion is explained separately. This is a capability inventory, not a scan execution log.
Manual verification overlaps automated checks. Detecting missing alternative text does not establish whether existing text describes an image accurately. A clean automated result does not establish that a criterion or a complete user journey conforms.
New reports include this inventory and its limitations. Manual checks remain unverified until someone performs them; the inventory itself does not add score deductions.
## On the privacy side, the limit is structural
Tracker and cookie detection is not a sampling problem — it is an observability one. We drive a real browser to a public page and record what it does. That makes what we find highly reliable: if we say a request fired before consent, you can open DevTools and watch it fire.
It also means an entire category is invisible. Server-side tracking — Conversions API, server-side tag managers, hashed-email backend sends — leaves no trace in the browser. Neither does anything that only fires inside a logged-in area. If those matter to you, a scan is not the tool; a server-log audit is.
## Where we say “we are not sure”
Not every finding is equally solid, and reports that pretend otherwise are less useful, not more. Veracly separates three kinds:
- Observed — we watched it happen and can point at the element or the request. You can reproduce it yourself.
- Inferred — established by absence, or by a heuristic. We probed for a privacy policy across a fixed set of locations and did not find one; a site that publishes it somewhere we did not look looks identical to a site with none.
- Contextual — the technical observation is right, but the conclusion depends on facts a scan cannot reach, such as what your privacy policy actually says or whether a tag is consent-gated at runtime.
A finding in the second or third group is a prompt to look, not a verdict. We would rather tell you that than hand you a confident number built on an inference.
## What this page is not
It is a description of what our software checks. It is not legal advice, and the list of regulations we monitor is not a list of the regulations that bind you — those are different questions, and only the second one matters to a regulator. If a finding has consequences, take it to a qualified lawyer in the relevant jurisdiction.
If you think a finding is wrong, we would like to know: corrections@veracly.app . We re-scan and reissue or retract within five business days.
## Common questions
Does an automated scan prove my site is compliant? +
No, and no automated tool can. Veracly documents partial automated checks, review signals and requirements it does not automate in one version-labelled inventory. Manual verification overlaps automated checks; a detected failure pattern or a clean result does not establish full conformance. On the privacy side the limit is structural rather than statistical: we observe what a browser does on a public page, so server-side tracking, authenticated-area tracking, and anything that fires only for some visitors are invisible to us. A clean result means no client-side evidence was found on the pages crawled.
Which countries does Veracly cover? +
The 27 EU member states (European Accessibility Act), the 30 EU/EEA states including Iceland, Liechtenstein and Norway (GDPR and ePrivacy), the United Kingdom (Equality Act 2010), the United States (ADA), Canada, and Australia (Disability Discrimination Act). The inventory labels WCAG versions without implying that every jurisdiction requires every version. Canada uses an Ontario AODA comparison; actual federal or provincial duties require separate scope verification. Selected primary and visitor markets trigger comparison frameworks. Actual legal applicability also depends on establishment, targeting, business activity and statutory exceptions. If your market is not on the list, a scan still runs and still reports what it technically observes, but nothing is scored against a statute we do not monitor.
Why does my report not mention an Impressum? +
The imprint finding is raised only for sites whose primary market is Germany or Austria, where § 5 DDG and § 5 ECG bind essentially every commercial website. Switzerland has a real duty too, under Art. 3(1)(s) UWG, but it applies specifically to electronic commerce rather than to every site, and a crawl cannot tell whether a site trades online. Raising it for every Swiss site would tell brochure operators a statute binds them when it does not, so we do not.
What is the difference between the free scan and a paid report? +
The engine is identical — same rules, same jurisdictions, same scoring. The free scan covers a single page and shows the top three priorities with plain-English explanations; the paid report covers your configured page limit on a schedule, lists every priority, and adds remediation snippets, per-jurisdiction detail pages, and evidence screenshots. A finding that appears in a free scan is the same finding a paid scan would produce.
How do I check a finding myself? +
Every finding we can reproduce carries a DevTools recipe — the filter to type and what you should see. That is deliberate: a compliance finding you have to take on trust is worth less than one you can confirm in a minute. Findings we cannot reproduce that way say so instead of pretending otherwise, and the report distinguishes what we watched happen from what we inferred from absence.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- Multi-jurisdiction
### Multi-jurisdiction website compliance: one site, many laws
EU, UK, US, and Canadian visitors trigger different laws. Here is the practical playbook for satisfying GDPR, EAA, ADA, UK Equality Act, and AODA with one programme.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## Switzerland: Impressum & legal-notice requirements for commercial websites (2026)
URL: https://veracly.app/blog/impressum-switzerland
Published: 2026-07-06

Imprint
# Switzerland: Impressum & legal-notice requirements for commercial websites (2026)
Switzerland requires a legal notice (Impressum) on commercial websites under Art. 3(1)(s) UWG, narrower than Germany’s rule, but the email address is explicitly mandatory. Here is the field-by-field checklist and how Swiss law differs from the German DDG.
By Veracly Compliance Team · 2026-07-06· 6 min read
Switzerland is often lumped in with Germany and Austria as a “DACH Impressum” market, and a German-style legal notice will usually satisfy Swiss authorities. But the Swiss rule is its own thing: a different statute, a narrower scope, and one requirement that is stricter than most people expect. If you sell into Switzerland, or run a.ch site, this is what actually applies.
## The legal basis: Art. 3(1)(s) UWG
Switzerland does not have a dedicated “imprint law” like Germany’s DDG. The obligation lives in unfair-competition law: Article 3 paragraph 1 letter s of the Federal Act against Unfair Competition (UWG in German, LCD in French, LCSl in Italian; SR 241), added in the revision that came into force on 1 April 2012 .
The provision makes it an act of unfair competition to offer goods, works, or services in electronic commerce without, among other things, providing clear and complete information on your legal identity and contact address, including your email address . The same letter (s) also carries the e-commerce contract-formation duties — stating the technical steps to conclude a contract, providing a way to detect and correct input errors, and confirming the order by email — but it is the identity-and-contact limb that functions as the Swiss “Impressum.”
## Who is in scope
The trigger is electronic commerce — offering goods, works, or services online. That squarely covers webshops, online booking systems, and paid digital products. A purely informational brochure site with no online offer sits, on the strict wording, outside Art. 3(1)(s). In practice we still recommend publishing a legal notice: the line between “informational” and “offering a service” is thin (a bookable appointment, a quote request, or a paid download can cross it), and a complete notice costs nothing to maintain.
## Switzerland vs Germany vs Austria at a glance
All three DACH countries require a legal notice, but the statute and the scope differ. Switzerland’s is the narrowest — it only bites once you are actually selling online, whereas the German and Austrian rules reach almost every business site.
Requirement Switzerland Germany Austria
Legal basis Art. 3(1)(s) UWG §5 DDG (ex-TMG §5) §5 ECG; §25 MedienG (media)
Applies to Sites offering goods or services in electronic commerce Almost all business websites Almost all commercial websites
Email address Mandatory — named in the statute Required (rapid electronic contact) Required under §5 ECG
Business identifier UID (CHE-xxx.xxx.xxx) + commercial register HRB number + USt-IdNr. Firmenbuch number + UID (ATU)
The practical upshot: a purely informational site can be out of scope in Switzerland yet still need a legal notice in Germany or Austria.
## The Swiss field-by-field checklist
Art. 3(1)(s) asks for “clear and complete” identity and contact details. In practice a compliant Swiss legal notice contains:
- Full legal name and legal form (AG, GmbH, Einzelfirma / raison individuelle, etc.).
- Physical address — a real street address in the seat of the business, not only a P.O. box.
- Email address — explicitly named in the statute, and therefore mandatory. A contact form alone does not satisfy it.
- A direct contact channel beyond email — a telephone number is the safe default.
- Commercial-register entry for registered businesses (the cantonal Handelsregister / registre du commerce), together with the UID — the Swiss business identification number in the format CHE-xxx.xxx.xxx.
- VAT number if the business is VAT-registered (the UID suffixed with MWST / TVA / IVA).
- Regulated-profession details where applicable (authorisation, supervisory authority) — e.g. medical, legal, or financial services.
## Where it goes, and what auditors check
The mechanics mirror the German rules even though the statute differs:
- Reachable from every page — a footer link, labelled clearly (“Impressum,” “Legal notice,” or “Mentions légales,” depending on the site language).
- A real <a> link , indexable by crawlers — not a JavaScript-only modal.
- Consistent with the privacy policy — the entity named in the legal notice matches the data controller in the privacy policy.
- Language. There is no language mandate, but the notice should be in the language(s) you actually sell in — German, French, Italian, or English.
## Don’t confuse it with the privacy policy
The legal notice is a separate obligation from data protection. Switzerland’s revised Federal Act on Data Protection (revFADP / nDSG / nLPD) came into force on 1 September 2023 and requires a privacy policy describing how you process personal data. Many Swiss sites merge the two into one “Impressum & Datenschutz” page; that is fine, as long as both sets of information are actually present.
## How enforcement works — no Abmahnung, but real exposure
Switzerland lacks Germany’s cottage industry of Impressum Abmahnungen , so the day-to-day risk feels lower. It is not zero. A missing or incomplete legal notice is an unfair-competition act, and two provisions do the work. Art. 9 UWG defines the civil claims — prohibition, cessation, declaratory relief, damages and account of profits — for anyone whose clientele, credit or professional standing is threatened or harmed, which in practice means competitors. Art. 10 UWG is what extends standing beyond them: to customers (para. 1), to professional and trade associations and to consumer organisations of national or regional standing (para. 2), and to the Confederation (para. 3). On top of that, Art. 23 UWG makes an intentional breach a criminal offence prosecuted on complaint. The practical takeaway is the same as everywhere — the fix is cheap, so there is no reason to carry the risk.
## What Veracly does and does not check here
Bluntly: the imprint check does not run on Swiss sites. Veracly’s imprint detection is gated to sites whose primary country is Germany or Austria, because that is where the presence duty is general enough to grade mechanically. Point a scan at a .ch domain and it raises no imprint finding at all — not a pass, not a fail, nothing. We would rather write that sentence than let a Swiss reader assume a silent report means a clean legal notice.
And where it does run, it checks presence , not content. There is no field validation anywhere in the product. Nothing reads your legal notice and confirms that the email address, the UID, or the commercial-register entry is actually in it, and nothing checks it against Art. 3(1)(s) UWG. The field-by-field checklist above is the audit; it is a one-off job for a human, and it takes about twenty minutes.
A scan of a Swiss site still does real work — the axe-core accessibility pass, the pre-consent cookie, storage and third-party tracker observations, and policy-page detection — but which jurisdiction rule packs it grades against is driven by country, and Switzerland sits outside the EAA, ADA, UK Equality Act and AODA country sets. Read the findings on their own terms; do not expect a Swiss verdict. Run a scan .
See also: Impressum requirements for German websites · What is a website compliance audit?
Live check
### Does this site have a compliant Impressum?
Paste any URL to check whether a reachable Impressum / legal-notice page exists. Results in a couple of seconds.
Automated check of a single page, informational only, not legal advice.
## Common questions
Does a Swiss commercial website need an Impressum? +
If the site offers goods, works, or services in electronic commerce, a webshop, online booking, or paid digital product, yes. The legal basis is Art. 3(1)(s) of the Federal Act against Unfair Competition (UWG / UCA, SR 241), in force since 1 April 2012. A purely informational brochure site with no online offer is arguably outside the strict wording, but publishing a legal notice anyway is standard practice and removes the argument.
What must a Swiss legal notice contain? +
Art. 3(1)(s) UWG requires clear and complete information on the operator’s legal identity and contact address, and it names the email address explicitly. In practice that means: full legal name and legal form, a physical address (not just a P.O. box), a working email address, and, for registered businesses, the commercial-register entry and UID (CHE-xxx.xxx.xxx). Add the VAT number if the business is VAT-registered.
Is the email address mandatory in Switzerland? +
Yes. Unlike some jurisdictions where a contact form can suffice, Art. 3(1)(s) UWG names the email address as part of the required contact information for electronic commerce. A contact form alone does not satisfy the wording.
How is the Swiss requirement different from Germany’s Impressum? +
Scope. Germany’s §5 DDG applies to almost every business website. Switzerland’s Art. 3(1)(s) UWG applies specifically to electronic commerce, sites that offer goods or services online. So a Swiss informational site may be out of scope where an equivalent German site would not be. The disclosed fields also differ: Switzerland uses the UID and commercial-register data rather than the German HRB number and USt-IdNr.
Does Switzerland have the German-style Abmahnung system? +
No. Switzerland does not have Germany’s mass cease-and-desist (Abmahnung) industry. But a non-compliant legal notice is still an unfair-competition act. Art. 9 UWG sets out the civil claims (prohibition, cessation, declaratory relief, damages) for anyone whose clientele, credit or professional standing is threatened — in practice, competitors. Art. 10 UWG extends standing beyond them: to customers (para. 1), to professional and trade associations and to consumer organisations of national or regional standing (para. 2), and to the Confederation (para. 3). Art. 23 UWG allows criminal prosecution on complaint. The exposure is real, just enforced differently.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Imprint
### Imprint (Impressum) requirements for German websites in 2026
Germany and Austria require an Impressum on every commercial website; Switzerland only for sites offering goods or services online. Here is the legal basis, the field-by-field checklist, and the common failures that trigger Abmahnung letters.
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## Website compliance in Finland: cookies, GDPR and accessibility
URL: https://veracly.app/blog/website-compliance-finland
Published: 2026-06-27

Multi-jurisdiction
# Website compliance in Finland: cookies, GDPR and accessibility
Finland splits cookie oversight between two regulators and was one of the last EU states to abandon browser-settings consent, in 2021. Here is how the cookie rule, GDPR and the European Accessibility Act actually apply to a Finnish website.
By Veracly Compliance Team · 2026-06-27· 7 min read
Finland applies the same EU rules as the rest of the union — GDPR for personal data, ePrivacy for cookies and storage, and the European Accessibility Act for accessibility — but its implementation has two distinctive features: cookie oversight is split between two regulators , and Finland was one of the last EU member states to abandon “consent” by browser settings. This guide maps the three frameworks as they apply to a Finnish website in 2026.
## The three frameworks that apply
- GDPR + Tietosuojalaki. The GDPR applies directly, supplemented by the Finnish Data Protection Act (Tietosuojalaki, 1050/2018). The regulator is the Office of the Data Protection Ombudsman (Tietosuojavaltuutettu).
- ePrivacy via the Act on Electronic Communications Services. The cookie-storage rule is Section 205 of Act 917/2014, supervised by Traficom.
- EAA via the Act on the Provision of Digital Services. The European Accessibility Act was implemented through amendments to existing laws, including Act 306/2019, in scope from 28 June 2025.
## Cookies: Section 205 and active consent
Under Section 205 of the Act on Electronic Communications Services, storing or reading information on a user’s terminal equipment requires consent unless the storage is strictly necessary to deliver the service the user requested. Analytics cookies such as _ga or _pk_id are not strictly necessary, so they need prior opt-in consent.
Finland arrived at that position late. Traficom continued to accept browser settings as a way of expressing consent even after the Court of Justice decided Planet49 (C-673/17) on 1 October 2019, leaving Finland one of the last holdouts in the EU. The position turned on the Deputy Data Protection Ombudsman’s decision of 14 May 2020, which held that telling users to manage their browser privacy settings is not sufficiently active and explicit consent; Traficom and the Office of the Data Protection Ombudsman then jointly issued revised cookie guidance on 13 September 2021. The headline points:
- Consent must be an active, affirmative action — no pre-ticked boxes, no implied consent.
- Non-essential cookies may not be set before that consent is given.
- Rejecting cookies must be as easy as accepting them.
- Browser-settings “consent” is no longer acceptable.
Finnish courts have since reinforced enforcement of cookie legislation, so this is not guidance that can be safely ignored. It aligns with the EU-wide consensus on reject-all parity and on which framework governs cookies .
## Two regulators, two questions
Finland’s split model is worth understanding because it changes who you answer to:
- Traficom (the Finnish Transport and Communications Agency, via its Cyber Security Centre) supervises the storage rule — the §205 question of whether information may be placed on or read from the device at all.
- The Office of the Data Protection Ombudsman supervises the processing — the GDPR question of whether the personal data the cookies collect is handled lawfully, with valid consent and the required disclosures.
A Finnish site needs both correct: a valid storage consent under §205, and a valid GDPR basis and notice for what follows.
## Accessibility: Act 306/2019 and the EAA
The Act on the Provision of Digital Services (306/2019) has required accessibility from public-sector and certain publicly-funded and essential services since 2019, measured against EN 301 549 — in practice WCAG 2.1 Level A and AA . The European Accessibility Act then extended accessibility obligations to a wide range of consumer-facing private products and services from 28 June 2025. Notably, Finland implemented the EAA largely by amending existing legislation (including Act 306/2019), with a separate act for products — Act 102/2023 on the accessibility requirements of certain products — rather than one consolidated statute.
Do not address this to a Regional State Administrative Agency. Supervision of digital accessibility passed from Etelä-Suomen aluehallintovirasto to Traficom on 1 January 2025, and the Regional State Administrative Agencies were abolished altogether at the end of 2025. That gives Traficom three roles on a Finnish website: cookie storage under §205, digital accessibility under Act 306/2019, and market surveillance for products under Act 102/2023. It can enforce requirements including through conditional fines under the Act on Conditional Fines (uhkasakkolaki, 1113/1990).
## A practical checklist for a Finnish site
- No non-essential cookie, pixel or storage write fires before active consent.
- Consent is by affirmative action — not browser settings, not pre-ticked boxes.
- Reject is as easy and prominent as Accept .
- A privacy notice names the trackers and the GDPR legal basis for processing.
- The site meets WCAG 2.1 AA (EN 301 549) for consumer-facing content.
## How Veracly checks a Finnish website
Veracly evaluates a Finnish URL against all three frameworks in one scan. The cookie module records the third-party requests, cookies and storage writes present before the banner is touched — and it never touches the banner, because clicking one would itself be a consent gesture and would pollute the pre-consent reading. It flags non-essential storage set before consent, a missing banner, a missing or unequal reject path, and pre-ticked consent. Two limits worth stating plainly: we cannot detect reliance on browser settings, because that is a claim in your banner copy rather than an observable runtime behaviour, so a human has to read it; and only requests to other hosts are recorded, so a self-hosted Matomo setting _pk_id from your own domain is invisible to the request log. Reject parity is read from the rendered banner — button kind, visibility, visual weight — not tested by clicking Reject. The accessibility module runs axe-core against the rendered DOM for WCAG 2.1 AA, and tracker findings come with a DevTools recipe you can run yourself.
See also: Website compliance in the Netherlands · Auditing a site across multiple jurisdictions · The EAA for small and medium businesses
## Common questions
Can I rely on browser settings for cookie consent in Finland? +
No, but Finland was slow to say so. Traficom treated browser settings as a valid way of expressing consent even after the CJEU decided Planet49 (C-673/17) on 1 October 2019, which made Finland one of the last holdouts in the EU. That ended with the Deputy Data Protection Ombudsman decision of 14 May 2020, after which Traficom and the Office of the Data Protection Ombudsman jointly reissued the cookie guidance on 13 September 2021: consent must be given by an active, affirmative action, and pointing users to their browser settings is not valid consent. Non-essential cookies may not be stored before the user actively consents, and rejecting must be as easy as accepting.
Who enforces cookie rules in Finland? +
Two authorities. Traficom (the Finnish Transport and Communications Agency, through its Cyber Security Centre) supervises the technical storage rule under §205 of the Act on Electronic Communications Services. The Office of the Data Protection Ombudsman (Tietosuojavaltuutettu) supervises the GDPR consent and data-processing that the cookies trigger. Finnish courts have upheld enforcement of these rules.
Does the European Accessibility Act apply to my Finnish website? +
For in-scope consumer products and services from 28 June 2025, yes. Finland implemented the EAA largely as amendments to existing laws, including the Act on the Provision of Digital Services (306/2019), plus a separate act for products (102/2023). Digital services are measured against EN 301 549, which means WCAG 2.1 Level A and AA in practice. The supervising authority is Traficom: supervision of digital accessibility passed from Etelä-Suomen aluehallintovirasto to Traficom on 1 January 2025, and the Regional State Administrative Agencies were abolished at the end of 2025. Traficom is also the market-surveillance authority for Act 102/2023.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- Multi-jurisdiction
### Multi-jurisdiction website compliance: one site, many laws
EU, UK, US, and Canadian visitors trigger different laws. Here is the practical playbook for satisfying GDPR, EAA, ADA, UK Equality Act, and AODA with one programme.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## Website compliance in the Netherlands: cookies, GDPR and accessibility
URL: https://veracly.app/blog/website-compliance-netherlands
Published: 2026-06-27

Multi-jurisdiction
# Website compliance in the Netherlands: cookies, GDPR and accessibility
The Netherlands applies the same EU rules as everyone else, but through its own statutes and regulators. The cookie rule is in the Telecommunicatiewet, where the ACM supervises Art. 11.7a itself and the Autoriteit Persoonsgegevens covers the GDPR side, and accessibility is now law under the Implementatiewet.
By Veracly Compliance Team · 2026-06-27· 7 min read
The Netherlands is an EU member state, so the headline rules are the same ones that apply across the bloc: the GDPR for personal data, the ePrivacy Directive for cookies and storage, and the European Accessibility Act for digital accessibility. What trips up operators is that each of these reaches a Dutch website through a different national statute and a different regulator . This guide maps the three frameworks as they actually apply in the Netherlands in 2026.
## The three frameworks that apply
- GDPR + UAVG. The GDPR applies directly, and the Dutch Uitvoeringswet AVG (UAVG) fills in the national detail. The supervisory authority is the Autoriteit Persoonsgegevens (AP).
- ePrivacy via the Telecommunicatiewet. The cookie-consent rule is Article 11.7a of the Telecommunicatiewet, in force since 2012. This is the rule that requires the banner, not the GDPR.
- EAA via the Implementatiewet. The European Accessibility Act is transposed by the Implementatiewet toegankelijkheidsvoorschriften producten en diensten, applying to in-scope consumer products and services from 28 June 2025.
## Cookies: Article 11.7a Telecommunicatiewet
Article 11.7a requires that, before storing information on or reading information from a user’s terminal equipment, a website gives clear and complete information about the purposes and obtains consent. Three exemptions apply — one more than most member states have. The first two are the familiar ones: a cookie strictly necessary to transmit the communication, and a cookie strictly necessary to deliver a service the user explicitly requested (for example, a session or shopping-cart cookie).
The third is the one that makes the Netherlands different. Article 11.7a lid 3, added by the Act of 4 June 2014 (bill 33902), removes the consent requirement for cookies that obtain information about de kwaliteit of effectiviteit of a delivered service, provided they have geen of geringe gevolgen voor de persoonlijke levenssfeer — no or only minor consequences for privacy. That is an analytics carve-out, and it has no equivalent in the German or French transpositions.
So advertising pixels, social embeds, A/B testing and session recording all need prior opt-in consent. Analytics is the Dutch exception, and a narrow one: the AP’s own published guidance accepts that a Google Analytics deployment configured strictly to its privacy-friendly settings currently needs no consent. Every setting has to be right, and the moment the data is reused for advertising or shared onward the carve-out stops applying. As with the rest of the EU, the rule is technology-neutral: swapping a cookie for localStorage or a tracking pixel does not escape it.
## The AP cookie crackdown
Through 2025 the Autoriteit Persoonsgegevens made cookie banners a stated enforcement priority. Several organisations received a “cookie letter” asking them to fix non-compliant banners, and the AP examined how sites deploy Google Analytics 4. It acts here on the AVG side: Article 15.1(3) Telecommunicatiewet puts supervision of Art. 11.7a itself with the Autoriteit Consument en Markt, which is why the AP asked the Minister in March 2025 to be designated instead. The AP’s position on banner design is specific:
- If there is an “Accept all” button on the first layer, there must be a “Reject all” button on that same first layer, at the same level of prominence.
- A “Settings” or “Manage” link does not count as a reject option — rejecting must be as easy as accepting.
- No non-essential cookies or trackers may fire before the visitor actively consents.
This mirrors the broader EU consensus (see our piece on reject-all parity ), and it is the single most common reproducible failure Veracly detects on Dutch sites.
## Accessibility: the EAA in Dutch law
The European Accessibility Act applies EU-wide from 28 June 2025. In the Netherlands it is transposed by the Implementatiewet toegankelijkheidsvoorschriften producten en diensten, which amends several existing laws including the Warenwet (Commodity Act), the Telecommunicatiewet and the Civil Code. For digital services, consumer-facing websites, apps and web shops must be accessible — measured in practice against WCAG 2.1 AA through the harmonised standard EN 301 549.
Enforcement is split across supervisors depending on the product or service; the Autoriteit Consument en Markt (ACM) supervises e-commerce. A microenterprise relief exists for service providers (fewer than 10 staff and turnover or balance sheet at or below €2 million), but it is narrow and does not extend to products. Public-sector bodies were already covered separately under the Web Accessibility Directive.
## A practical checklist for a Dutch site
- No non-essential cookie, pixel or storage write fires before consent.
- The banner offers Reject all on the first layer, as prominent as Accept all.
- A privacy statement names the trackers used and the GDPR/UAVG legal basis.
- Analytics is either consent-gated or configured strictly to the AP’s privacy-friendly settings under Art. 11.7a lid 3; either way, any US transfer rests on a valid Chapter V mechanism.
- The site meets WCAG 2.1 AA (EN 301 549) for consumer-facing content.
## How Veracly checks a Dutch website
Veracly evaluates a Dutch URL against all three frameworks in one scan. The cookie-audit module records the third-party requests, cookies and storage writes present before the banner is touched — and it never touches the banner, because clicking one would itself be a consent gesture and would pollute the pre-consent reading. Requests to your own hostname are not recorded, so first-party-proxied tracking is invisible to it. It reports non-essential storage set before consent, a missing banner, and a missing or unequal reject path — that last one read from the rendered banner, not tested by clicking Reject.
One limit to know before you read the report: findings are mapped to a jurisdiction rule pack, not to Dutch statute. There is no Telecommunicatiewet mapping in the product yet, so the GDPR pack cites § 25 TDDDG — the German transposition of the same ePrivacy article. For a Dutch site the observation is the right one; the citation is not yet localised, and the Art. 11.7a lid 3 analytics carve-out is not modelled at all, so treat any analytics finding as a prompt to check your configuration against the AP’s settings rather than as a verdict. The accessibility module runs axe-core against the rendered DOM for WCAG 2.1 AA, and tracker findings come with a DevTools recipe you can run yourself.
See also: Website compliance in Finland · GDPR vs ePrivacy: which governs cookies? · The EAA for small and medium businesses
## Common questions
Do I need a cookie banner for a Dutch website? +
If your site sets any non-essential cookie or reads any non-essential storage, yes. Article 11.7a of the Telecommunicatiewet requires prior, informed consent before placing or reading information on a visitor’s device — subject to three exemptions, not the usual two: strictly necessary cookies, communication cookies, and a Dutch-specific carve-out in Art. 11.7a(3) for cookies that measure the quality or effectiveness of a delivered service with no or only minor consequences for privacy. That third limb is why the Autoriteit Persoonsgegevens accepts a strictly privacy-friendly configured analytics setup without consent. The AP’s 2025 guidance is explicit that if there is an “Accept all” button on the first layer, there must be a “Reject all” button on the same layer at the same prominence.
Which authority enforces cookie rules in the Netherlands? +
Two, and the split is the opposite of what most people assume. Article 15.1(3) of the Telecommunicatiewet designates the Autoriteit Consument en Markt (ACM) as the supervisor for Article 11.7a itself. The Autoriteit Persoonsgegevens (AP) is the data protection authority, and its competence over cookies flows from the AVG, which governs the personal-data processing the cookies trigger. That division is precisely why the AP wrote to the Minister in March 2025 asking to be designated the competent supervisor for Art. 11.7a. Through 2025 the AP ran a high-profile cookie-banner enforcement push on the AVG side, sending “cookie letters” to organisations and scrutinising Google Analytics 4 deployments.
Does the European Accessibility Act apply to my Dutch website? +
For most consumer-facing digital services and products placed on the market from 28 June 2025, yes. The EAA is transposed by the Implementatiewet toegankelijkheidsvoorschriften producten en diensten, which amends the Warenwet, the Telecommunicatiewet and the Civil Code. In practice websites and apps must meet WCAG 2.1 AA via EN 301 549. A microenterprise relief exists for service providers, and the Art. 3(23) test has two limbs: fewer than 10 persons employed, and either annual turnover at or below €2m or an annual balance-sheet total at or below €2m. Either financial limb suffices. The relief does not cover products.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- Multi-jurisdiction
### Multi-jurisdiction website compliance: one site, many laws
EU, UK, US, and Canadian visitors trigger different laws. Here is the practical playbook for satisfying GDPR, EAA, ADA, UK Equality Act, and AODA with one programme.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## AI chatbots on your website: do they trigger new compliance obligations?
URL: https://veracly.app/blog/ai-chatbot-compliance-2026
Published: 2026-05-12

Multi-jurisdiction
# AI chatbots on your website: do they trigger new compliance obligations?
A chatbot that answers product questions is one thing. A chatbot that screens leads, takes bookings, or makes underwriting decisions is another. The compliance surface depends on what the bot does, not on what model powers it.
By Veracly Compliance Team · 2026-05-12· 7 min read
A website chatbot in 2026 sits at the intersection of three frameworks that did not all exist when the deployment patterns settled. GDPR governs the personal-data side. ePrivacy governs the storage side. The EU AI Act adds transparency obligations and, for some chatbots, conformity assessment. None of these individually is novel; their combination on a single feature is.
## GDPR, what chatbots collect
Every chatbot collects at minimum:
- The text the user types (often containing PII volunteered for support).
- A session identifier linking utterances within a conversation.
- Timestamps, page URL, referrer.
- Sometimes: an explicit email or name field the user filled in to start the chat.
All of this is personal data under Article 4. The lawful basis depends on the chatbot’s purpose. A support chatbot generally runs on contract (6(1)(b)) or legitimate interest (6(1)(f)). A lead-generation chatbot is more contested than it is usually presented: Recital 47 GDPR says in terms that processing for direct-marketing purposes may be regarded as carried out for a legitimate interest, so 6(1)(f) is available in principle and a balancing test decides it. Consent is frequently still the right answer in practice — the marketing channel you use afterwards and the storage the widget writes need it anyway — but there is no EDPB position requiring consent for marketing chatbots as such.
Article 22, automated decision-making. Article 22(1) is worded as a right, but the CJEU read it in C-634/21 SCHUFA (7 December 2023) as a general prohibition : it applies of its own force, and the data subject does not have to invoke anything for it to bite. A chatbot answering “what time do you open?” does not trigger it. A chatbot that pre-qualifies loan applicants, screens job applicants, or routes users to different prices based on profile does. Where it applies, the processing is barred unless one of the Article 22(2) gateways is open (necessary for a contract, authorised by Union or Member State law, or explicit consent) — and on the contract and consent routes the Article 22(3) safeguards, human intervention, the right to express a point of view and the right to contest the decision, have to be designed in from the start. They are not a review path you switch on when somebody asks for it.
## The EU AI Act, Article 50 transparency
The EU AI Act (Regulation (EU) 2024/1689, phased application 2024 to 2027) imposes tiered obligations based on risk.
For chatbots, the relevant tier is Article 50 (transparency obligations for AI systems intended to interact directly with natural persons), which has applied since 2 August 2026 . Users must be informed they are interacting with an AI system, unless that is obvious to a reasonably well-informed, observant and circumspect person taking the circumstances and the context of use into account.
Who owes the duty is easy to get backwards. Article 50(1) binds the provider — the party that develops the system and places it on the market. An SMB embedding an off-the-shelf Intercom or Tidio widget is a deployer , and the design-level disclosure duty sits with the vendor. That is not a licence to relax. Deployers carry their own transparency duties elsewhere in Article 50, your users will not care about the distinction when the bot feels deceptive, and the moment you white-label the bot under your own name and persona you have arguably placed it on the market yourself and become the provider. Read the contract before assuming the vendor has it covered.
The disclosure itself should be:
- Clear, visible, and visible before the widget is opened. The instinctive placement is the bot’s opening message, and legally that is fine. But a disclosure that exists only inside the conversation is invisible to anyone who has not started one — to a visitor scanning the page, and to every automated check including ours (see below). Put it where the closed widget lives: a label or caption next to the launcher, or an aria-label naming the assistant as AI. Then repeat it in the opening message. Doing both costs nothing.
- Provided before interaction. Not buried in terms of service.
- Accessible in the language of the user. Same locale as the chat UI.
The disclosure can be as simple as “Hi! I’m an AI assistant. Ask me about [topic].” Most modern chatbot products ship this by default but a custom-built bot needs to be checked.
The higher-risk tiers of the AI Act apply when the chatbot performs functions in Annex III (recruitment, credit scoring, biometrics, education, essential services). Most SMB marketing or support chatbots are not Annex III. Confirm against your bot’s actual function, “help our customers” can mean very different things.
## ePrivacy, the storage question
A chatbot widget typically loads a script that:
- Sets a session cookie or localStorage entry to maintain chat state.
- Stores conversation history client-side for the “continue chat” UX.
- Fingerprints the user for fraud prevention or analytics.
All of this is “storage of information on terminal equipment” under ePrivacy 5(3). The exception for “strictly necessary for the service the user requested” covers the session state once the user has opened the chat. It does not cover the script loading before the user clicks the chat button.
The compliant pattern: the chat widget loads on click, not on page load. Sites that auto-pop the chatbot are firing storage on every visitor, including ones who never engage. That is ePrivacy 5(3) consent territory.
## Cross-border data transfers
Most of the large chatbot platforms (Intercom, Drift, Zendesk, HubSpot) are US-based. EU customer chat transcripts transferred to US servers re-engage the Schrems II / DPF analysis. The current state (DPF in force) means transfers are lawful provided the vendor is DPF-certified — but the framework is under challenge. The General Court dismissed Latombe v Commission (T-553/23) on 3 September 2025, and an appeal (C-703/25 P) is pending before the Court of Justice. Nobody should be building a transfer strategy that only works while the adequacy decision stands.
Vendors headquartered and hosting in the EU reduce this surface: Userlike (Germany), Crisp (France), Tidio (Poland). US vendors offering an EU workspace or EU data region, Intercom among them, narrow it without closing it. The trade-off: feature set is typically smaller and integrations with US-hosted CRMs may re-introduce a transfer at the CRM-write step.
## The LLM-backed chatbot question
Chatbots powered by GPT-4 / Claude / Gemini introduce a second layer: the prompt-plus-context sent to the LLM provider is itself a transfer . EU customer messages flowing to OpenAI’s servers are subject to the same transfer analysis as any other US-bound data.
Two mitigation patterns:
- Use an EU-region endpoint where your provider genuinely offers one. Mistral and Aleph Alpha host in the EU. The large US providers offer EU data residency to varying degrees and on varying contract terms, so check the specific product rather than the brand, and check the endpoint rather than the marketing page — eu-west-1, for instance, is an AWS region name, not a model provider’s endpoint. Also: EU hosting reduces the transfer surface, it does not eliminate it. Remote access to EU-stored data from a third country is itself a transfer under Chapter V, so who can reach the data matters as much as where it sits.
- Get explicit consent for the LLM hand-off. Disclose in the chatbot intro and the privacy policy that messages are processed by a third-party LLM provider, named explicitly, with the DPF status disclosed. This is what CNIL has signaled it expects for the LLM era.
## Practical 2026 checklist
- Does the bot identify itself as AI? Required by AI Act Article 50 from August 2026.
- Does the bot make any decision with legal or significant effect? If yes, Article 22(1) prohibits it outright unless one of the Article 22(2) gateways applies. If one does, build the human-intervention and contest path into the flow by default rather than waiting for a request.
- Does the bot load before user interaction? If yes, gate it behind consent.
- Is conversation data stored beyond the session? If yes, disclose retention period in the privacy policy and offer deletion.
- Is the bot powered by an LLM hosted outside the EU? If yes, ensure DPF certification of the provider and disclose the transfer.
- Add the chatbot vendor and the LLM provider to your subprocessors page.
## What Veracly actually checks, and where it will be wrong
The Article 50 check has shipped — the widget at the top of this post runs it. Here is what it does, in detail, because the limits matter more than the feature.
When a scan’s country scope touches the EU or EEA, Veracly runs a separate AI Act transparency assessment against the homepage. It matches third-party request URLs against 17 chat-widget vendor signatures — Intercom, Drift, Crisp, Tidio, Zendesk Chat, HubSpot Chat, LiveChat, Tawk.to, Freshchat, Olark, Gorgias, Kustomer, Userlike, Smartsupp, Chatra, Front Chat and Help Scout Beacon. Two checks are emitted:
- Check A — chatbot disclosure, Art. 50(1). Widget detected and an AI-disclosure phrase found in the page text: pass. Known vendor and no phrase: fail, high severity, with a copy-paste disclosure snippet. Generic widget pattern with no identifiable vendor: warn , not fail — because the disclosure may live in a runtime message we cannot observe, and manufacturing alarm is the thing we most want to avoid.
- Check D — AI-use clause in your policy. Advisory, low severity. It only warns when AI is actually detected on the site; a site with no chatbot and no clause comes back not applicable, not as a gap.
Checks B (labelling of AI-generated content, Art. 50(2)) and C (deepfake and synthetic-media disclosure, Art. 50(4)) exist in the type union and the database constraint, and the report renderer accepts them. They are not emitted . Nothing in Veracly detects AI-generated content or synthetic media, and we are not going to guess at it.
Four limits to hold in mind before you read a result:
- The widget is never opened. We do not click the launcher and we do not send it a message. A disclosure delivered only as the bot’s first runtime reply — the placement most vendors ship by default — is invisible to the check, so a genuinely compliant site can score a fail. That asymmetry is exactly why the placement advice earlier in this post says to put the disclosure on the closed widget as well.
- The disclosure search is page-wide, not widget-scoped. The word “chatbot” anywhere on the homepage, including in a blog teaser, turns a fail into a pass. The check errs generous in that direction, and you should not read a pass as proof the disclosure is where a user would see it.
- Homepage only. A custom in-house bot with no matching vendor signature or widget selector returns not applicable rather than a verdict.
- The readiness score is its own number. It runs 0 to 100 and never touches your compliance score or any jurisdiction verdict . Article 50 is a transparency-readiness question, not an accessibility or privacy grade, and averaging it into the others would overstate what a scan can prove.
One structural point about how this interacts with the cookie side of a scan. The AI Act vendor signature list and the tracker registry are two separate tables, and they only partly overlap. Nine of the seventeen chat vendors also carry a tracker-registry entry — Intercom, Drift, Crisp, Zendesk Chat, HubSpot, LiveChat, Tawk.to, Olark and Userlike — so if one of those widgets loads before consent, it normally also surfaces on the tracker side as a pre-consent finding, filed under the vendor’s tracker name rather than as anything labelled “chatbot”. The other eight — Tidio, Freshchat, Gorgias, Kustomer, Smartsupp, Chatra, Front Chat and Help Scout Beacon — have no tracker entry at all, so their pre-consent loading is invisible to that half of the scan. It is no less a problem for being invisible; you just have to find it in the storage and request evidence, or in DevTools, yourself.
See also: Is Google Analytics 4 illegal in Europe? · Tracking pixel audit
Live check
### Does this site disclose its AI chatbot?
Paste any URL to check whether a chat widget is present and whether it discloses that it is AI (Art. 50).
Automated check of a single page, informational only, not legal advice.
## Common questions
Does the EU AI Act apply to my website chatbot? +
It depends on the function, and on whether you are the provider or the deployer. Article 50(1) requires people to be told they are interacting with an AI system, but only where that is not obvious to a reasonably well-informed, observant and circumspect person taking the circumstances and context of use into account. That design-level duty binds the provider that develops the system and places it on the market, not the SMB that embeds an off-the-shelf widget. Deployers carry their own transparency duties elsewhere in Article 50, and white-labelling a bot under your own name and persona can make you the provider. The higher-tier obligations (risk management, conformity assessment) apply only to "high-risk" systems, which most marketing chatbots are not.
Do chatbots trigger GDPR Article 22? +
Only if the bot makes a "decision based solely on automated processing" that produces a legal or similarly significant effect on the user. A bot that books a meeting or answers FAQs does not. A bot that screens loan applications, sets insurance premiums, or rejects job candidates does.
Is chat history personal data? +
Almost always. Chat transcripts are textual data linked to a session identifier; combined with timestamps, IP addresses, or any explicit identifier the user shares, they become personal data under GDPR Article 4. Treat chat history as you would email logs, retention policy, access control, deletion process.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- Multi-jurisdiction
### Multi-jurisdiction website compliance: one site, many laws
EU, UK, US, and Canadian visitors trigger different laws. Here is the practical playbook for satisfying GDPR, EAA, ADA, UK Equality Act, and AODA with one programme.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## Cookies vs localStorage vs IndexedDB: which require consent?
URL: https://veracly.app/blog/cookies-localstorage-indexeddb-consent
Published: 2026-05-12

Cookies
# Cookies vs localStorage vs IndexedDB: which require consent?
"It is not a cookie, so it does not need consent." This is the most common technical misconception in cookie compliance. The storage rule covers every mechanism that writes to terminal equipment.
By Veracly Compliance Team · 2026-05-12· 5 min read
A persistent misconception in cookie compliance: that swapping cookies for localStorage somehow escapes the consent obligation. It does not. The ePrivacy storage rule is technology-neutral, the EDPB and national DPAs have been explicit about this for years, and the only thing that changes when a developer migrates from cookies to localStorage is the inspection tool used to find the violation.
## What Article 5(3) actually says
Directive 2002/58/EC, Article 5(3) (as amended in 2009):
Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent...
Three things in this text are worth re-reading. “Storing of information” is not storing of cookies . “Gaining of access to information already stored” covers reading device properties, not just reading what you wrote. “Terminal equipment” is the user’s device, anything you put there or read from it.
## What this covers in practice
The current consensus position (German DSK guidance December 2021; EDPB Guidelines 02/2023 on the technical scope of Article 5(3); CNIL position papers; national implementations of the ePrivacy Directive across all 27 member states):
- HTTP cookies. First-party, third-party, session, persistent, all covered.
- HSTS supercookies. The per-host HSTS state a browser persists after a Strict-Transport-Security header can be used as a tracking primitive, and read that way it is information stored on and retrieved from terminal equipment, so 5(3) engages. This is not an inference: EDPB Guidelines 02/2023 name HSTS explicitly at paragraph 43 and footnote 26, alongside ETag.
- localStorage and sessionStorage. Web Storage API entries.
- IndexedDB. Structured client-side database entries.
- Service Worker caches, Cache API entries. Service-worker-controlled caches that persist after browser close.
- File System Access API entries. When used to persist client data.
- Web SQL Database (deprecated but still seen on old codebases).
- Web Beacon / 1×1 pixel requests that write identifiers.
- ETag and Last-Modified cache headers when used as a tracking primitive (the EDPB explicitly covers cache-based identification techniques).
- Browser fingerprinting. Canvas fingerprinting, audio fingerprinting, font enumeration, WebRTC IP detection, covered as “gaining access to information already stored” on the device, even without writing anything.
## What this excludes
Server-side processing of data the user voluntarily submitted (a contact form, a checkout) does not trigger 5(3) because no storage on the user’s device occurs. That is GDPR territory, not ePrivacy 5(3). The line is whether the user’s terminal equipment is involved as a storage or readout site.
HTTP request headers the browser sends automatically (User-Agent, Accept-Language, Sec-CH-UA hints) are also outside 5(3) when used in their intended functional capacity . The moment those headers are combined to fingerprint a user, 5(3) re-engages. The EDPB’s test is neither intent nor transport but instruction : whether the entity instructed the terminal equipment to send the information (Guidelines 02/2023, paras 33–34). The same paragraphs make clear the entity that issues the instruction and the entity that receives the information need not be the same, so “we never wrote the code, we only receive the data” is not an answer.
## The “localStorage trick” that does not work
A pattern Veracly sees in the wild: a developer reads the cookie-consent law, assumes it is cookie-specific, and switches the analytics tracker to write its identifier to localStorage instead of a cookie. The CMP banner is removed because “we do not set cookies anymore.”
This is legally identical to the original cookie deployment. The storage event is the trigger; the storage mechanism is not. The argument does not need an enforcement record to stand on, which is just as well: a regulator reading Article 5(3) against a localStorage identifier arrives at the same place it arrives for a cookie, and there is nothing in the wording to push back with.
The practical consequence: a Veracly scan flags localStorage entries and IndexedDB keys the same way it flags cookies. The report’s storage inventory is not cookie-only.
## How to audit your site
- Open DevTools, hard-reload the page (Cmd-Shift-R / Ctrl-Shift-R).
- In the Application tab, expand Storage. Check Cookies, Local Storage, Session Storage, IndexedDB, Web SQL, Cache Storage.
- For each entry, ask: is this strictly necessary for the service the user requested? If no, ePrivacy 5(3) consent is required before the entry was written.
- Repeat after consent acceptance. Many sites that look clean pre-consent re-introduce trackers post-consent, which is correct as long as the trackers fired only after the consent click.
- Repeat after consent rejection. Some sites continue to fire trackers even when the user clicked reject. This is a hard violation under both ePrivacy 5(3) and GDPR Article 7.
## Veracly’s scope, precisely
Worth being exact about what is captured. On first load, before any interaction with a consent banner, Veracly records cookies from the whole browser context — which is why cookies set inside a cross-origin iframe are caught too, though a cookie carries only its name and domain, with no frame attached to it. Web Storage and IndexedDB are read per frame, and those entries do carry the URL of the frame that wrote them, so an embed’s localStorage is attributable. Anything written before consent surfaces as a pre-consent cookie or pre-consent storage-write finding, evaluated against the same 5(3) test as a cookie, because the law makes no distinction.
Two hard limits on that. First, we record keys and database names only, never values . A Veracly report cannot leak the contents of your users’ storage because it never reads them. Second, that list is the whole list: there is no Service Worker registration check, no Cache API enumeration, and no fingerprinting detection of any kind — no canvas, audio, WebGL or font-enumeration instrumentation. The earlier version of this post claimed all three. None of them are real, and the fingerprinting gap is a genuine one worth naming: canvas fingerprinting sits squarely inside Article 5(3), and we cannot see it.
The scanner also never clicks your banner. Clicking Accept or Reject would itself be a consent gesture and would pollute the pre-consent reading, which is the measurement we care most about getting right. That is a deliberate trade, and its cost is that steps 4 and 5 of the manual audit above are yours to run — there is no post-consent pass. Run a scan .
See also: GDPR vs ePrivacy: which one governs cookies? · Heat maps and session recordings: the legitimate interest grey area
## Common questions
Does localStorage really need consent? +
Yes if the storage is non-essential. ePrivacy 5(3) is technology-neutral; it covers any "storing of information, or gaining of access to information already stored, in the terminal equipment of a subscriber or user." Note that it is the wording, not a list of APIs, that does the work here: the words IndexedDB, sessionStorage, Service Worker and Cache API appear nowhere in the adopted text of EDPB Guidelines 02/2023, so treat any article quoting the Guidelines as naming them with suspicion. What the Guidelines supply is the test, and localStorage meets it without argument — it is information, it is stored, and it is on the user’s terminal equipment. The German DSK guidance of December 2021 reaches the same result for German sites.
What about fingerprinting that does not write anything? +
Article 5(3) covers both "storing of information" and "gaining of access to information already stored." Browser fingerprinting reads characteristics from the device, fonts installed, screen size, audio context. The EDPB has confirmed fingerprinting is covered, even when no cookie or storage entry is written.
Is sessionStorage different from localStorage in this respect? +
Not legally. sessionStorage clears on tab close; localStorage persists across sessions. Both trigger 5(3) when the storage is non-essential. The lifetime difference does not change the legal classification.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Cookies
### What is a cookie banner audit? (2026 checklist)
A cookie banner audit checks design, defaults, dark patterns, and what loads before any consent gesture. The Accept and Reject paths themselves have to be walked by hand. Here is the 2026 checklist.
- Cookies
### Cookie consent in Australia: what the law actually requires
Australian businesses install consent banners because European advice tells them to. There is no Australian rule requiring one for ordinary analytics. But sensitive information is a real exception, and the Privacy Commissioner enforced it against tracking pixels in June 2026.
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.

---

## Does my SMB really need to comply with the European Accessibility Act?
URL: https://veracly.app/blog/eaa-microenterprise-exemption
Published: 2026-05-12

EAA
# Does my SMB really need to comply with the European Accessibility Act?
The EAA microenterprise exemption is widely cited and widely misunderstood. It does exempt a microenterprise online shop from the service requirements. The limits are on the product side, in national law, and in the definition itself.
By Veracly Compliance Team · 2026-05-12· 7 min read
The European Accessibility Act has been in force since 28 June 2025. It applies to a broad set of products (e-readers, computers, payment terminals, self-service kiosks) and a narrower set of services (banking, e-commerce, electronic communications, audiovisual media, e-books, transport). Most SMB website operators have heard there is a microenterprise exemption. Most have a wrong idea of how it works.
## The exemption text
Article 4(5) of Directive (EU) 2019/882: “Microenterprises providing services shall be exempt from compliance with the accessibility requirements referred to in paragraph 3 of this Article and any obligations relating to the compliance with those requirements.”
Two important words: microenterprises and providing services . Both qualify the scope. And the Directive defines microenterprise for itself, in Article 3(23) — it does not incorporate Commission Recommendation 2003/361/EC, which matters, because that Recommendation would drag in linked- and partner-enterprise aggregation and a two-year grace period that the EAA does not have. The Article 3(23) test is an enterprise which:
- employs fewer than 10 persons , and
- has an annual turnover not exceeding €2 million or an annual balance-sheet total not exceeding €2 million
Read those conjunctions carefully, because this is where most write-ups go wrong. The headcount limb is mandatory. The financial limb is a disjunction : either measure under the ceiling is enough, and the ceiling is “not exceeding,” so exactly €2M is inside the definition rather than outside it. So:
- A 9-person consultancy with €3M turnover and a €1M balance-sheet total is a microenterprise.
- A 9-person consultancy with €3M turnover and a €4M balance-sheet total is not.
- A 12-person consultancy with €500k revenue is not, whatever its balance sheet says.
## What “providing services” excludes
The exemption is for service providers. Manufacturers, importers, and distributors of EAA-covered products are not exempt regardless of size. A 4-person company importing payment terminals into the EU does not get a microenterprise free pass on the accessibility requirements for those terminals.
For most SMB website operators this is academic, they do not import payment hardware. But it does mean that if your site is the storefront through which an EAA-covered product reaches end users, the product’s accessibility obligations travel with it. The service exemption does not cover that.
## The e-commerce case, which is where most articles go wrong
E-commerce is a covered service under Article 2(2)(f), defined in Article 3(30) as selling goods or services to consumers online. So Article 4(5) applies to it: a microenterprise running an online shop is exempt from the EAA’s service-side accessibility requirements for that shop. Most write-ups say the opposite, usually by reaching for the products rule and applying it to the storefront. But three things survive the exemption:
- National accessibility law is not displaced — though it reaches far fewer microenterprises than is usually claimed. Germany’s BFSG is the EAA transposition rather than something that pre-dates it, and §3 Abs. 3 BFSG carries the same microenterprise exemption across. France’s private-sector duty is Article 47 of Loi n° 2005-102, which bites only above €250M average turnover; RGAA is the technical reference it points to, not a law. Italy’s Legge Stanca was extended to private firms only above €500M average turnover. Spain’s duty is RD 1112/2018, covering the public sector and services of general economic interest; UNE 139803 is an AENOR standard, not legislation. For an actual microenterprise, none of those four is likely to bite.
- Antidiscrimination law still applies. The UK Equality Act 2010 (post-Brexit but still in force) imposes a reasonable-adjustments duty regardless of microenterprise status. Germany’s AGG, France’s 2005 disability law, similar.
- The product side still applies. Reselling an EAA-covered product means the product obligations follow the chain.
## The practical decision tree
- Is the service you provide even in Article 2(2)? The list is closed: electronic communications, access to audiovisual media services, certain transport elements, consumer banking, e-books, e-commerce. If your service is not on it — a clinic, a law firm, a builder — the EAA does not reach you and the exemption is beside the point.
- Are you a microenterprise under Article 3(23)? Fewer than 10 persons AND turnover or balance-sheet total not exceeding €2M — either financial measure will do. If no, assume the EAA applies.
- Do you sell or distribute EAA-covered products? If yes, microenterprise exemption does not cover the product obligations.
- Does your member state impose a private-sector accessibility duty that actually reaches you? At microenterprise size, usually not. Germany carries the exemption straight across in §3 Abs. 3 BFSG. France’s Article 47 duty starts at €250M average turnover and Italy’s Legge Stanca at €500M. Spain’s RD 1112/2018 covers the public sector and services of general economic interest. Ireland transposed the EAA in 2023 and carried the service exemption with it; its Disability Act 2005 duty runs to public bodies. Check your own transposition rather than assuming in either direction.
- Do you operate cross-border? Even microenterprise services may be caught by the destination country’s law if you target users there.
- Are you near the threshold? If you expect to reach 10 persons in the next 12 months, or to pass €2M on turnover and balance-sheet total together, plan as if the EAA applies. The exemption ends the day you cross.
## What the exemption does not change
Even when the EAA exemption applies cleanly, three things remain:
- GDPR cookie and tracking obligations are unaffected. GDPR has no microenterprise exemption. A 3-person SMB site that fires a Meta Pixel pre-consent has the same exposure as a 300-person one.
- Accessibility statement obligations under national law may still apply. Germany’s BFSG, for example, requires an accessibility statement from non-microenterprises but encourages it from microenterprises.
- The enforcement surface is national, and it is worth being precise about it rather than alarming. In Germany, §32 BFSG lets a consumer or a recognised association apply to the Land market-surveillance authority to take action; §33 is the separate step that opens once such an application is refused, giving the consumer an administrative remedy and recognised associations a right of action — but §3 Abs. 3 BFSG carries the microenterprise exemption into that route too, so it is not a way around the carve-out. Italy routes complaints through AgID under Legge Stanca, within that law’s own scope. In France the instrument is Article 47 of Loi n° 2005-102 and the administrative sanction attached to it — not any “DDA”; the Disability Discrimination Act is a repealed British statute and has never had anything to do with French law. General antidiscrimination law is a separate track everywhere, and that one has no size threshold at all.
## Veracly’s position
We do not ask you for a size band and we do not compute your exemption. Nothing in a scan knows your headcount or your balance-sheet total, and a report that guessed at them would be worth less than this article. The scope question above is a legal one and it stays yours.
What we do is run axe-core against the WCAG 2.2 AA superset — the 2.0, 2.1 and 2.2 A and AA rule sets together, so the 2.1 AA bar is cleared along the way — and cite the EAA rule pack whenever an EU or EEA country is in scope, whether or not you believe the exemption covers you. Two reasons that is the right default. National accessibility law and general antidiscrimination law sit outside the carve-out and are not size-gated. And if you expect to cross the threshold, the useful thing to hold on the day you do is a dated run of scans showing the work started before you had to — not a blank page and a deadline. Read the EAA findings with the Article 2(2) and Article 3(23) analysis above in mind; that is your call to make, not ours.
See also: EAA compliance for SMBs: what changed June 2025 · When does a small business lose its compliance carve-outs?
## Common questions
What is the EAA microenterprise threshold? +
Article 3(23) of the Directive: fewer than 10 persons employed, AND annual turnover not exceeding €2 million OR an annual balance-sheet total not exceeding €2 million. The headcount limb is mandatory; the financial limb is an either/or. A 9-person firm with €3M turnover but a €1M balance-sheet total is still a microenterprise. Note also that "not exceeding" means exactly €2M is inside the definition.
Does the exemption apply to e-commerce? +
Yes, to the shop itself. E-commerce is a covered service under Article 2(2)(f), so Article 4(5) does exempt a microenterprise online shop from the service-side accessibility requirements. This is the point most write-ups invert. What the exemption never reaches is the product side: manufacturers, importers and distributors of EAA-covered products (e-readers, computers, payment terminals, ATMs, ticketing machines) carry those obligations at any size, and selling such a product through your shop puts you in its distribution chain.
What about a 5-person dental practice website? +
The EAA does not reach it at all, so the exemption never has to be argued. Article 2(2) is a closed list of covered services: electronic communications, access to audiovisual media services, certain transport elements, consumer banking, e-books, and e-commerce. Healthcare is not on that list. Annex I sets out what the accessibility requirements are; it does not decide who is in scope. National accessibility and antidiscrimination law can still apply, and if the practice sells anything online, that e-commerce service is assessed separately.
When does the exemption stop applying? +
The moment you employ 10 or more persons, or you exceed €2M on turnover AND on balance-sheet total together. Because the financial limb is a disjunction, passing €2M turnover alone does not end the exemption if your balance-sheet total stays at or under €2M. There is no grace period in the Directive: Article 3(23) defines microenterprise for itself rather than importing Commission Recommendation 2003/361/EC, so that Recommendation’s two-year grace does not apply. Member-state transposition may add one. The safer planning assumption is that you lose the exemption in the financial year you cross the line.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- EAA
### EAA compliance for SMBs: what has applied since 28 June 2025
The EAA has applied to private companies in the EU since 28 June 2025. Here is the SMB-shaped version: who is in scope, who is exempt, and the four things you actually need to do.
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## Do I need a cookie banner if I only use "essential" cookies?
URL: https://veracly.app/blog/essential-cookies-no-banner
Published: 2026-05-12

Cookies
# Do I need a cookie banner if I only use "essential" cookies?
You can skip the cookie banner if you only use essential cookies. The catch: "essential" excludes almost every cookie most websites actually use, including most analytics tools that market themselves as "privacy-friendly."
By Veracly Compliance Team · 2026-05-12· 5 min read
The honest answer to “can I skip the banner?” is “yes, if you only use cookies that are strictly necessary for what the user asked for.” The unhonest version, sold by some consent-management vendors, treats the exception as a marketing claim. The real list of strictly-necessary cookies is short, and most SMB sites set at least one cookie that breaks the exemption.
## What qualifies as strictly necessary
ePrivacy 5(3) exempts storage that is “strictly necessary for the provision of an information society service explicitly requested by the subscriber or user.” The interpretation people usually reach for here, the EDPB’s Guidelines 02/2023, is the wrong instrument: those guidelines address the scope of Article 5(3), what counts as storage or access in the first place, and deliberately do not interpret the strictly-necessary exemption. The working list still traces to WP29 Opinion 04/2012 (WP194), which goes through the cookie types that qualify. It is short:
- Session cookies for authentication. When a user is logged in, maintaining the session is necessary to deliver the requested service.
- CSRF protection tokens. Anti-forgery tokens on form submissions.
- Load balancer routing. Sticky-session cookies that ensure the user’s requests reach the same backend during a session.
- Shopping cart state. A cart cookie persisting cart contents between page loads on a checkout flow the user initiated.
- Security cookies that detect attacks on a service the user requested. Cloudflare’s bot management cookie, Akamai’s session-based fraud-detection cookies in narrow contexts.
- Explicit user-preference cookies. A user clicks “dark mode,” the site sets a preference cookie to remember it next visit. The storage is necessary because the user explicitly asked for the customization.
## What does not qualify
- Analytics, even “privacy-friendly” ones. GA4, Matomo, Plausible, Fathom, Mixpanel, Amplitude. Helpful to you, not necessary for the user.
- Performance cookies that A/B test or personalize. Even if the personalization is intended to benefit the user, the storage exceeds “strictly necessary”, the user can be served the page without it.
- Default theme or default language cookies set without user action. Setting a language preference based on the user’s Accept-Language header is functionality; persisting that choice as a cookie before the user has interacted is storage that exceeds necessity.
- Security cookies where there is nothing much to secure. This is a matter of degree, not a clean line, and the exempt list above is the general case: bot management protecting a service the user is actively using is normally fine. The harder case is the same cookie applied blanket-wide to purely static marketing pages with no form, no login and no transaction. Some authorities would still accept it as protecting the site’s availability; the conservative reading is that the necessity argument weakens as the thing being protected disappears. If you rely on it, be able to name the attack it prevents on that page.
- Identifiers whose purpose is to follow the user across sites. Third-party advertising and analytics identifiers, and any first-party cookie set so that another party can read it. Note the distinction carefully, because a domain attribute on its own proves nothing: a sticky-session or single-sign-on cookie set at .example.com so your own subdomains can read it is still strictly necessary, exactly as the exempt list above says. What breaks the exemption is the cross-site purpose, not the presence of a leading dot.
- Anything from a third-party ad, social, or analytics vendor. The EDPB has explicitly rejected the “legitimate interest” argument for tracking storage. Strictly necessary excludes anything serving a third party.
## The narrow path that actually works
A site that legitimately runs banner-free is uncommon but exists. Typical patterns:
- Pure logged-in SaaS dashboards. A signed-in user’s authenticated session and CSRF protection only. No analytics on the dashboard, or analytics on a separate marketing site that does run a banner.
- Static informational sites. A small business homepage with no forms, no analytics, no third-party widgets, hosted on Cloudflare with bot management disabled on the static pages. Possible but increasingly rare.
- Analytics that writes nothing to the device. Vercel Web Analytics, Plausible in its cookieless mode, Cabin. Where a tool genuinely stores nothing on and reads nothing from terminal equipment, Article 5(3) is not engaged at all, though the GDPR still governs whatever data results. The condition is that nothing else on the site writes either. In France there is a second route to the same outcome, CNIL’s audience-measurement exemption, which can cover correctly configured tools that do use storage. Everywhere else, treat a vendor’s cookieless claim as something to confirm in DevTools rather than accept from a marketing page.
## The audit question
Before claiming the essential-only exemption, run a fresh cookie inventory. Open DevTools, load your site fresh, check the Application tab for every cookie set on first load, every localStorage entry, every IndexedDB key. Cross-reference each against the strictly-necessary list above. If even one entry on your site falls outside the list, you are subject to ePrivacy 5(3) consent.
A free Veracly scan covers one page , and on that single page we routinely turn up storage on sites that describe themselves as “essential only.” The usual culprits: a third-party widget (Calendly, a chat box), an embed (YouTube, Vimeo), a CDN cookie applied more broadly than anyone intended. Note what one page implies, though: the analytics script somebody left on a subpage after an experiment is precisely the thing a one-page scan will not see. That is an argument for walking the rest of the site yourself, not for assuming the rest is clean.
## Veracly’s position
Veracly does not enforce a banner where none is required, and it does not assume an essential-only exemption without evidence either. What a scan returns is the cookies and storage keys observed on the pages it visited , before any consent gesture, with the entries that look non-essential called out against Article 5(3). Four things to hold it to:
- It is an observation, not an inventory. One page on a free scan, up to your plan’s page cap otherwise, and only what actually loaded during that visit. Storage is recorded as key and database names, never values.
- Third-party requests only. Anything served from your own hostname, including self-hosted Matomo or a server-side tag endpoint on your own subdomain, is invisible to the scan by design.
- The strictly-necessary classification is a name-pattern heuristic , not a vendor database. It recognises the common session, CSRF and CDN cookie shapes. A genuinely essential cookie with an unusual name can be flagged, and a tracker with an innocuous name can slip past. Read the output as a shortlist to check, not a verdict to file.
- Free scans show samples, not the full set. Three cookie samples, three request URLs, three rendered priorities — and those three do carry a written explanation, as does the executive summary. What a free scan has none of is the copy-paste remediation and the evidence screenshots.
The site operator decides whether to remove the offending storage or to add a banner. We would rather hand you a short, honest list you can verify in DevTools than a confident one you cannot.
See also: GDPR vs ePrivacy: which one governs cookies? · Cookies, localStorage, IndexedDB: which require consent?
## Common questions
Can I really skip the cookie banner with essential-only cookies? +
Yes, under ePrivacy 5(3) the exception applies to storage that is strictly necessary for a service the user requested. No consent required, no banner required. The condition is that every cookie you set must individually qualify as strictly necessary, a single non-essential cookie breaks the exemption for the whole site.
Is Google Analytics 4 essential? +
No. Analytics is helpful to the site operator, not strictly necessary for the service the user requested, so as a general rule it needs consent. One jurisdiction-specific exception matters a great deal if you are in it: CNIL operates an audience-measurement exemption in France, covering tools configured to produce anonymous aggregate statistics only, with no cross-site tracking, no onward data sharing, and a limited identifier lifetime. CNIL publishes configuration guidance naming Matomo among the tools that can be set up to qualify. That exemption is French. Do not assume it travels to Germany, Italy or Spain, and do not assume a default install of Matomo, Plausible or Fathom qualifies, because out of the box it generally does not.
Are CDN security cookies essential? +
Many are, but check the names against your provider before relying on it. Cloudflare’s __cf_bm and Akamai’s ak_bmsc support bot detection on a service the user is actively requesting and typically qualify under 5(3). Fastly is worth a flag: "fastly_cdn" circulates widely in cookie lists and is not a real Fastly cookie, so a list containing it is a list nobody checked. Fastly’s client-hint cookies are the _fs_ch_ family. Verify each cookie against your CDN’s own documentation rather than a blog table, and note that several CDNs also ship analytics features that do not qualify.
What about cookies for accessibility preferences? +
Storing a user’s explicit accessibility preference (font size, high contrast) is generally accepted as strictly necessary because the user explicitly requested the customization. A cookie that sets a default theme without user action does not qualify.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Cookies
### What is a cookie banner audit? (2026 checklist)
A cookie banner audit checks design, defaults, dark patterns, and what loads before any consent gesture. The Accept and Reject paths themselves have to be walked by hand. Here is the 2026 checklist.
- Cookies
### Cookie consent in Australia: what the law actually requires
Australian businesses install consent banners because European advice tells them to. There is no Australian rule requiring one for ordinary analytics. But sensitive information is a real exception, and the Privacy Commissioner enforced it against tracking pixels in June 2026.
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.

---

## Veracly free scan vs. paid report: what is different, and when to upgrade
URL: https://veracly.app/blog/free-scan-vs-paid-report
Published: 2026-05-12

Multi-jurisdiction
# Veracly free scan vs. paid report: what is different, and when to upgrade
The free scan is not a teaser. It is a real audit of one page, one snapshot in time. Here is exactly what it tests, what it does not, and the signal that says it is time to upgrade.
By Veracly Compliance Team · 2026-05-12· 6 min read
The free Veracly scan is not a teaser. It runs the same scanner code against the same rule set, scores it with the same formula, and signs the result with the same Ed25519 key. The AI translator writes the executive summary and the plain-English text on the priorities you can see. The differences are scope, cadence, and detail, not honesty.
## What the free scan covers
- One URL, the one you submitted. We render it, run axe-core, capture cookies and the network waterfall on first load.
- Analysis against the rule packs your declared market triggers — an EU market brings the EAA and GDPR/ePrivacy, the UK the Equality Act, the US the ADA, Canada the AODA. You pick that market on the form; we do not guess it.
- A summary report delivered by email within about five minutes. It runs to roughly eight to ten pages: cover, executive summary, per-jurisdiction scorecard, the top three priorities, methodology, glossary, and the legal disclaimer with the integrity block.
- The top three priority issues with plain-English explanation.
- An audit-ledger anchor. The free PDF is signed with the same key and verifiable at veracly.app/verify/<scan-id> by the same mechanic as a paid one, on a shorter clock: free anchors are retired 60 days after signing, paid anchors carry no automatic expiry. Every PDF prints its own verify window in the integrity block, and it says 30 days from issue. When a free anchor retires, the stored fingerprint is erased with it, so verification is genuinely over at that point rather than moving to a slower channel. If the report needs to convince somebody, have them verify it inside the window.
## What the free scan does not cover
- Only the URL submitted. We do not crawl your sitemap, follow internal links, or scan account-gated pages.
- Only one snapshot in time. There is no re-scan, no score-drop alert, no weekly cadence.
- The summary lists three priorities; the inventory of remaining issues is omitted.
- Copy-paste developer fixes are not in the free report. The summary says what is wrong; the paid report adds how to fix it .
- Evidence screenshots are not captured on free scans, so the priority rows carry no visual evidence.
- The PDF and its record are deleted 60 days after generation, and the verify anchor retires on the same window. A paid report is kept for the life of the scan record, and its verify anchor has no expiry at all.
- White-label PDF branding is a paid-tier feature (Agency).
One thing that is not on that list, because we have claimed it in the past and it was wrong: language. A free PDF renders in whichever of the seven supported locales you selected on the form, not English. The only English-pinned element is the upgrade page at the back.
## Tier comparison
For an SMB on a single-site, single-jurisdiction footprint, Starter (€79 / £69 / $89 per month) covers one site at fifty pages, monthly scanning only, one visitor country, full reports. Growth (€199) adds three sites at two-fifty pages each, weekly or monthly cadence, up to three visitor countries, plus Slack alongside the email alerts. Pro (€399) covers ten sites at five hundred pages each, daily, weekly, or monthly cadence, and unlimited visitor countries. Agency (€599) is the white-label tier: twenty-five sites at a thousand pages each, same cadence options as Pro. Every paid tier can also trigger a scan on demand from the site detail page, on any cadence.
All four tiers are billed monthly or annual; annual is roughly seventeen percent off. Annual customers also get the locked-in price for the first year if we raise rack rates later.
## The four signals that say “upgrade now”
We have watched the conversion data on the design partners who upgraded. The pattern is consistent, one of four triggers:
- Your free scan returned a critical finding. A pre-consent pixel, a missing form label, a banner that fails parity. You need the full report’s fix snippets to actually ship the fix.
- You operate more than one page that matters. A free scan only tests the URL you give it. If your checkout, your account login, or your booking flow lives at different URLs, the snapshot misses them. The smallest site we have seen that meaningfully benefits from a multi-page scan has six pages; most have thirty to fifty.
- Your site changes more than monthly. A new marketing experiment, a new tracking pixel, a new third-party widget, every change is a chance to introduce a regression. The pre-consent firing issue is overwhelmingly introduced by a marketing team adding a pixel between audits, not by the original implementation.
- An auditor, regulator, or large customer has asked. A signed, timestamped, multi-jurisdiction PDF that the recipient can verify independently is the format procurement teams expect. The free summary is signed and verifiable, but it covers one page of your site, carries no per-jurisdiction detail pages, no remediation appendix, and no issue inventory, and both the file and its verify anchor are gone 60 days after issue. That is not the artifact you want on file with a regulator or a procurement team.
## The signals that say “keep using the free scan”
Yes, we keep this list too. The free scan is the right tool when:
- You run a single-page personal site that does not collect data.
- You are a developer triaging one specific page before a launch.
- You audit other people’s sites as a one-off, not your own continuously.
- You are a hobbyist or student learning what compliance scanners look at.
We do not believe in selling continuous monitoring to people who do not need continuous monitoring. Honest auditor, not magic widget, the same line applies to our pricing as to our reports.
## How to evaluate before you pay
There is no trial tier, and we would rather say so than imply one. What there is: the single-page scan, free and account-free, running the same analyzers and the same scoring formula as a paid scan, against whichever rule packs your jurisdiction triggers. It is the paid engine on one page, not a weaker engine on all of them. One real difference: a free scan covers the single primary market you pick on the form, where a paid plan lets you declare up to three (Growth) or all of them (Pro), so a paid scan of the same URL can evaluate more packs than the free one did.
So the honest evaluation path is: scan your most complex page — a checkout, a booking flow, something with a cookie banner and a form — rather than your homepage. If the findings on that one page are the kind of thing you would act on, the multi-page version will find more of them. If they are not, a paid plan will not change that, and you should not buy one.
See also: Free website compliance scan: what to look for · Reading your first Veracly report
## Common questions
Is the free scan limited on purpose? +
Yes, and the limits are scope limits rather than quality limits. It is single-page and single-shot, capped at one scan per email address per rolling 7 days, but the crawler, the analyzers, the rule packs, the severity mapping, the scoring formula, and the Ed25519 signing are the same code path as the paid tier. No analyzer is tier-gated. The free PDF renders in whichever of the seven supported languages you asked for, same as a paid one.
Do I lose access to my free scan if I upgrade? +
A free scan is not attached to an account, so there is nothing to carry across. Free scans run under a separate holding organization and there is no claim path that moves one into a paid workspace. They are also not kept forever: the PDF and its report record are deleted 60 days after the report is generated, and the audit-ledger anchor is retired on the same window. Download the PDF and keep your own copy. Upgrading gives you continuous scanning, multi-page crawls, and the full report set from the first paid scan onward.
Is there a free trial of the paid tier? +
No. Checkout collects a payment method and billing starts when you subscribe. What is free is the single-page scan, which needs no account at all. There is no way to preview a multi-page report before subscribing — the free scan is capped at one page. What you can do is run it against your most complex page; the sections below set out exactly what it covers and what it leaves out.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- Multi-jurisdiction
### Multi-jurisdiction website compliance: one site, many laws
EU, UK, US, and Canadian visitors trigger different laws. Here is the practical playbook for satisfying GDPR, EAA, ADA, UK Equality Act, and AODA with one programme.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## GDPR vs ePrivacy: which one actually governs cookies?
URL: https://veracly.app/blog/gdpr-vs-eprivacy-cookies
Published: 2026-05-12

Cookies
# GDPR vs ePrivacy: which one actually governs cookies?
GDPR did not invent the cookie banner. ePrivacy did, nine years earlier. Understanding which framework requires what is the difference between a defensible CMP setup and a banner that fails on first inspection.
By Veracly Compliance Team · 2026-05-12· 6 min read
A reader of European compliance content could be forgiven for thinking GDPR invented the cookie banner. It did not. The consent requirement arrived with the 2009 amendment to the ePrivacy Directive, nine years before the GDPR became applicable in May 2018. It came from a different framework, and it survives if the GDPR is ever repealed. Understanding which regulation does what is the foundation of a defensible cookie setup.
## The two frameworks
ePrivacy Directive 2002/58/EC , amended in 2009 (Directive 2009/136/EC). Article 5(3), the so-called “cookie law”, requires informed consent before any storage of information on, or access to information already stored on, a user’s terminal equipment. There are two exemptions, not one: storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, and storage strictly necessary for a service the user has explicitly requested. The transmission limb is the one almost every article forgets; it is also the narrower of the two in practice.
GDPR (Regulation (EU) 2016/679) , in force since May 2018. Article 4(11) defines consent stringently. Article 6 lists the six lawful bases for processing personal data. Article 7 sets the conditions for consent. The data subject rights (Articles 15 to 22) apply to any personal data, including cookie-derived.
The two work in series, not in parallel. ePrivacy 5(3) governs the moment data enters the user’s device or is accessed from it. GDPR governs what happens to the data after collection. A site needs both lawful: a valid ePrivacy 5(3) consent for the storage event, and a valid GDPR Article 6 basis for the processing.
## The 5(3) trigger
Article 5(3) fires on any “storing of information” or “gaining of access to information already stored” on terminal equipment. This is broader than cookies:
- HTTP cookies (first-party and third-party)
- localStorage and sessionStorage
- IndexedDB
- Service Worker caches
- Pixel and beacon requests that write client identifiers
- Browser fingerprinting techniques that read device characteristics
The German DSK guidance (December 2021) and the EDPB Guidelines 02/2023 on the technical scope of Article 5(3) both confirm the rule is technology-neutral. One caveat worth having, because plenty of articles get it wrong: the Guidelines do not contain a list of APIs. The words “IndexedDB”, “sessionStorage”, “Service Worker” and “Cache API” appear nowhere in the adopted text. What the Guidelines supply is the test — built on the statutory terms information , terminal equipment , and gaining access — and that test is what catches all of them. A site that swaps cookies for localStorage does not escape consent.
## The “strictly necessary” exception
The second of the two exemptions is the one CMPs actually invoke: 5(3) allows storage without consent when it is “strictly necessary for the provision of an information society service explicitly requested by the subscriber or user.” It is narrower than most CMPs label it:
- Yes: session cookies that track a logged-in user’s authenticated state. CSRF tokens. Load balancer session affinity. Shopping cart state during a checkout.
- Yes (qualified): security cookies for fraud prevention on a payment flow, EDPB has accepted these as strictly necessary in narrow contexts.
- Usually no, with one real exception: analytics. The default position is the right one to plan around — analytics serves the site operator, not the user who asked for the page, so it needs consent. But “any analytics, anywhere” overstates the law, and the overstatement is not the EDPB’s. WP29 Opinion 04/2012 (WP194) recommended a first-party analytics exemption, and the CNIL actually operates one: audience measurement strictly limited to producing anonymous statistics for the site itself, first-party, no cross-site tracking, no data sharing and no other use of the data, is exempt from consent in France, and the CNIL publishes configuration guides naming specific tools including Matomo. Two things to hold onto: this is a national position, not an EU-wide one, and the configuration conditions are strict enough that most default installs fail them. Check your own jurisdiction before relying on it.
- No: “user preferences” cookies that persist beyond the session. Language preference, theme, these enhance the service, they are not strictly necessary.
- No: any third-party advertising, retargeting, social, or fingerprinting cookie.
## Where the conflation goes wrong
Two common failure modes in cookie-consent writing:
- “GDPR requires a cookie banner.” No, ePrivacy 5(3) does. GDPR tightens the definition of consent the banner relies on.
- “If we have legitimate interest, we do not need consent.” GDPR Article 6(1)(f) (legitimate interest) is a lawful basis for processing personal data. It does not override ePrivacy 5(3) consent for the storage event. The EDPB has explicitly rejected the “legitimate interest for cookie storage” argument multiple times.
A third, more subtle one: the assumption that the EU-US Data Privacy Framework (DPF, adequacy decision 10 July 2023) fixed cookie compliance. It did not. The DPF addresses GDPR Chapter V (international transfers). ePrivacy 5(3) consent is unaffected. A site that consent-gates GA4 properly is fine under both frameworks; a site that fires GA4 pre-consent is in breach of ePrivacy regardless of whether the resulting data ends up in a DPF-certified Google data center.
## The ePrivacy Regulation that never arrived, and now never will
The European Commission proposed a new ePrivacy Regulation in January 2017, intended to replace the 2002 Directive and harmonise cookie rules across member states. It never cleared the Council. The Commission announced its intention to withdraw the proposal on 11 February 2025 , formally adopted the withdrawal on 16 July 2025 , and the withdrawal was published in the Official Journal on 6 October 2025 . No successor proposal exists.
That settles a question a lot of compliance planning had been leaving open. The 2002 Directive as amended in 2009 is the law, indefinitely, and it is a Directive — so Article 5(3) reaches you through a national statute, not a single EU text: §25 TDDDG in Germany, art. 82 of the Loi Informatique et Libertés in France, art. 122 Codice Privacy in Italy, art. 11.7a Telecommunicatiewet in the Netherlands, art. 397 PKE in Poland. The detail-level divergence between them is permanent rather than transitional. A multi-country deployment has to check each transposition, and anyone deferring a decision until “ePrivacy lands” is waiting for a train that was cancelled.
## How Veracly applies the two frameworks
The cookie-audit module lives on the ePrivacy 5(3) side, and that is where it is strongest. It records the cookies, Web Storage and IndexedDB entries written before any banner interaction, the third-party requests that fire pre-consent, whether a banner exists at all, and whether a reject control is present alongside accept. Every such finding ships with a DevTools recipe so you can reproduce it yourself rather than take our word for it.
The GDPR side is much thinner than the marketing for this class of tool usually admits. Veracly does not check Article 13/14 disclosure completeness. It checks whether a privacy policy is reachable ; it does not read it. No content analysis exists anywhere in the product — nothing verifies that a controller, a legal basis, a retention period, a DSAR contact, a DPO or a transfer mechanism is disclosed. Acceptance is a keyword test against a 2xx page on your own host, which also means a policy hosted on your CMP vendor’s domain is not seen at all. Article 13/14 completeness is a document review and it needs a person.
What the reports do get right is the citation: each finding is flagged under the framework it actually engages, so a regulator follow-up gets the correct legal reference rather than a generic “cookie issue.”
See also: Cookies, localStorage, IndexedDB: which require consent? · Do I need a banner if I only use essential cookies?
## Common questions
Which law actually requires the cookie banner? +
ePrivacy Article 5(3), originally from the 2002 ePrivacy Directive and amended in 2009. It requires consent for any non-essential storage on a user device, including cookies, localStorage, and IndexedDB. GDPR does not require a cookie banner; it tightens the definition of consent that ePrivacy already required.
What does GDPR add for cookies? +
Three things. First, a stricter consent standard, Article 4(11) defines consent as freely given, specific, informed, and unambiguous. Second, the data subject rights (access, erasure, portability) that apply to data collected via cookies. Third, the lawful-basis framework in Article 6 that governs the processing once data is collected.
Why does the distinction matter in practice? +
Because the GDPR adequacy regime (DPF, SCCs, Schrems II) addresses Chapter V transfers, it does not displace ePrivacy 5(3). A site that has the perfect GDPR posture but fires a tracking pixel pre-consent has not complied with ePrivacy. The fines are separate.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Cookies
### What is a cookie banner audit? (2026 checklist)
A cookie banner audit checks design, defaults, dark patterns, and what loads before any consent gesture. The Accept and Reject paths themselves have to be walked by hand. Here is the 2026 checklist.
- Cookies
### Cookie consent in Australia: what the law actually requires
Australian businesses install consent banners because European advice tells them to. There is no Australian rule requiring one for ordinary analytics. But sensitive information is a real exception, and the Privacy Commissioner enforced it against tracking pixels in June 2026.
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.

---

## Do I need to honor the Global Privacy Control (GPC) signal in the EU?
URL: https://veracly.app/blog/global-privacy-control-eu
Published: 2026-05-12

GDPR
# Do I need to honor the Global Privacy Control (GPC) signal in the EU?
GPC is a browser signal that tells sites "do not sell or share my data." California treats it as a binding opt-out. The EU has not legislated it, and the draft ePrivacy Regulation that would have was withdrawn in 2025. Honoring GPC in the EU is optional, and defensible on Article 21(5) GDPR alone.
By Veracly Compliance Team · 2026-05-12· 6 min read
Global Privacy Control is a browser signal, an HTTP header and a JavaScript property, that lets a user broadcast a privacy preference once and have every site they visit respect it without per-site banner clicks. Sec-GPC: 1 on the request header means “treat me as having opted out of any sale, sharing, or tracking that my jurisdiction’s law lets me opt out of.”
In California, Colorado, Connecticut, and Texas, GPC is legally binding under each state’s consumer privacy statute. In the EU, GPC is not codified. The question of whether SMB sites should honor it has a defensible answer that is not “wait for the EDPB to require it.”
## Where GPC is binding today
- California CCPA / CPRA. California Civil Code §1798.135(b)(1) lets a business meet its opt-out duty by honoring an opt-out preference signal, and 11 CCR §7025(b)–(c) makes processing that signal mandatory and sets out how. Rulemaking sits with the California Privacy Protection Agency , which took it over from the Attorney General.
- Colorado CPA. Colorado regulations (4 CCR 904-3 §5.04) require honoring “universal opt-out mechanisms”; GPC qualifies as of January 2024.
- Connecticut CTDPA. Similar universal-opt-out provision; GPC named by AG guidance.
- Texas TDPSA. The statute took general effect on 1 July 2024, but the duty to recognise a universal opt-out mechanism is separately dated: §541.055(e) applies it from 1 January 2025 .
- Several other US states (Delaware, Maryland, Oregon, Minnesota, New Jersey) have adopted similar provisions in 2024 to 2025.
## Where GPC sits in EU law in 2026
GDPR Article 21. Article 21(2) grants an unconditional right to object to processing for direct marketing. Article 21(5) then adds the sentence that actually matters here: in the context of information-society services, the data subject “may exercise his or her right to object by automated means using technical specifications.” That is a description of a browser signal, written into the Regulation in 2016. It is the strongest hook GPC has in EU law — and it is a hook, not a mandate. Nothing designates GPC as the specification, and the EDPB has published no opinion, guideline or work-programme item on it. Claims that the EDPB endorses GPC are extrapolation, and you will find several of them.
The nearest thing to a ruling. Landgericht Berlin, judgment of 24 August 2023 (Az. 16 O 420/19) , in proceedings brought by the vzbv against LinkedIn, held that a Do Not Track signal amounted to an effective objection and that telling users the signal had no effect was unlawful. Read it as the direction of travel, not as settled law: it is first instance, it is not final, and it is on appeal to the Kammergericht.
The ePrivacy Regulation is not coming. For eight years the answer to “when will the EU codify a universal signal?” was Article 10 of the draft ePrivacy Regulation, which would have obliged browsers to offer a consent setting and sites to respect it. That vehicle is dead. The Commission announced its intention to withdraw the proposal on 11 February 2025 , formally adopted the withdrawal on 16 July 2025 , and it was published in the Official Journal on 6 October 2025 . No successor instrument is on the table.
That rearranges the argument in this post rather than defeating it. “Honor it early and avoid a retroactive scramble” was never a great reason, and it is now an empty one: there is no scramble scheduled. What is left is the case on the merits — Article 21(5), an objection right you already owe and have to operationalise somehow, and the fact that running one opt-out path across your EU and US visitors is cheaper than running two. If those reasons do not move you, no legislative deadline is going to.
What GPC cannot do. GPC is an opt-out signal; ePrivacy Art. 5(3) consent is opt-in. A Sec-GPC header is not consent, and its absence is emphatically not consent either — you still need a banner and an affirmative act before you write a non-essential cookie. GPC operates on the objection side of the GDPR and on processing you run under legitimate interest. Treating it as a substitute for a consent mechanism is the one implementation mistake worth naming outright.
## The right way to honor GPC in the EU
Honoring GPC in the EU is a layered concept because GDPR consent and ePrivacy consent are opt-in. GPC says “I opt out”, useful for processing the site does under legitimate interest, less useful for processing that already requires consent. The clean integration:
- On every request, check the Sec-GPC header. If 1, treat the user as having objected to processing under Article 21 and opted out of any sale or sharing that would otherwise be permissible under legitimate interest.
- On the client, check navigator.globalPrivacyControl. Use this as a fallback for SPA-style navigations or when the cookie banner hydrates before a server round-trip.
- Suppress the cookie banner. A GPC-signalling user has expressed a preference for privacy; presenting a banner asking them to accept tracking is friction without value. Persist the rejection in a first-party cookie so future visits stay banner-free.
- Do not load non-essential trackers, ever. The GPC user has opted out of the universe of tracking that requires their consent. Loading GA4 / Meta Pixel / LinkedIn Insight on a GPC visit is inconsistent with the opt-out, regardless of whether the user clicked anything.
- Honor the user’s right to revoke. A user who clears the consent cookie and explicitly accepts tracking after a GPC-rejection should be respected; the GPC signal expresses a preference, not an unmovable absolute.
## Implementation, briefly
On a Next.js application, the cleanest pattern is to detect Sec-GPC in middleware and stamp a first-party cookie on the response. The client then reads that cookie via React context and never mounts the consent banner. The same context controls whether non-essential analytics modules are mounted at all.
Veracly’s own marketing site implements this pattern. The middleware at apps/web/src/middleware.ts writes veracly_gpc=1 when it sees Sec-GPC: 1. The ConsentProvider reads that cookie before the banner mounts. The cookie banner never appears for a GPC-signalling visitor.
## What about Do Not Track?
Do Not Track (DNT) was the predecessor to GPC. It was widely ignored by sites and eventually deprecated by browser vendors as ineffective. GPC succeeded where DNT failed because it acquired the one thing DNT never had: statutory backing. That was not there at launch — GPC shipped in 2020 with no state obliging anyone to honour it, and California’s regulations came first. Roughly a dozen states now require honouring a universal opt-out signal, and a single jurisdiction with enforcement behind it creates the network effect DNT never achieved.
Sites that already implemented DNT respect probably still have the code path. Migrating it to honor GPC instead is straightforward: read Sec-GPC where you previously read DNT, treat truthy as opt-out.
## Does a Veracly scan check this? No.
We are correcting this section in place rather than quietly deleting it. An earlier version claimed the scanner “runs every page twice, once with a default browser profile and once with Sec-GPC: 1 set,” and that sites honoring GPC “see their compliance score improve.” Neither was true. There is no GPC check in the product: the scanner sends no Sec-GPC header, loads each page once, and GPC is not a violation type, so it cannot move a compliance score in either direction. The claim described a feature nobody had built.
Doing it properly would mean a second, differently-configured pass over every page plus a behavioural diff between the two runs — real work, not yet done. If we ship it, this section gets rewritten again. Until then, test it yourself in about two minutes: turn GPC on (Brave and DuckDuckGo send it by default; Firefox has it as an opt-in setting), open DevTools, filter the Network panel by your analytics or pixel domain, and compare what fires against the same page loaded in a browser without the signal.
What a scan does observe is the pre-consent state — which cookies, storage entries and third-party trackers appear before any banner interaction at all. That is a different question from GPC, and a useful one, but we are not going to sell it as a GPC test. Run a scan .
See also: GDPR vs ePrivacy: which one governs cookies? · What reject-all has to do under GDPR
## Common questions
Is honoring GPC required under GDPR? +
Not by any enforceable provision today. The closest textual hook is Article 21(5) GDPR, which says that in the context of information-society services a data subject may exercise the right to object "by automated means using technical specifications" — a description of exactly what GPC is. But nothing designates GPC as that specification, no member state has made it binding the way California has under §1798.135(b)(1) of the CCPA, and the EDPB has published no opinion, guideline or work-programme item on GPC. Earlier versions of this post said otherwise; that was extrapolation and we have removed it.
Why honor it then? +
Three reasons, none of which is "it will be mandatory soon" — the draft ePrivacy Regulation that would have made it mandatory was withdrawn in 2025 and has no successor. First, Article 21(5) GDPR already contemplates objections made by automated technical means, so honoring GPC is a defensible way to discharge an obligation you have anyway. Second, the signal exists because users want their privacy preferences automated, and ignoring a stated preference is a bad look in front of a regulator handling a complaint. Third, if you already honor GPC for US visitors under CCPA, running one opt-out path for everyone is simpler than running two.
What signal should I actually look for? +
Two signals. The Sec-GPC HTTP header (sent on every request from a browser with GPC enabled) is the server-side check. The navigator.globalPrivacyControl JavaScript property is the client-side check. Do not assume broad support behind either: Brave and DuckDuckGo send GPC by default and Firefox offers it as an opt-in setting, while Chrome, Edge and Safari have never shipped it at all. Whichever signal you get, present and truthy is authoritative.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.
- GDPR
### Is Google Analytics 4 illegal in Europe? The actual answer in 2026
GA4 is not strictly illegal in the EU, but it is also not a drop-in default. Two distinct questions decide its fate: did you get consent, and does the EU-US Data Privacy Framework still hold?
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.

---

## Is Google Analytics 4 illegal in Europe? The actual answer in 2026
URL: https://veracly.app/blog/is-ga4-illegal-in-europe
Published: 2026-05-12

GDPR
# Is Google Analytics 4 illegal in Europe? The actual answer in 2026
GA4 is not strictly illegal in the EU, but it is also not a drop-in default. Two distinct questions decide its fate: did you get consent, and does the EU-US Data Privacy Framework still hold?
By Veracly Compliance Team · 2026-05-12· 8 min read
Asking whether GA4 is illegal in Europe is asking three questions in one. The answers differ depending on which one you mean. Compliance teams that conflate them either over-react (rip out GA4, lose all analytics signal) or under-react (assume DPF fixed everything, ship pre-consent firing). Neither is right in 2026.
## The three questions
- Is the transfer of EU personal data to Google’s US servers lawful under Chapter V GDPR? This is the Schrems II question.
- Does setting a GA4 cookie or storing a client ID require consent under ePrivacy? This is the cookie banner question.
- Does GA4 process personal data lawfully under Articles 5 and 6 GDPR? This is the legal-basis question.
All three must be answered yes for GA4 to be deployed compliantly. Most coverage collapses them into one.
## Question 1, Schrems II and the DPF
Schrems II (C-311/18, July 2020) invalidated Privacy Shield as a basis for EU-US transfers, finding US surveillance law incompatible with GDPR adequacy. From 2020 to 2023 the only lawful basis was Standard Contractual Clauses plus “supplementary measures”, a legal posture the EDPB explicitly characterized as difficult to satisfy for cloud services.
That changed on 10 July 2023 when the Commission adopted an adequacy decision for the EU-US Data Privacy Framework. Google self-certified under the DPF. As a matter of black-letter law in 2026, transfers to Google for GA4 purposes are lawful provided Google’s DPF certification is current.
The challenge to the DPF has already happened. It was not brought by noyb. MEP Philippe Latombe asked the General Court to annul the adequacy decision, and on 3 September 2025 the Court dismissed the action (T-553/23), holding among other things that the US Data Protection Review Court is sufficiently independent. An appeal was lodged on 31 October 2025 and is pending before the Court of Justice as C-703/25 P. So the DPF stands today, but it stands subject to appeal, and its legal architecture is close enough to Privacy Shield that an eventual invalidation would put GA4 back in the pre-2023 state: transfer-unlawful without supplementary measures. Treat the DPF as current law and keep a documented fallback; do not treat it as settled.
## Question 2, ePrivacy consent
ePrivacy Article 5(3) requires informed consent for “the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user.” This applies to all non-essential storage, cookies, localStorage, IndexedDB, fingerprinting techniques.
GA4 sets first-party cookies and stores a client ID. It is non-essential by every reasonable definition. Article 5(3) consent is required before the storage occurs.
The DPF does not change this. The DPF addresses GDPR Chapter V (transfers); ePrivacy 5(3) is a separate framework whose national-level transpositions all require pre-collection consent. A site that fires GA4 on first page load before the banner is clicked is in breach regardless of where the data ends up.
## Question 3, Lawful basis under Article 6
Once you have consent (Question 2 satisfied) and a lawful transfer mechanism (Question 1 satisfied), the GA4 processing itself needs an Article 6 lawful basis. For consent-gated analytics this is Article 6(1)(a), the same consent. Legitimate interest (6(1)(f)) cannot be the basis because the EDPB has repeatedly held that tracking technologies requiring ePrivacy consent cannot then be processed under a different Article 6 basis post-collection.
## What this means in practice
- You can use GA4 in the EU. Provided you obtain ePrivacy consent before any GA4 cookie is set or any client ID stored, the deployment is lawful under the current DPF.
- You must gate GA4 behind consent. No first-load firing, no “legitimate interest” arguments, no “but the data is anonymous.” Pre-consent firing is the single most common GA4 violation Veracly sees on SMB sites.
- Consent Mode v2 is not a workaround. Google’s Consent Mode v2 sends modeled aggregates when consent is denied, but it still requires consent to set any cookie. The marketing pitch can be misleading; the actual mechanism is consent-gated.
- Plan a contingency. The adequacy decision survived first instance and is under appeal (C-703/25 P). Sites with significant EU traffic should have a documented analytics fallback (Matomo, Plausible, server-side first-party analytics) that does not depend on US transfers.
## The non-Google alternatives
Two categories of GA4 alternative reduce the legal-basis stack to just ePrivacy consent:
- EU-hosted analytics. Matomo (Cloud EU), Plausible (self-hosted or Plausible Cloud, EU servers). Both eliminate the transfer question. Both still require consent unless deployed in cookie-less mode.
- Cookie-less analytics. Plausible default, Cabin, Vercel Web Analytics, Fathom. These do not set cookies and use techniques (daily-rotated hashed IPs, no cross-session identifiers) designed to stay outside Article 5(3). Be careful how far you push that. The only regulator that has published a conditional exemption is the CNIL (délibérations 2020-091 and 2020-092), and it is conditional: strictly limited purpose, no cross-site tracking, aggregate output only. § 25(2) TDDDG contains no analytics exemption at all, and EDPB Guidelines 2/2023 confirm that Article 5(3) is technology-neutral, so “cookie-less” does not by itself put a tool outside its scope. Verify the specific tool in the specific member state before assuming.
## Veracly’s rule entry for GA4
Veracly matches GA4 on its firing endpoints, not on the tag that loads it: google-analytics.com/g/collect, google-analytics.com/mp/collect, analytics.google.com/g/collect, and the region1 / region2.google-analytics.com regional hosts. A pre-consent hit against any of those is a pre-consent-tracker finding, graded critical under the GDPR rule pack, carrying a Schrems II jurisdictional note.
googletagmanager.com/gtag/js is deliberately not on that list, and the reason is a mistake we made and had to fix. While the loader was matched as GA4, every site whose Consent Mode v2 was correctly deferring /collect was still being reported as “GA4 firing pre-consent”. Loader scripts now produce a separate, softer pre-consent-tracker-loaded finding graded high , which says only what was actually observed: the script arrived before consent, but no data hit was seen leaving the browser. The same split applies to the Meta Pixel (/tr is the firing endpoint; connect.facebook.net is the loader).
Two limits worth stating plainly. Veracly only sees what the browser sends to a third-party host, so server-side GA4 and first-party-proxied deployments — a Measurement Protocol call made from your own server, or a tagging server on your own domain — are invisible to the scan. An absent finding is not a clean bill of health. And the absence of a post-consent finding does not mean the engine judged your post-consent deployment lawful: Veracly never clicks your cookie banner, because clicking would itself be a consent gesture and would pollute the pre-consent reading. Everything the report says is about the state of the page before anyone has consented to anything.
See also: GDPR vs ePrivacy: which one actually governs cookies? · GDPR cookie audit explained
## Common questions
Did any DPA officially ban GA4? +
Several ruled Universal Analytics non-compliant: Austria (DSB, January 2022), France (CNIL, February 2022), Italy (Garante, June 2022), Denmark, Norway, Finland aligned. Those decisions applied to Universal Analytics specifically. GA4 has not received a comparable adequacy ruling but inherits the same Schrems II concerns until the legal basis is fully resolved.
Did the EU-US Data Privacy Framework fix the problem? +
Partly. The DPF (adequacy decision of 10 July 2023) restored a lawful mechanism for transferring personal data from the EU to certified US companies including Google. It addresses the Schrems II "no adequate transfer mechanism" finding. It does not address ePrivacy 5(3) consent obligations. It has already been challenged once: the General Court dismissed an annulment action against the adequacy decision on 3 September 2025 (T-553/23, Latombe v Commission), and an appeal is pending before the Court of Justice as C-703/25 P. The DPF stands today, but it stands subject to that appeal.
Do I need consent for GA4? +
Yes. GA4 sets first-party cookies and stores client identifiers in localStorage on first page load. ePrivacy 5(3) requires consent for any non-essential terminal-equipment storage. GA4 is non-essential.
What about GA4 server-side or consent-mode v2? +
Server-side GA4 (Google Tag Manager Server with EU regional containers) reduces but does not eliminate transfers. Consent Mode v2 sends modeled aggregate data when consent is denied, but still requires consent before any cookie is set. Neither is a turn-key "GA4 without consent" path.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.
- GDPR
### Do I need to honor the Global Privacy Control (GPC) signal in the EU?
GPC is a browser signal that tells sites "do not sell or share my data." California treats it as a binding opt-out. The EU has not legislated it, and the draft ePrivacy Regulation that would have was withdrawn in 2025. Honoring GPC in the EU is optional, and defensible on Article 21(5) GDPR alone.
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.

---

## How to read your first Veracly compliance report
URL: https://veracly.app/blog/reading-your-veracly-report
Published: 2026-05-12

Multi-jurisdiction
# How to read your first Veracly compliance report
Your first Veracly report is dense by design. Here is the section-by-section tour, the numbers that actually matter, and a triage plan for the first week.
By Veracly Compliance Team · 2026-05-12· 7 min read
Your first Veracly report is dense. The PDF is twelve to twenty pages, the dashboard has fewer pixels but more drill-down, and the cover page shows six numbers before you even get to the body. This article is the guided tour, what each section is for, which numbers matter, and how to get from “received” to “the top five fixes are filed in your tracker” in under thirty minutes.
One navigation note before the tour: the sections are not numbered. Each one carries a title and nothing else, so cite them by name when you forward the report or point somebody at a page. The headings below are the titles as they appear, in the order they appear.
## The cover
The headline is your overall score and a status pill (green/yellow/red). The mini-cards below show one number per jurisdiction that fired. Two things to read here:
- The status pill is the at-a-glance verdict. Green (85+) means your site is in good shape; yellow (60 to 84) means you have actionable findings but no single catastrophic one; red (under 60) means at least one critical issue you should file today.
- The jurisdiction strip tells you which laws actually apply to your real traffic mix. We do not score laws that do not apply, if you have zero EU visitors, GDPR does not appear here.
## Executive summary
One paragraph of natural-language summary, AI-drafted from data the rules engine has already finished producing: the verdicts, the scan statistics, and the top violation types. There is no review step after the drafting, and it would be dishonest to imply one, no human and no second engine pass reads that paragraph before it reaches you. What it does have is a deterministic floor: if the model is unreachable or errors, the report falls back to a templated summary built straight from the verdicts, so the section is never blank and never invented. The numbers in the stat cards beneath it come from the database, not from the model. Treat the prose as a readable gloss on those numbers and the numbers as the record.
The stat cards underneath translate the headline into traceable numbers: pages scanned, unique issues, jurisdictions evaluated, distinct critical findings. If something on the executive summary surprises you, the stats below tell you which page count is driving it.
## Per-jurisdiction scorecard
One card per applicable jurisdiction. Each shows a score, a violation count, the critical count, and a severity-distribution bar (critical / high / medium / low). Read the bar shape, not just the number, two sites with a 72 can have wildly different fix workloads if one has all-low and the other has two criticals.
For AODA you will see two numbers side-by-side: the strict 2.1-AA score (used for cross-jurisdiction parity with the other cards) and the legal-floor score against IASR §14’s 2.0-AA bar (which is Ontario’s actual statutory requirement). The 2.0 number is what an Ontario regulator would compare against in practice.
## Top priorities
This is where you start. Ten issues ranked by severity first, then by how many pages the issue affects, a critical that appears on every page outranks a critical on one page, which outranks any high. Each row has a one-paragraph plain-English explanation from the AI translator pass.
Those explanations are cached for 30 days, keyed to the violation type and the specific element sampled, so the same issue on the same element reads identically across two reports a fortnight apart. That is the point: stable wording makes a genuine change in a finding visible instead of drowning it in reworded prose. It also means the text you are reading may have been generated during an earlier scan.
If your team only does one thing with the report this week, file these ten as tickets and assign them. The downstream remediation appendix has the copy-paste fix for each.
## Per-jurisdiction detail
One detail page per jurisdiction that fired. The ring at the top mirrors the scorecard number. The table below it lists the top ten findings for that jurisdiction , which can overlap with the cross-jurisdiction top priorities but often introduces a few jurisdiction-specific ones (an EAA accessibility statement requirement, a UK Equality Act reasonable-adjustments concern, an AODA-only IASR clause).
The cited regulations panel at the right is the answer to “under what law?” Use it when you forward the report internally, pasting the regulation reference into a Jira ticket converts “we have a compliance issue” into “Article X.Y of regulation Z requires the following.”
## Remediation appendix
The longest section by page count. One card per top-priority finding, expanded to include: a one-paragraph plain-English explanation, an evidence screenshot (when the scanner could capture a stable element selector), a free-form fix-in-prose, and language-tagged code blocks (HTML / CSS / JavaScript) for the AI-generated patch.
The HTML/CSS/JS snippets are starting points, not patches to commit unreviewed. The scanner cannot see your component library or class-name conventions; treat the snippets the way you would treat a Stack Overflow answer, read it, adapt it, then commit.
## Remaining issues
A flat inventory of every issue past the top ten. No fix detail (the top ten and the remediation appendix already cover the high-leverage class), this exists so the report is a complete record. A buyer who only ships the top ten on the first iteration can come back to this section for the second sprint.
## Methodology, then glossary
What rule set we used, what each acronym means, what we did not evaluate (manual screen-reader testing, cognitive-load testing). Skip on first read; come back when a stakeholder or auditor asks “how was this measured?”
## Legal disclaimer and integrity block
The disclaimer is standard auditor language: the report is a snapshot, not a legal opinion. The integrity block is more interesting, every Veracly report is signed with an Ed25519 key, and the Verification ID printed here is what a holder of the PDF pastes at veracly.app/verify/<uuid> to confirm the bytes are the ones we issued. Read the rest of that block before you forward the report: it states that the Verify URL is valid for 30 days from issue. On a paid report it also tells the recipient to request the stored fingerprint from support@veracly.app against the Verification ID after that; on a free scan it instead notes that once the anchor retires 60 days after issue the stored fingerprint is erased and byte-for-byte verification ends. The ID is the durable half; the URL is not. It also carries the corrections address, if you want to dispute a finding rather than fix it. See How to verify a Veracly report is authentic for the full mechanic.
## A 30-minute workflow for the first report
- Open the PDF, read the executive summary (1 min).
- Scan the per-jurisdiction scorecard. Note the worst jurisdiction and the severity-bar shape (2 min).
- Go to Top Priorities. File each row as a ticket in your tracker with the title, severity, and the regulation reference from the corresponding detail page (15 min).
- For each ticket, open the remediation appendix card. Paste the explanation into the ticket description and link the AI snippet as a starting point (10 min).
- Schedule a re-scan for when the fixes land. Do not assume the automatic cadence will cover it, Starter runs monthly, Growth weekly or monthly, Pro and Agency daily, weekly, or monthly, and it is set per site. Use the Scan now button on the site detail page as soon as the fix ships (2 min).
## What the report deliberately does not tell you
Compliance is not a percentage. A 95 with one critical finding is more exposed than an 80 with twenty mediums. Read the severity distribution, not the headline, when you are deciding whether a result is “good enough.”
And the report is silent on the things automation cannot reach: manual screen-reader usability, cognitive-load testing of complex forms, plain-language review of legal pages by an actual lawyer. The methodology section names these omissions on purpose.
See also: The top 10 issues Veracly finds, and how to fix them · Free scan vs. paid report: when to upgrade
## Common questions
What does the overall score mean? +
The headline score is the average of every jurisdiction that fired for your site. A 70 means a typical visitor mix lands in the yellow band, you have meaningful violations but no single critical one. Green is 85+; red is below 60.
Why are some jurisdictions marked "not evaluated"? +
A jurisdiction only fires when your real visitor traffic includes the region it covers. An Australian-publisher site with zero EU visitors will see GDPR marked not-evaluated; we do not score what does not apply. That decision is shown on the report so it does not look like missing data.
What is the difference between an issue and a violation? +
An issue is a unique rule that failed (for example "form-label-missing"). A violation is an instance of that issue (the report counts five form-label-missing findings as five violations of one issue). The executive summary uses unique issues; per-jurisdiction cards use violations.
Where do I start fixing? +
The Top Priorities table. The report sections are not numbered, so look for that heading; it sits after the per-jurisdiction scorecard. Rows are ranked by severity first and then by how many pages the issue affects, so the ten items listed are the highest-leverage fixes regardless of which jurisdiction surfaced them. Anything beyond the top ten goes in the Remaining Issues inventory at the back.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- Multi-jurisdiction
### Multi-jurisdiction website compliance: one site, many laws
EU, UK, US, and Canadian visitors trigger different laws. Here is the practical playbook for satisfying GDPR, EAA, ADA, UK Equality Act, and AODA with one programme.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## Re-scanning after a fix: how Veracly tracks compliance regression
URL: https://veracly.app/blog/regression-detection-weekly-scan
Published: 2026-05-12

Multi-jurisdiction
# Re-scanning after a fix: how Veracly tracks compliance regression
Most compliance bugs are introduced after the original audit, not during it. A scheduled re-scan plus a score-drop alert is how you catch them in the cycle they ship.
By Veracly Compliance Team · 2026-05-12· 6 min read
The reason continuous monitoring exists is that the vast majority of compliance bugs are introduced after the original audit, not during it. A marketing team ships a new analytics pixel; a partner agency drops in a Hotjar tag for a campaign; a redesign re-orders the cookie banner with a different reject-all path. None of those changes touched the page that was originally audited, and all of them break compliance.
Veracly’s scheduled re-scan plus score-drop alert is the answer. Here is how the mechanic actually works, stated narrowly, because the useful version of this article is the one that tells you what the alert does not watch.
## What the re-scan covers
The same scope as your initial scan: every page the crawler reaches inside your configured page budget (fifty on Starter, two-fifty on Growth, five hundred on Pro, a thousand on Agency). Discovery is breadth-first from your homepage, following internal links to a depth of two, on the same hostname only.
We do not seed the crawl from your sitemap. Veracly fetches and honours robots.txt, and it parses the Sitemap: directive it finds there, then deliberately ignores it. A sitemap is a claim about what a site wants indexed, not a map of what a visitor can reach. A new page enters the scan set once something inside the crawl depth links to it.
Every scan produces a full report, same structure, same rule set, same PDF. The history lives on the site detail page as an attestation timeline : one row per completed scan, with the per-jurisdiction scores on that date and a link to the signed verification record for that report. That is the surface for reading the trend, and you can publish it as a link for a regulator or a buyer.
What the timeline is not is a diff. Veracly does not compute a finding-level comparison between two scans, so working out which issues appeared or disappeared is still a two-window read of the two reports. We would rather say that than sell you a diff view that does not exist.
## What triggers a score-drop alert
One signal, and it is narrower than most monitoring copy implies. After each scan we take the average score across every jurisdiction evaluated for that site and compare it with the average from the previous completed scan of the same site. If the new average is lower by at least your alert threshold, the report goes out flagged as a score drop.
- The comparison is on the average, not on any one card. A ten-point fall on the GDPR card, with the other four cards holding steady, moves a five-jurisdiction average by two points and does not fire.
- The default threshold is 10 points. Settable anywhere from 1 to 100 under Account → Settings. It is an organization-level setting, applied to every site you monitor, not a per-site one.
- The first scan of a site never fires. There is no prior scan to compare against, so the report is delivered as an ordinary report-ready.
And the thing that does not trigger an alert: a new critical finding. The alerting path reads scores; it never reads the finding list. A brand-new pre-consent pixel that costs you eight points against a ten-point threshold arrives as a normal report-ready email, and you find it by opening the report. If net-new criticals are what you care about most, lower the threshold to three or four and accept the extra noise, that is the lever that exists.
Delivery is by email to the organization owner, always. Slack is additional and optional on Growth, Pro, and Agency: paste an incoming-webhook URL under Account → Settings. Both go out the moment the report finishes rendering. There is no alert banner in the dashboard.
## What the alert email actually contains
It is the report-ready email with a red block at the top. In full:
- A subject line naming the domain and the fact that the score dropped.
- The drop block: previous average, new average, and the delta.
- The new average score and the number of jurisdictions it spans.
- A download button for the PDF.
- A line on how long that link stays live, seven days for a paid presigned URL, sixty days for a free scan.
It does not list the findings that moved, does not name the affected URLs, and does not link to a diff. Everything diagnostic is in the PDF. The email is a notification, not a report, and we are not going to push finding text into an inbox we do not control.
The Slack message carries the same numbers, the new average, the per-jurisdiction scores, and the drop, plus a download button.
## Investigating a regression
One workflow that works:
- Download the new report from the alert email and open the per-jurisdiction scorecard. That tells you which card moved.
- Open the attestation timeline for the site under Account → Sites → [domain]. It lists the per-jurisdiction scores for every completed scan, so you can see whether the card fell in one step or drifted over several runs.
- Open the previous report alongside the new one. There is no automated diff, so isolating what is new is a side-by-side read of the two Top Priorities tables. It takes a few minutes and it is the only way to get there today.
- Look at the affected URLs. If they are clustered on one page or one path, the regression came from a change on that page. If they are spread across many pages, the regression came from a global change (a layout component, a CDN-loaded widget, a CMP configuration change).
- Check the deploy log for the same window. Most regressions are traceable to a specific deploy or tag-manager change since the previous scan.
- File one ticket per new finding. The remediation appendix in the new report has the fix snippet, same as the first scan.
- Hit Scan now once the fix lands. The button is on the site detail page; do not wait for the next scheduled scan.
## The regressions this actually catches
Worth naming the list concretely, because it is narrower than the word “compliance” suggests:
- A new tracking pixel firing before consent. The most common real regression, and the one the scanner handles best: a marketer adds a tag through Tag Manager, nobody checks the consent gate, and the next scan records the request firing pre-consent, with a DevTools recipe you can reproduce yourself.
- A redesign that drops a contrast ratio, a form label, or an accessible name. These are axe-core violations and they move the score on the next run.
- A cookie-banner rebuild that loses reject-all parity , or loses the reject control altogether. Note the limit: parity is judged from the rendered DOM, not by clicking Reject and re-measuring. Veracly never clicks a consent banner, because a click would itself be a consent gesture and would pollute the pre-consent reading.
- A policy page that moved or started returning a 404. The privacy policy, accessibility statement, and imprint checks look for a reachable page on your own hostname; a relocated page reads as a missing one.
And the regressions it will not catch, which matter just as much when you decide how much weight to put on the score: a redesign that introduces a keyboard trap (Veracly never exercises the keyboard, and SC 2.1.2 is marked as not automated in the report’s criteria inventory), a cookie policy that has gone stale against the tags you actually run (there is no declared-versus-observed comparison), anything behind a login, and anything on a page the crawler cannot reach. Those need a person.
## Tuning the threshold
If the default 10-point threshold is too noisy for your site, or too quiet, it is a single number under Account → Settings, valid from 1 to 100, applied across every site in the organization. There is no per-site override today.
Tune it after two or three normal-state scans rather than at signup. Large sites with a lot of third-party widgets do wobble by a point or two between runs, and averaging across jurisdictions damps that further, which is part of why the default sits at 10 rather than at 3.
See also: Reading your first Veracly report · The top 10 issues Veracly finds and how to fix them
## Common questions
How often does Veracly re-scan? +
There is no universal default; the cadence is set per site from the frequencies your tier allows. Starter is monthly only. Growth can run weekly or monthly. Pro and Agency can run daily, weekly, or monthly. Every paid plan also has a Scan now button on the site detail page, so you never have to wait for the schedule after a fix lands.
What counts as a "score drop"? +
A fall of at least 10 points in the average score across every jurisdiction evaluated for that site, measured against the previous completed scan of the same site. 10 is the default threshold and it is configurable from 1 to 100 under Account then Settings. There is no separate trigger for new findings: the alerting path compares scores, not finding lists.
How fast is the alert? +
Immediate. The score-drop notice is a block inside the report-ready email itself, sent the moment the report finishes rendering, and the Slack message goes out in the same step. There is no separate alerting job and no queue behind it. The only thing you wait on is the scan cadence.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- Multi-jurisdiction
### Multi-jurisdiction website compliance: one site, many laws
EU, UK, US, and Canadian visitors trigger different laws. Here is the practical playbook for satisfying GDPR, EAA, ADA, UK Equality Act, and AODA with one programme.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## After a complaint to your data protection authority: what actually happens
URL: https://veracly.app/blog/regulator-complaint-process
Published: 2026-05-12

Multi-jurisdiction
# After a complaint to your data protection authority: what actually happens
A complaint to a data protection authority is the start of a process, not a verdict. Most SMBs imagine the worst; the actual workflow is a letter, a response, and usually a closure, provided the response is well-prepared.
By Veracly Compliance Team · 2026-05-12· 7 min read
A complaint to a supervisory authority is the start of a regulatory conversation, not a verdict. Most SMB owners who have never received one imagine FBI-style raids; the actual experience is a letter on official letterhead with a list of documents requested and a deadline to respond. The outcome depends heavily on what the response contains.
## The arrival
Supervisory authorities (CNIL in France, BfDI / state DPAs in Germany, Garante in Italy, AEPD in Spain, ICO in the UK, etc.) receive complaints through public web forms. A complaint is screened by the authority’s intake team. If it meets the threshold of a credible allegation against an identifiable controller, it is forwarded to the controller.
The forwarding is typically a letter or registered email containing:
- The complaint reference number.
- A summary of the allegation (often quoting the complainant’s text).
- The specific GDPR / ePrivacy / national-law articles the authority believes may apply.
- A list of information requested from the controller.
- A response deadline, typically 21 days (CNIL), 30 days (most DPAs), up to 60 days (large or complex matters).
The letter is not an accusation. It is a fact-finding step. The tone in most EU DPA letters is neutral and procedural.
## What gets asked for
A typical first-letter information request includes:
- The lawful basis under Article 6 the controller relies on for the processing in question.
- A copy of the privacy policy and any consent records.
- Where applicable, evidence of consent (timestamps, CMP logs).
- The retention period for the relevant data category.
- The data processing agreement with any subprocessors involved.
- Any transfer mechanism (DPF certification, SCCs, etc.) relied on for international transfers.
- The internal procedure for responding to data subject rights requests.
For accessibility complaints under the EAA or national accessibility law, the equivalent list is: WCAG conformance evidence, the accessibility statement, the remediation roadmap, and the date of the last audit. A Veracly report slots into the first and the last of those. It is not the evidence package, and an earlier version of this post claimed it was — which is exactly the kind of overclaim this site spends its time criticising in overlay vendors.
The reason is not modesty, it is arithmetic. Roughly a third of WCAG success criteria are machine-testable at all; every Veracly report carries a version-labelled inventory of all WCAG 2.2 Level A and AA criteria, marking each as partly automated, an automated review signal, or not automated, and stating what a person still has to check, rather than pretending otherwise. Keyboard traversal is never exercised, so no keyboard-trap or focus-order finding can exist. PDFs are never scanned. There is no screen-reader emulation and no authenticated-area testing. A conformance claim resting only on an automated scan is one a regulator can take apart with a single follow-up question. What the report evidences is the automated layer, the date it ran, and that the site is monitored rather than assumed compliant. The manual audit that completes the picture is separate work, and if the complaint is about accessibility you should assume the authority expects it.
## How to respond
Five principles consistently predict good outcomes:
- Respond on time. The deadline is real. Late responses can result in escalation regardless of substance. If you need an extension, ask explicitly before the deadline, most authorities grant a short extension on a reasonable request.
- Respond factually. Answer each question with documentation attached, not narrative. Authorities read hundreds of complaints; clear evidence is faster to process than careful prose.
- Be specific about remediation. If a finding is correct, acknowledge it and describe what you have already changed. “We fixed the banner parity issue on 12 May 2026, here is the deploy log” is a much better answer than “We dispute the characterization.”
- Don’t over-share. Provide the information requested, not everything the controller has. Volunteering additional processing details that were not asked about expands the scope of inquiry.
- Get a lawyer if there is doubt. First letter on a clear, cooperative case is generally manageable in-house. Special-category data, cross-border issues, or any allegation of intentional violation needs counsel.
## The escalation path
If the first response is unsatisfactory, or the complaint is severe enough at intake, the authority can escalate to a formal investigation. This typically involves:
- A follow-up letter with more specific document requests.
- Possibly an on-site visit (rare for SMBs in the EU, more common for large controllers and US contexts).
- A draft decision shared with the controller for comment.
- A final decision, possibly with a fine and remediation order.
- An appeal window, typically 30 to 60 days to the relevant administrative court.
For most SMB cases the process closes at step 1 with a warning, or at step 4 with a remediation order. Fines for SMB respondents are typically calibrated to size, CNIL has been explicit that they apply Article 83’s proportionality framework, and SMB fines in the four- and low-five-figure range are common; the seven-and-eight-figure headline fines target controllers with global revenue.
## The patterns that lead to fines
Across published EU DPA decisions against SMB respondents, the patterns that correlate with fines (versus warnings or remediation orders) are consistent:
- Failure to respond at all. The single largest predictor of an escalated outcome.
- Repeat violation. A controller previously warned for the same issue is treated more sternly than a first-time finding.
- Special-category data. Health, biometric, racial, religious, union, or sexual-orientation data raises the severity by one tier in most authorities’ internal frameworks.
- Children’s data. Special weight under GDPR Article 8 and CNIL’s 2021 guidelines on under-15 processing.
- Intentional or knowing violation. Evidence the controller knew the processing was problematic and continued. Internal communications surfaced in document production frequently determine the difference between a warning and a fine.
- Cross-border violations. Where the one-stop-shop engages, Article 56 designates the lead supervisory authority and Article 60 governs the cooperation procedure that follows. Get the direction right: this route is slower , not faster. Cross-border cases have historically sat in the Article 60 process for years, which is precisely why Regulation (EU) 2025/2518 , applicable from 1 January 2026, imposes binding procedural deadlines on them. Cross-border exposure raises severity because more authorities are watching and the eventual decision carries across the EU — not because anything moves quickly.
## What having a signed Veracly report does
A signed, timestamped Veracly report is a piece of evidence that does several things in a complaint response:
- Establishes when the controller last audited the relevant processing, the regulator wants to see that compliance is monitored, not assumed.
- Provides an independent third-party assessment, distinct from self-certification.
- Carries a verifiable signature, so the authority can confirm the PDF is the one issued and has not been edited. One practical caveat: the verify URL has a limited validity window — the integrity block printed in the PDF itself states 30 days from issue. If you are attaching a report to a complaint response, say when it was issued, and re-issue a current one rather than sending a regulator a link that will be dead when they click it.
- Maps findings to specific regulation articles, which is exactly the format the authority’s legal team is operating in.
None of this is a defense to a substantive violation. But it shifts the conversation from “does the controller take this seriously” to “here is the evidence of monitoring, here are the findings as of [date], here is the remediation status.” That framing matters.
## Practical recommendation
Treat the response window as a project. Open a folder for the complaint, file every piece of correspondence with the authority, file every piece of internal investigation, file your Veracly reports for the relevant period. Respond on the deadline, with attachments, in the format the authority requested. Follow up to confirm receipt. Most first-time SMB complaints close at this stage.
See also: How to verify a Veracly report is authentic · Sharing a Veracly report with regulators
## Common questions
How do most SMB complaints arrive? +
By mail or by registered email from the supervisory authority, with a complaint reference number and a response deadline (typically 21 to 30 days). They are factual and procedural, not accusatory. The cover letter usually summarizes the complaint and lists the specific information the authority requests.
What is the typical outcome? +
For a first-time SMB complaint with a cooperative response, the most common outcome by a very wide margin is closure with no fine, often with an instruction to remediate. The published French counts give a sense of scale: in 2023 the CNIL received 16,433 complaints, and across all of its enforcement activity that year it issued 168 formal notices (mises en demeure) and 42 sanctions. Do not turn those into a percentage — the enforcement figures cover the CNIL’s whole caseload, including controls it opened on its own initiative, so they are counts drawn from different populations rather than an outcome rate for complaints. The CNIL also publishes no breakdown by respondent size, so nobody can honestly give you an SMB-specific split.
Do I need a lawyer immediately? +
For most first-time SMB complaints, no. The response is a procedural letter providing the requested information. A lawyer becomes valuable if the complaint alleges special-category data processing, cross-border violations, or repeat violations, or if the regulator escalates to a formal investigation.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- Multi-jurisdiction
### Multi-jurisdiction website compliance: one site, many laws
EU, UK, US, and Canadian visitors trigger different laws. Here is the practical playbook for satisfying GDPR, EAA, ADA, UK Equality Act, and AODA with one programme.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## What "reject all" really has to do under GDPR (and why most banners get it wrong)
URL: https://veracly.app/blog/reject-all-parity-gdpr
Published: 2026-05-12

Cookies
# What "reject all" really has to do under GDPR (and why most banners get it wrong)
A cookie banner that puts "Accept all" on the front page and buries "Reject all" two clicks deep is not a defect, it is the violation. Banner parity is among the most-enforced consent rules in the EU.
By Veracly Compliance Team · 2026-05-12· 6 min read
Banner parity is among the most-enforced consent rules in the EU. On 31 December 2021 CNIL fined Google €150 million (délibération SAN-2021-023, split €90M against Google LLC and €60M against Google Ireland) and Facebook Ireland €60 million (SAN-2021-024). In both cases the finding was the same: refusing cookies took more work than accepting them. Italy’s Garante, the Spanish AEPD, the German Land data protection authorities and the Belgian APD have taken the same line. The rule is not interpretive, it has specific, enforced requirements.
## The rule, plainly
From CNIL’s guidelines on cookies and other trackers (délibération 2020-091, adopted 17 September 2020, enforced from the end of the grace period on 31 March 2021):
It must be as easy to refuse to consent as to give consent... If the user can consent at the first level by clicking on a single button, refusing must also be possible at the first level by clicking on a single button.
The EU-wide instrument for banners is not the EDPB’s Guidelines 03/2022 on deceptive design patterns, which are scoped to social media platform interfaces and are routinely miscited on this subject. It is the report of the EDPB’s Cookie Banner Taskforce, adopted 17 January 2023, which records the positions a large majority of national authorities found common ground on. That report is deliberately modest about its own reach: it describes itself as a common denominator and a minimum threshold, and says it does not prejudge any national authority’s own analysis. The part that is settled: a design that makes accepting easier than refusing invalidates the consent.
## What passes parity
- Two buttons, equal prominence. “Accept all” and “Reject all” on the same banner, same row, similar size, equivalent color treatment (either both branded or both neutral).
- Three buttons. “Accept all,” “Reject all,” “Manage preferences.” Each on the first banner. Slightly bigger panel footprint, but parity-clean.
- Toggles defaulted to off, plus accept-all + reject-all buttons. The toggle UI is the granular path; the two buttons are the one-click paths. As long as both one-clicks are present on the first surface, this passes.
## What fails parity
- “Accept all” button, “Manage preferences” link. The CMP industry’s most common default. Reject requires the user to click into a second panel and click reject there. Per CNIL: invalid consent. Fines have followed.
- Refusal present only as inline body text. The banner says somewhere in its paragraph that you may decline, but nothing on the surface is styled as a refusal control, so a user scanning the banner sees one option. Worth separating from a myth that circulates widely: a clearly placed “Continue without accepting” link is not the defect. CNIL’s recommendation 2020-092 uses that exact label in its own examples of compliant banners, and CNIL’s own site carries it. If you have that control, do not remove it on the strength of a blog post, this one included.
- “Accept all” in brand colour, “Reject all” as grey link text. Handle this claim carefully, because it is where most published advice overreaches. The Cookie Banner Taskforce expressly refused to impose a general colour or contrast standard (paragraph 17); the only contrast it condemns outright is text you cannot read against its background (paragraph 18). What authorities do act on is the point where reject stops looking like a control at all and starts looking like fine print, so that finding it takes effort accepting does not. Italy states a visual-equivalence requirement explicitly; elsewhere it is judged case by case.
- Reject requires more clicks than accept. If accept is one click and reject is one click followed by a confirmation modal, accept is easier. Invalid.
- Reject button greyed out until the user reads the policy. The UX trick of making the reject path require interaction (scrolling, reading) to activate. This is the core defect in plain form: refusing costs effort that accepting does not.
- Pre-ticked checkboxes for categories. Already established by the Planet49 CJEU decision (C-673/17, October 2019): consent must be active. Pre-ticked is invalid.
- Banner that re-appears on every page until accept. Pressure to accept. Invalid.
## The CNIL-Google decision in detail
CNIL’s €150M fine of Google (délibération SAN-2021-023, 31 December 2021, €90M against Google LLC and €60M against Google Ireland) named the specific defect: google.fr and youtube.com offered a single button that accepted cookies immediately, while refusing required, in the decision’s own words, « au moins cinq actions » — at least five actions.
- Accept-all: 1 click on a clearly labelled button.
- Reject path: at least five actions, spread across more than one screen, before the refusal was recorded.
CNIL held that this asymmetry discouraged refusal and invalidated the consent. Note how large the real gap is, because the figure is frequently repeated as three clicks: the decision found five actions or more. The fine reflected both the breach and the scale of Google’s French traffic.
## The Italian Garante position
The Garante’s 2021 guidelines (Provvedimento 231 of 10 June 2021) added a specific design requirement: equivalent visibility. Two buttons that are present but differently styled, accept in green, reject in gray, fail Garante’s visibility test even when click count is equal.
## The CMP configuration problem
Parity failures are usually configuration, not product. Nearly every consent platform on the market can render a first-layer reject button; whether yours does depends on the template you picked and the toggles you left alone. The two shapes we see most:
- The configured template buries reject behind a “Manage” link.
- The configured template puts accept and reject on the same surface, but the styling makes accept a prominent button and reject a quiet link.
We are not going to publish a list of vendors and their defaults. Templates change between product versions, between resellers, and between the plan tiers of the same vendor, so any such list is stale on arrival and unfair to whoever is on the version that fixed it. The noyb complaint waves of 2022 are sometimes cited as proof that particular products ship broken; they were aimed at how the sites in question had configured them. The only statement worth making is about your banner, as it renders today.
The fix is almost always a setting: turn on “show reject button on the first layer,” then give the two buttons the same treatment.
## The cost of failure
Fines for banner parity violations have ranged from €5k (small SMB, German DPA) to €150M (Google). CNIL has stated that small businesses face proportional fines, not headline-grabbing ones, but the regulatory cost is not the largest exposure, the larger cost is that invalid consent invalidates all the data collected under it. A 12-month archive of analytics gathered under a non-compliant banner is data that cannot be lawfully retained.
## Veracly’s parity check, and what it deliberately does not do
The parity check is a static inspection of the banner DOM , not a behavioural test. On each page we scan, we capture the banner element, enumerate the buttons inside it, classify each as accept, reject or manage, record whether it is visible, hidden, or positioned off-screen, and compute a visual weight for each one. Visual weight is rendered area multiplied by font weight , expressed as a fraction of the heaviest visible button. If the strongest reject button falls below 0.7 of the strongest accept button, or if reject exists only behind a submenu or off-screen while accept sits on the main banner, we raise reject-not-equal-to-accept and cite CNIL 2020-091 and the EDPB Cookie Banner Taskforce report.
Four limits, stated plainly, because they change how you should read the result:
- We do not measure colour contrast or click distance. Area and font weight are what we compute. Any judgement about colour is yours, and given what the Taskforce actually said about colour standards, that is the right division of labour.
- We never click your banner. A click would itself be a consent gesture and would pollute the pre-consent reading, which is the more valuable measurement and the one regulators ask about first. So we do not verify that pressing Reject stops the tags. We inspect whether the choice is presented fairly, and you test the behaviour yourself.
- When we cannot enumerate the buttons, we grade nothing. Banners that keep their controls in a closed shadow root, or render them outside the banner root, return an empty button list. In that case the parity verdict is withheld for that page rather than guessed. “No reject enumerated” is not the same observation as “no reject exists,” and we have shipped that exact false positive once already.
- A free scan covers one page. Banners are usually site-wide, so one page is usually enough to judge the banner, but if yours varies by section you are seeing one section. Paid scans crawl to the page cap of the plan.
The report cites the specific CNIL and EDPB guidance behind each finding and the configuration change that typically resolves it.
See also: Cookie banner audit checklist · GDPR vs ePrivacy: which one governs cookies?
## Common questions
Does reject have to be a button on the first banner? +
In France, yes: CNIL deliberation 2020-091 of 17 September 2020, enforced from 31 March 2021, requires that if consent can be given at the first level with one click, refusal must be possible at the first level with one click too. The EU-wide reference point for banners is the EDPB Cookie Banner Taskforce report of 17 January 2023, not Guidelines 03/2022, which are scoped to social media platform interfaces. A "Reject all" reachable only through a "Manage preferences" panel costs a click that "Accept all" does not, and that gap is the defect regulators name.
Can I make "Accept all" prominent and "Reject all" plain? +
Up to a point, but not to the point where reject stops reading as a control. The Cookie Banner Taskforce declined to set any general colour or contrast standard, so there is no EU-wide rule that the two buttons must match. What is enforced is effort: refusal must not cost the user more steps or more searching than acceptance. CNIL fined Google 150 million euros and Facebook Ireland 60 million euros on 31 December 2021 because refusing took several more actions than accepting. The 35 million euro Amazon fine of 7 December 2020 is often listed alongside them, but that decision was about advertising cookies dropped on arrival, not about button design.
What about a "Continue without accepting" link? +
It is not a dark pattern, and the widespread claim that CNIL says otherwise is backwards. CNIL recommendation 2020-092 shows "Continuer sans accepter" in its own examples of compliant banners, and CNIL uses that control on its own website. The narrower objection, from the EDPB Cookie Banner Taskforce, is to a refusal offered as inline body text with no visual support at all, where a user scanning the banner would never register it as an option. A clearly placed link or button carrying that label at the top level meets the requirement.
Does reject have to be the same color and size as accept? +
There is no EU-wide colour or size rule. Paragraph 17 of the Cookie Banner Taskforce report states that a general banner standard concerning colour or contrast cannot be imposed on controllers; paragraph 18 condemns only contrast so poor that the text is effectively unreadable. What is enforced is that refusing is available on the same layer, in the same number of clicks, as accepting. Italy is the outlier that goes further on visual equivalence. Two buttons of similar prominence pass everywhere; an "Accept all" button whose only counterpart is a "More options" link does not.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Cookies
### What is a cookie banner audit? (2026 checklist)
A cookie banner audit checks design, defaults, dark patterns, and what loads before any consent gesture. The Accept and Reject paths themselves have to be walked by hand. Here is the 2026 checklist.
- Cookies
### Cookie consent in Australia: what the law actually requires
Australian businesses install consent banners because European advice tells them to. There is no Australian rule requiring one for ordinary analytics. But sensitive information is a real exception, and the Privacy Commissioner enforced it against tracking pixels in June 2026.
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.

---

## Heat maps, session recordings, and the "legitimate interest" grey area
URL: https://veracly.app/blog/session-recording-legitimate-interest
Published: 2026-05-12

Tracking
# Heat maps, session recordings, and the "legitimate interest" grey area
Session recording tools sell themselves on the legitimate-interest argument: "we anonymize, we are GDPR-friendly, no consent required." EU DPAs have consistently rejected this. The recording itself is the storage event, and the storage is non-essential.
By Veracly Compliance Team · 2026-05-12· 6 min read
Session-recording tools (Hotjar, FullStory, LogRocket, Microsoft Clarity, Mouseflow, Smartlook) have a vendor pitch that goes: “Our data collection qualifies as legitimate interest under GDPR Article 6(1)(f). You can deploy without a consent banner.” This pitch is wrong about EU law in three independent ways. The tools themselves are not the problem; the deployment pattern is.
## Why legitimate interest fails for recording
First failure: ePrivacy 5(3). The recording-script load involves storage on the user’s terminal equipment. ePrivacy 5(3) requires consent for any non-essential storage. GDPR Article 6 governs what happens to data after collection; it cannot displace 5(3) at the collection step. The EDPB has explicitly rejected the “legitimate interest for cookie storage” argument multiple times.
Second failure: balancing test. Article 6(1)(f) requires that the controller’s legitimate interest is not overridden by the interests or fundamental rights of the data subject. The EDPB’s Guidelines on Article 6(1)(f) state that fine-grained behavioral profiling, which session recording is, generally fails the balancing test for marketing-derived legitimate interests. The user’s reasonable expectations on a transactional or informational website do not include their cursor being filmed.
Third failure: special-category data exposure. Session recordings routinely capture form-input fields. Even with vendor input-masking turned on, the mask is regex-based and routinely misses sensitive inputs (health intake forms, financial application forms, ID upload pages). Article 9 GDPR forbids legitimate interest as a lawful basis for special-category data processing. The risk of inadvertent Article 9 data capture is high enough that legitimate interest is not a defensible deployment posture.
## What the regulators have actually said
- CNIL (France): the 2020 guidelines and recommendation on cookies and trackers treat session-recording and heatmap tools as requiring consent. In February 2026 the CNIL went considerably further and opened a public consultation on a draft recommendation dealing specifically with session replay, naming Microsoft Clarity, Hotjar and FullStory. The consultation opened on 25 February 2026 and closed on 22 April 2026. That draft is the most detailed statement any EU regulator has published on these tools, and it is the document to read before deploying one in France.
- Garante (Italy): the 2021 cookie guidelines align with the same position, treating analytics and profiling trackers as consent-gated unless they meet the narrow strictly-necessary test.
- Bavarian DPA (Germany): Repeated guidance treating session-recording cookies as analytics-tier consent obligations.
- ICO (UK): Post-Brexit, ICO has retained the broadly aligned position. Recording tools require consent under PECR.
The convergence is consistent. The EU DPAs have not split on this question. Vendors that claim a different jurisdictional consensus are selling marketing copy, not legal analysis.
What is deliberately not on that list is a table of fines. Earlier versions of this article claimed CNIL sanctions against French sites running Hotjar, Garante action against Italian e-commerce sites running Smartlook and Mouseflow, and a 2023 Datatilsynet position paper. None of the three survived a source check, so all three are gone rather than replaced. The regulators’ position on the lawful basis is consistent and well documented; the published enforcement record aimed specifically at session-recording tools is thinner than blog posts — ours included, until this revision — usually suggest. Plan against the stated position, not against an imagined fine schedule.
## What input masking does and does not solve
Every major session-recording vendor offers input masking, a regex-based filter that masks form fields matching patterns like password, email, credit card. Vendors pitch this as the “privacy-respecting” mode. It is not a consent workaround. Masking addresses one risk (literal PII capture inside form fields) and not the others:
- The recording still captures cursor paths, scroll patterns, click sequences, page navigation. This behavioral profile is personal data per recital 30.
- The masking regex is imperfect. Forms with non-standard input names (a health intake form’s “diagnosis” field, an application’s “condition” field) are captured unredacted.
- Client-side masking does close the obvious hole: text the regex catches never leaves the browser, so a vendor breach cannot expose it. What a breach or a subpoena does reach is everything the mask did not catch, which is most of the recording, the DOM of every page the visitor saw, the cursor and scroll trace, the click sequence, and every URL visited, including anything your own application put in a query string.
- The recording is associated with a session identifier the vendor can correlate across sessions if the same identifier persists in localStorage.
## The deployment pattern that actually works
Session recording is not banned in the EU. It is consent-gated. The compliant deployment pattern:
- Load the recording script post-consent only. Atype="text/plain" attribute on the script tag at first render, flipped to text/javascript after the user clicks accept on the analytics category. Every major CMP supports this.
- Enable input masking even with consent. Defense-in-depth. Consent does not entitle the controller to special-category data.
- Document the legal basis as Article 6(1)(a) consent. Not legitimate interest. Vendor templates and policy generators often default to legitimate interest; override.
- Add the recording tool to the cookie policy and subprocessors page. The vendor is processing personal data on the controller’s behalf. Article 13/14 transparency requires disclosure.
- Honor reject and delete requests. Recordings created under consent are deletable on Article 17 request. The vendor must support this and you must wire your support process to forward the requests.
## Veracly’s flag
Veracly’s tracker registry is a hand-curated list of 69 vendors. Five of them carry the session-replay category: FullStory, LogRocket, Mouseflow, Crazy Egg and SessionStack. Hotjar and Microsoft Clarity are in the registry too, categorised as analytics rather than session-replay, both rated high privacy risk, both carrying a note that their recordings and heatmaps are personal data requiring explicit consent. If a vendor is not among those 69 entries, Veracly does not see it: the list is curated by hand between releases, not pulled from a live feed.
When one of those endpoints is requested before consent, the scan raises a pre-consent tracker finding with the request URL and a DevTools recipe you can re-run yourself. Three limits are worth stating. Veracly loads the page and watches it; it does not scroll, hover or click, so a recorder that only starts on interaction is never exercised. It never clicks the banner — a click is itself a consent gesture and would pollute the pre-consent reading — so there is no post-consent pass and nothing in the report tells you whether a consent choice is honoured after it is made. And a self-hosted or first-party-proxied recorder served from your own domain is invisible to the scan entirely. The jurisdictional note attached to each vendor is a short static string we wrote, not a live index of enforcement decisions.
See also: Tracking pixel audit · Cookies, localStorage, IndexedDB consent
## Common questions
Is "anonymized" session recording exempt from consent? +
No. The recording itself involves storage on the user’s terminal equipment (session identifier, recording cursor) and processing of behavioral data that EDPB has consistently classified as personal data even when "anonymized" by the vendor’s self-description. ePrivacy 5(3) and GDPR Article 6 both apply.
Do these tools really capture personal data? +
Yes. Session recordings capture mouse movements, click sequences, form input (often including PII before sanitization), and scroll patterns. Even with input masking enabled, the behavioral profile is sufficient to identify a returning visitor in a small population. The CNIL, Garante, and Bavarian DPA have all confirmed this position.
What about Microsoft Clarity’s "free, GDPR-friendly" pitch? +
Microsoft Clarity is one of the most aggressive tools in this category and is generally classified by EU DPAs as requiring consent. The "GDPR-friendly" claim refers to Microsoft’s data-processing agreements and EU hosting options, not to the consent question. Consent is still required.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Tracking
### Tracking pixel audit: GDPR & ePrivacy compliance for SMBs
Tracking pixels share visitor data with ad networks the moment they fire. Here is what an audit checks, why pixels are the most-fined item on SMB sites, and how to keep them and stay compliant.
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## Sharing a Veracly report with your developer, lawyer, or regulator
URL: https://veracly.app/blog/sharing-veracly-reports
Published: 2026-05-12

Multi-jurisdiction
# Sharing a Veracly report with your developer, lawyer, or regulator
The same PDF gets read very differently by your developer, your lawyer, and the regulator who asked for it. Here is the three-audience guide to handing it over.
By Veracly Compliance Team · 2026-05-12· 5 min read
A Veracly report has three primary audiences. Each one reads it differently. The same PDF that lands in front of a developer as a backlog will land in front of a lawyer as a risk register and in front of a regulator as evidence. Here is how to hand it over to each.
One thing to settle before any of it. The report carries two identifiers: the Verification ID , printed in the integrity block on the disclaimer page, and the verify URL built from it. These are not two independent lifetimes. The URL is the ID in a path, they resolve against the same record, and neither can outlive the other, so quoting the ID is not a hedge against a dead link. What changes over time is what that record can still tell you. A paid-report anchor carries no automatic expiry and the retention sweep never touches it; the published policy sets no horizon at all, because the anchor is kept independently of the parent scan record and outlives it when that record is dropped at 12 months. A free-scan anchor is retired 60 days after signing: the signature and the stored SHA-256 are erased, and the second copy of that digest, held with the PDF record, is deleted on the same window. After retirement the URL still answers, but only to confirm that the report existed and when it was signed. The PDF prints a more conservative promise than either, that the verify URL is valid for 30 days from issue. Every cover note below is written on that basis: open the link yourself on the day you send it, and tell the recipient what they will find there later. A dead “independently verifiable” link in front of a regulator is worse than no link at all.
The report’s sections are not numbered, so the names below are what you will actually see as headings in the PDF. They appear in this order.
## Sharing with your developer
What they need: Top Priorities and the Remediation Appendix. Everything else is context they can skim.
How to share: Forward the PDF, then create one ticket per Top Priority row in your tracker. Each ticket should carry: the violation title, the severity, the specific element selector from the remediation card, and the copy-paste HTML/CSS/JS fix. Do not file a single ticket saying “fix all accessibility issues”, that ticket will sit forever.
What to put in the cover note: “Top ten priorities are linked below as tickets. The PDF appendix has the fix snippet for each. Please take the criticals first; we have a re-scan scheduled for [date].”
## Sharing with your lawyer or compliance team
What they need: The Per-Jurisdiction Scorecard, the Per-Jurisdiction Detail pages, and the Legal Disclaimer. They will care less about the specific HTML fix and more about the citations panel on each detail page.
How to share: Forward the PDF with the Verification ID. Most legal reviewers will independently confirm the signature before they cite the report, so handing them what they need upfront is faster than answering “is this authentic?” later. Include the verify URL as well if you have just opened it and it resolves. If this is a free-scan report more than 60 days old, say so in the note rather than letting them discover a retired record on their own.
What to put in the cover note: “Multi-jurisdiction scan dated [scanDate]. The legal-floor score on the AODA card uses Ontario’s 2.0-AA statutory bar; the cross-jurisdiction parity score uses 2.1 AA. Verification ID [id], printed in the integrity block on the final page. The signed record can be confirmed at veracly.app/verify/<uuid>, which also accepts a ?sha256= parameter so you can reconcile the file you are holding against the signed record yourself.”
## Sharing with a regulator
What they need: The Executive Summary, every Per-Jurisdiction Detail page, the Methodology section, and the Legal Disclaimer. Regulators care about methodology and rigor; they will scrutinize the “what we did not evaluate” disclosure as much as the findings.
How to share: The PDF only. Do not send the dashboard link; regulators expect a fixed-snapshot document they can file. This is the one audience where the link-freshness rule is not optional: a regulator files your cover note and may open the link months later. There is no second, more durable route waiting behind the link, so do not promise one. The durable thing you control is the file itself: attach the PDF, record its SHA-256 in the cover note, and tell the regulator exactly what the endpoint will and will not still confirm by the time they read it.
What to put in the cover note: Be brief and specific. “Per your request of [date] regarding [reference number], please find attached our most recent multi-jurisdiction compliance scan for [domain], dated [scanDate]. The document is cryptographically signed; its Verification ID is [id], printed in the integrity block on the final page. The SHA-256 of the attached file is [digest]. Authenticity can be confirmed without contacting us at veracly.app/verify/[id]?sha256=[digest], which returns the signed record and checks it against the digest above. Veracly’s retention policy is published at veracly.app/.well-known/veracly-retention.json. If the record has been retired under that policy before you open the link, the endpoint will still confirm that this report was issued and on what date, but the signature and the fingerprint are erased at retirement and cannot be reissued by us or by anyone else, which is why the digest is stated here. The report was generated by an independent automated audit tool against WCAG 2.1 AA, GDPR, ePrivacy, EAA, ADA, UK Equality Act, and AODA. Methodology and scope limitations are documented in the methodology section of the attached document. We are at your disposal for any follow-up.”
That is longer than the version we used to publish here, which pasted a bare verify URL and left it at that. It is also longer than the version that replaced it, which told the regulator to email support for a fingerprint reconciliation after the record retired. That was worse than a dead link, because it was a promise we cannot keep: retirement erases the fingerprint from the anchor, and the same sweep deletes the only other copy of it. Proof that the report existed survives retirement. Proof that the bytes in front of you are the bytes we signed does not, unless someone wrote the digest down while it was still available. So write it down, in the cover note, on the day you send.
## Sharing with a customer or B2B prospect
What they need: The cover page and Executive Summary. The full detail is available if asked for, but most enterprise procurement reviewers will file the report against a checklist after reading the cover.
How to share: Send the PDF as a transparency signal alongside your DPA or security questionnaire response. Frame it as proof that you monitor, not as a score to debate.
What to put in the cover note: “Attached is our current compliance scan, dated [scanDate]. We re-scan on a [monthly / weekly / daily] schedule and a material score drop triggers an internal review. The PDF is signed; the Verification ID and verification instructions are in the integrity block on the final page.” Say the cadence you actually run, it is set per site and Starter plans are monthly, not weekly.
## Publishing the report on your own site
Some customers publish their Veracly reports on a public /accessibility or /trust page as a transparency signal. This is an unusually strong move for an SMB and rewards well, it is concrete evidence of audit cadence, the signature makes the claim falsifiable, and the page itself becomes a trust signal that closes B2B deals.
If you publish, link directly to the PDF. Do not extract screenshots, the value is the falsifiable signed document, not a screenshot anyone could fake.
Publishing a verify URL needs one extra habit, because a trust page is exactly the place a stale link does the most damage. Either replace the link each time you post a fresher report, or publish the Verification ID with a line saying how to check it. If you leave a link up, put a diary note to open it yourself every month, and re-publish rather than let it rot. This is a rule we hold ourselves to: we do not put verify URLs in our own outbound material, for exactly this reason.
## What never to do
- Do not edit the PDF before sharing. Any byte change invalidates the signature, and the recipient’s verification will fail.
- Do not strip the disclaimer page. The integrity block lives there; without it the report cannot be verified.
- Do not re-export the PDF through a different viewer (some viewers re-encode the file on save). If you need a different format, generate it from the original.
- Do not redact findings before forwarding. If a regulator later requests the original and the redacted version was shared with the same number, that discrepancy is itself reportable.
See also: How to verify a Veracly report is authentic · Reading your first Veracly report
## Common questions
Can I share my Veracly report publicly? +
Yes, the PDF is yours, and verification works without a Veracly account. Some customers publish their reports on a /accessibility or /trust page as a transparency signal. The signature lets external parties confirm the bytes are unaltered, for as long as the anchor is live, so re-check any published verify link when you publish a new report.
Should I share the dashboard or just the PDF? +
The PDF for most external audiences. Internal stakeholders who need the issue inventory and drill-down get more value from the dashboard, but external recipients (regulator, customer, lawyer) expect a single fixed document they can save.
Will the PDF expire? +
The PDF does not, but the verify link does, and this is the single most important thing to get right before you forward a report. Every PDF prints, in its own integrity block, that the Verify URL is valid for 30 days from issue. Paid-report anchors carry no automatic expiry, and they are kept independently of the parent scan record rather than dying with it when it is dropped at 12 months, so the verify URL keeps resolving afterwards. You can also quote the Verification ID to support@veracly.app and we will reconcile a SHA-256 against the stored fingerprint. Free-scan anchors are retired by a daily sweep 60 days after signing, the free PDF is deleted on the same window, and the fingerprint goes with it, so after that nobody can confirm the bytes, us included. A retired link does not 404: it returns a record confirming the report existed and when it was signed. So: keep the PDF, and check the link before you send it, not after.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- Multi-jurisdiction
### Multi-jurisdiction website compliance: one site, many laws
EU, UK, US, and Canadian visitors trigger different laws. Here is the practical playbook for satisfying GDPR, EAA, ADA, UK Equality Act, and AODA with one programme.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## When does a small business lose its compliance carve-outs?
URL: https://veracly.app/blog/small-business-compliance-thresholds
Published: 2026-05-12

Multi-jurisdiction
# When does a small business lose its compliance carve-outs?
GDPR has no small-business exemption. EAA has one but only for service providers. CCPA kicks in at $25M revenue or 100k consumers. Each regulation draws the line differently, here is the map.
By Veracly Compliance Team · 2026-05-12· 7 min read
Every regulator that has thought about small business has answered “at what size do you apply?” differently. The result for an SMB owner: a patchwork of thresholds, each measured against a different metric, each triggering a different obligation. Here is the actual map.
## GDPR, no threshold
Regulation (EU) 2016/679 applies to any organization established in the EU that processes personal data, regardless of size. It also reaches organizations with no EU establishment, but only on the Article 3(2) conditions: offering goods or services to data subjects in the Union , or monitoring their behaviour in the Union. Note the wording. The test is where the data subject is, not their residence or citizenship, and merely being reachable from the EU is not enough. The EDPB Guidelines 3/2018 look for evidence of targeting, EU currencies, EU languages, EU-specific delivery, EU-directed marketing. A one-person consultancy that happened to take one EU customer without ever aiming at the EU market is probably outside Article 3(2); the same consultancy running EU-targeted ads is squarely inside it. Either way there is no size threshold.
The single SME-friendly carve-out is Article 30(5): organizations under 250 employees are exempt from maintaining records of processing activities, except when processing is not occasional, includes special categories (health, race, religion, etc.), or is likely to result in risk to data subjects. Most SMBs process customer data continuously, which means “not occasional,” which means the carve-out does not actually apply. Treat as if Article 30 applies in full.
## ePrivacy Directive, no threshold
Directive 2002/58/EC and its national transpositions apply to any electronic communications service or website operating in the EU. No size carve-out. A solo developer’s blog has the same cookie-consent obligations as a 10,000-employee enterprise.
## EU Accessibility Act, microenterprise exemption for services only
Directive (EU) 2019/882 Article 4(5) exempts microenterprises providing services from the EAA service obligations. The test sits in Article 3(23), and its shape matters: fewer than 10 persons employed and either an annual turnover not exceeding €2M or an annual balance-sheet total not exceeding €2M. The headcount limb is mandatory; the financial limb is a disjunction, so a 9-person firm with €3M turnover and a €1M balance-sheet total is still a microenterprise. The exemption does not extend to:
- EAA-covered products (manufacturers, importers, distributors).
- Antidiscrimination law (UK Equality Act, German AGG, French 2005 law), which carries no size threshold of its own.
A common misreading is that national accessibility law claws the exemption back. It usually does not. Germany’s BFSG is the German transposition of the EAA, not a pre-existing parallel regime, and § 3 Abs. 3 BFSG carries the identical microenterprise carve-out for service providers. France’s RGAA duty, under art. 47 of the 2005 law, starts at €250 million turnover, which is far above any SMB. Neither bites below the EAA threshold. Check the transposing statute in each member state you actually sell into rather than assuming a stricter local floor exists.
See our detailed write-up on the EAA exemption .
## UK Equality Act 2010, no threshold for reasonable adjustments
The reasonable-adjustments duty under Section 20 applies to every service provider regardless of size. The duty is anticipatory, a 2-person service provider must consider accessibility before being asked. The Equality and Human Rights Commission (EHRC) has been consistent that resource constraints affect the “reasonable” qualifier but not the existence of the duty.
## US ADA Title III, “public accommodations”
The ADA does not use a head-count threshold. Title III applies to any business qualifying as a “public accommodation”, a category covering retail, restaurants, professional services, lodging, transportation, education, and recreation. Most SMB websites qualify; corporate B2B websites with no consumer interface generally do not.
Title I (employment) has a 15-employee threshold but does not regulate websites. The DOJ’s April 2024 final rule under Title II applies to state and local government, not private SMBs.
## California CCPA / CPRA, three thresholds, any one triggers
California Civil Code §1798.140(d) defines a covered business as a for-profit entity that:
- Has annual gross revenues over $25 million ; or
- Buys, sells, shares, or receives personal information of 100,000 or more California consumers or households annually; or
- Derives 50% or more of annual revenue from selling or sharing personal info.
The three thresholds are independent. An SMB with $5M revenue can still cross the 100,000-consumers bar if they run a high-traffic California-facing site. Once covered, the full CCPA/CPRA suite applies.
## Colorado, Connecticut, Texas, Virginia, Utah, converging
The post-CCPA wave of US state privacy laws settled on a similar pattern: revenue or volume-based thresholds, focused on consumer-data sales. The current population of state laws (2026):
- Colorado, Connecticut: 100,000 consumers per year, or 25,000 consumers + revenue from sales.
- Virginia: 100,000 consumers, or 25,000 + 50% sale revenue.
- Utah: $25M revenue + 100,000 consumers OR 25,000 + 50% sale revenue.
- Texas TDPSA: “Conducts business in Texas” with no size threshold, but the substantive duties only apply to non-small-businesses (under SBA size standard).
- Other states (DE, MD, OR, MN, NJ, NH, KY, etc.): similar 100k consumer / 25k+sale-revenue pattern, with some variation.
## Australian Privacy Act, AUD 3M threshold
The Privacy Act 1988 applies to organizations with annual turnover above AUD 3 million . Below that, organizations are exempt from the Australian Privacy Principles (APPs) entirely. Exceptions:
- Health service providers (no threshold, covered regardless).
- Organizations that trade in personal information.
- Contractors to the federal government.
- Credit reporting bodies, residential tenancy databases.
The AUD 3M threshold is under reform; the Australian government has signaled intent to lower it substantially. The 2024 reform package proposes phased extension to all organizations regardless of turnover, with smaller-business obligations tiered. Plan as if the threshold may be lowered in 2026 to 2027.
## Canada, PIPEDA + provincial
PIPEDA applies federally to commercial activities; no size threshold. Provincial laws (Quebec Law 25, BC PIPA, Alberta PIPA) apply additionally; Quebec’s Law 25 is the strictest and applies to any organization processing Quebec residents’ data, no size carve-out.
AODA (Ontario) applies to every Ontario organization with at least one employee. The 50-employee line people quote gates exactly one duty: IASR s. 14, the obligation to make websites and web content conform to WCAG 2.0 Level AA (and note that s. 14 also carves out live captioning and audio description). An organization with 1 to 49 employees still owes the customer service standard, accessibility policies, staff training, and accessible formats and communication supports on request. “Under 50, nothing applies” is the single most common AODA error.
## Brazil LGPD, no threshold
Lei Geral de Proteção de Dados (LGPD) applies to any organization processing data of Brazilian residents, no size carve-out. Penalty caps are smaller for small-and-startup organizations under ANPD regulation (RDA 4 of 2023), but the substantive obligations apply equally.
## The compounding effect
An SMB selling EU + UK + US + Canadian customers is simultaneously under: GDPR (no threshold), ePrivacy (no threshold), UK Equality Act (no threshold), ADA (public accommodation), and possibly CCPA + Colorado + Texas + Quebec Law 25. Each has its own consent regime, breach notification timeline, data subject rights, and enforcement body.
This compounding is why “we are small, we are exempt” is rarely accurate for an SMB with cross-border traffic. The exemptions stack, qualifying for one is not the same as qualifying for all, and the substantive obligations of the regulations without size thresholds (GDPR, ePrivacy, UK Equality Act, ADA, Quebec Law 25, LGPD) cover most of the surface anyway.
## What Veracly does, and does not, track for you
Veracly does not ask you to declare a size band, and there is no size field anywhere in the product. That is deliberate. Severity is fixed per rule pack, so an EAA finding is graded identically whether you have four employees or four hundred. We are not willing to downgrade a finding to “informational” on the strength of a self-declared headcount, because that declaration is exactly the thing a regulator would test first, and a report that softened its own findings on an untested input would be worth nothing when it mattered.
What the scan does select on is jurisdiction. Rule-pack selection is driven by the country inferred for the site and the visitor countries configured on your plan, so a site with no EEA footprint in scope is not graded against the EAA at all. Whether the microenterprise exemption applies to you is a legal question about headcount, turnover, and whether you are a service provider or a manufacturer, and the report does not answer it. The Methodology section is a short note on how the scan works, crawling, axe-core, network interception, policy pages, not a threshold analysis. Use this page for the thresholds, then check the transposing statute for your market.
See also: EAA microenterprise exemption · Multi-jurisdiction website compliance
## Common questions
Does GDPR have a small-business exemption? +
No. GDPR Article 30 has a partial exemption from the "records of processing activities" obligation for organizations under 250 employees, but that is a paperwork carve-out, not a substantive one. All other GDPR obligations, lawful basis, consent, data subject rights, breach notification, transfers, apply regardless of size.
What is the most common threshold across all regulations? +
There is no single one. The closest to a common threshold is the EU SME definition (<50 employees, <€10M turnover) and the EU microenterprise definition. Note that the microenterprise test is not a flat conjunction: EAA Article 3(23) requires fewer than 10 persons employed AND either turnover not exceeding €2M OR a balance-sheet total not exceeding €2M, so the financial limb is an either/or. The substantive regulations (GDPR, ePrivacy, EAA, ADA, CCPA) each pick their own bar anyway.
When does my US site come under CCPA? +
When you cross any of: $25M annual revenue, buying/selling/sharing personal info of 100,000 California consumers or households, or deriving 50%+ of revenue from selling/sharing personal info. The thresholds are independent, meeting one is enough.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- Multi-jurisdiction
### Multi-jurisdiction website compliance: one site, many laws
EU, UK, US, and Canadian visitors trigger different laws. Here is the practical playbook for satisfying GDPR, EAA, ADA, UK Equality Act, and AODA with one programme.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## The top 10 compliance issues we see on SMB sites, and how to fix them
URL: https://veracly.app/blog/top-compliance-issues-and-fixes
Published: 2026-05-12

Multi-jurisdiction
# The top 10 compliance issues we see on SMB sites, and how to fix them
Most SMB sites trip on the same short list of compliance issues. Nine of them a scanner can catch; one it cannot, and we say which. All are fixable in under a day with the right snippet.
By Veracly Compliance Team · 2026-05-12· 9 min read
These are the issues we see most often on SMB sites. We are deliberately not attaching a percentage to that: our production scan corpus is nowhere near large enough to support one, and an invented prevalence figure is exactly the kind of claim this blog exists to argue against. What follows is the judgement of the people who wrote the rule packs. Nine of the ten are findings the Veracly engine emits on its own; number ten is a manual check and is labelled as one. None require a rebuild; all are fixable in a single PR. For each: the regulation it breaches, the typical Veracly severity, and the developer fix.
## 1. Tracking pixels firing before consent
What: Meta Pixel, Google Ads, GA4, LinkedIn Insight loading on first page view, before the cookie banner has been clicked.
Regulation: ePrivacy Article 5(3), GDPR Article 7. CNIL and the Italian Garante have issued seven-figure fines for this exact pattern.
Severity: Critical.
Fix: Move every non-essential script behind a consent gate. The simplest pattern: set type="text/plain" on the <script> tag at first load and flip it to text/javascript when the user accepts. Most CMP vendors ship a helper for this; if you do not use a CMP, a 20-line vanilla helper does the job.
## 2. Form inputs without labels
What: Inputs with placeholder text but no associated <label> or aria-label.
Regulation: WCAG 2.1 AA Success Criterion 1.3.1 (Info and Relationships) and 4.1.2 (Name, Role, Value). Caught by every accessibility scanner and every screen reader.
Severity: Critical. The axe label rule is mapped critical in every one of our rule packs, EAA, ADA and UK Equality Act alike, because an unlabelled input is not a degraded experience, it is a form a screen-reader user cannot complete.
Fix: <label for="email">Email</label> paired with <input id="email" ... />. If a visible label is not in the design, use aria-label="Email" on the input. Never rely on placeholder alone, it disappears the moment the user starts typing.
## 3. Insufficient color contrast on body text
What: Gray-on-white body text with a contrast ratio below 4.5:1.
Regulation: WCAG 2.1 AA Success Criterion 1.4.3 (Contrast, Minimum).
Severity: High.
Fix: Darken the gray, but check the number before you touch a token. color: #9ca3af on #ffffff is 2.54:1 and fails outright. #6b7280 is 4.83:1 and already passes for normal text, if that is your body color, leave it alone. #475569 is 7.58:1 and passes with room to spare. Pair this with a one-time pass through your design tokens; the issue usually lives in 3-4 CSS variables, not on individual elements.
## 4. Missing accessibility statement
What: No accessibility statement resolving on your own domain. That is the whole test, and it is worth being precise about it: we check presence, never content and never freshness. There is no date or version check on any policy document in the engine, so a statement written in 2019 and never touched since passes exactly like one reviewed last week. Keeping it current is a calendar item you own, not a finding you will get.
Regulation: European Accessibility Act Article 13(2) and Annex V, which require a service provider to explain, in the general terms and conditions, how the service meets the accessibility requirements. The prescriptive statement template most people picture, conformance status, feedback mechanism, enforcement contact, comes from Article 7 of the Web Accessibility Directive (EU) 2016/2102 and binds the public sector; in the UK that lands as the 2018 accessibility regulations plus procurement law.
Severity: Critical, and it only fires when an EAA member state is in your scan scope. Outside the EAA there is no accessibility-statement rule in our packs at all, so a US-only or UK-only scan will not raise it, which is not the same as saying you do not need one.
Fix: Publish /accessibility on your own host, a statement parked on a vendor domain is not accepted by the check, with: the conformance target (WCAG 2.1 AA), the known limitations, a contact path for accessibility reports, and a last-reviewed date. Put the annual re-review in a calendar; nothing in the scan will remind you.
## 5. Cookie banner with no “reject all” option
What: A banner with “Accept all” on a prominent button but “reject all” buried two clicks deep, or missing entirely.
Regulation: GDPR Article 7(3), ePrivacy. The CNIL, the Garante and the AEPD have all fined for asymmetric consent, the design choice is itself the violation. In Germany, enforcement against private websites sits with the sixteen Land authorities, not the BfDI, which supervises federal public bodies and the telecoms and postal sector.
Severity: High.
Fix: Reject and accept must be on the same surface, same visual weight. The standard CNIL test: a reasonable person presented with the banner could decline as easily as accept. Most CMPs have a “banner parity” toggle shipped off-by-default, turn it on.
## 6. Self-hosted Google Fonts violation (live load)
What: The page loads fonts from fonts.googleapis.com or fonts.gstatic.com at runtime.
Regulation: LG München I 2022 ruling, live-loading Google Fonts transmits visitor IP addresses to Google without consent, violating GDPR Article 6. Class actions in Germany have followed.
Severity: Medium, inside GDPR scope. There is no country modifier on this rule, contrary to what the Munich origin story suggests: it grades medium whether your primary market is Germany or Portugal. Outside GDPR scope it is not graded low, it is not graded at all, because the rule lives only in the GDPR pack.
Fix: Self-host the font files. If you are on Next.js, the next/font/google API does this at build time automatically, drop the external <link> tags. For static sites, download the woff2 files and serve from your own origin.
## 7. Third parties that appear nowhere in the privacy policy
What: A vendor is observed loading on the page, Hotjar, Clarity, TikTok, Intercom, whose name appears nowhere in the published privacy text.
Regulation: GDPR Article 13 (information to be provided); in the UK, PECR alongside UK GDPR Article 13. The most common cause of a regulator follow-up question.
Severity: Medium, and only inside GDPR scope.
Fix: Name every third party you actually load, and say what it does. Two honest caveats on this rule. It deliberately under-reports: any mention of the vendor in any form counts as disclosed, so a pass means “the name is present”, not “the disclosure is adequate”. And nothing in Veracly compares a published cookie table against the cookies we actually saw set, that completeness check does not exist in our engine and we are not going to imply it does. Run a fresh inventory yourself from the browser’s Application tab, and re-check it on every third-party addition.
## 8. Missing alt text on meaningful images
What: Product photos, infographics, team headshots without an alt attribute.
Regulation: WCAG 2.1 AA SC 1.1.1 (Non-text Content).
Severity: Medium.
Fix: alt="descriptive text" on meaningful images, alt="" (empty string) on decorative ones. The empty alt is correct, not lazy, screen readers skip it. The bug is omitting the attribute entirely, and that is exactly as far as automation reaches: axe-core tests whether alt is present, never whether it says anything useful, and it cannot tell a meaningful image from a decorative one. alt="" on your hero product photo passes every scanner on the market, ours included, and still fails the user. Alt-text quality is a human review.
## 9. Empty headings and paragraphs dressed up as headings
What: An <h2> that contains only an icon, a decorative span, or nothing at all; or a large bold <p> sitting where a heading belongs.
Regulation: WCAG 2.1 AA SC 1.3.1 (Info and Relationships).
Severity: Medium.
Fix: Give every heading element real text, and promote visual pseudo-headings to actual <h2> / <h3> elements. Note the boundary here: empty headings and fake headings are machine-detectable and we fire on both, but whether your heading order is semantically correct is not, and we do not grade it. One <h1> per page with sections that drop a level at a time is still the right pattern, you just will not get a scanner finding when you break it. CSS handles visual size; do not pick a heading element for its font size.
## 10. Privacy policy missing required clauses (manual, no scanner settles this)
What: The published privacy policy omits one or more required sections, typically the international transfers clause, the data retention table, or the supervisory authority contact.
Regulation: GDPR Articles 13 and 14 enumerate the required disclosures.
Severity: Not scored, and that is the point. Veracly checks that a privacy policy exists and resolves on your own domain. It does not read the text for a controller, a legal basis, a retention period, or a transfer mechanism, there is no clause-level analysis in the engine at all. Any tool that claims to grade the adequacy of your policy is running a keyword search and calling it a legal opinion.
Fix: Run your policy against the Article 13/14 checklist by hand. Common omissions: SCC reference for non-EU transfers, named supervisory authority for your country of establishment, retention periods (not just “as long as necessary”). Re-read it every time you add a processor, and put a lawyer over the final language every couple of years.
## The pattern
Nine of these ten issues are fixable by a single developer in under a day. Issue #10 (privacy policy) is the only one that needs a lawyer review on the final language. That is the SMB compliance opportunity in 2026: the bar is low because most sites never check.
See also: Reading your first Veracly report · Cookie banner audit checklist
## Common questions
How were these ten chosen? +
Engineering judgement, not a prevalence statistic. These are the findings our rule packs fire most often in practice, weighted by severity, and each maps to a specific named regulation rather than a vague "best practice." Nine are automated findings; the tenth, privacy policy clause coverage, is a manual check we include precisely because no scanner can settle it. All ten are fixable in code; none require redesign.
Are these in priority order? +
Roughly. We list the legal-exposure issues first (consent, missing legal pages, form labels) because those carry the largest fine surface. Severity in your own report depends on how many pages each issue affects on your site.
Does fixing all ten make my site compliant? +
No. It removes the most common and most easily evidenced failures, which is worth doing, but compliance is the long tail: accessibility statements, third-party widget review, the keyboard and screen-reader testing no scanner performs, and ongoing monitoring as your site changes. The top ten are the floor, not the ceiling.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- Multi-jurisdiction
### Multi-jurisdiction website compliance: one site, many laws
EU, UK, US, and Canadian visitors trigger different laws. Here is the practical playbook for satisfying GDPR, EAA, ADA, UK Equality Act, and AODA with one programme.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## How to verify a Veracly report is authentic
URL: https://veracly.app/blog/verify-veracly-report-authenticity
Published: 2026-05-12

Multi-jurisdiction
# How to verify a Veracly report is authentic
A compliance report is only useful if its reader trusts it. Every Veracly PDF is cryptographically signed and independently verifiable, for a defined window. Here is the mechanic, and the expiry, in plain English.
By Veracly Compliance Team · 2026-05-12· 6 min read
A compliance audit is a claim about a moment in time. The reader of the report, your developer, your lawyer, a regulator, a procurement team, has to trust that the claim is what Veracly actually issued, not something edited along the way. That trust is too important to rest on “we are a reputable vendor.” Every Veracly report carries a cryptographic proof anyone can verify in under a minute. Here is the mechanic.
## What gets signed
On every scan, we compute the SHA-256 digest of the exact PDF bytes about to be uploaded. We then sign a canonical record with Veracly’s private Ed25519 key and persist the signature in our audit ledger. The signature does not live inside the PDF (embedding it would be circular: the embedded bytes would change the digest and invalidate the signature). Instead, the PDF surfaces the scan UUID as a lookup key.
The record has seven fields, and all seven are inside the signature. If you are rebuilding it yourself, this is the part to get exactly right, a record missing a field produces signature_mismatch, which reads to a regulator as a forged report:
- v — schema version, currently the integer 2.
- issuer — pinned to the string veracly.app.
- scan_id — the scan UUID printed on the report.
- language — the locale of this report variant. Each language is a separately rendered PDF and is signed independently.
- pdf_sha256 — lowercase hex, no separators.
- issued_at — ISO 8601, UTC.
- key_id — the first 16 hex characters of sha256(public_key_raw_bytes), so a verifier can pick the right key after a rotation.
Canonicalization is a deliberately small subset of JCS: top-level object only, keys sorted in ASCII order, no whitespace, values JSON-escaped. Sorted, that puts issued_at first and v last, which is not the order above, so sort rather than transcribing. One historical wrinkle: anchors signed before 2026-07-31 may carry an eighth optional field, requested_by. We stopped writing it because the verify endpoint is unauthenticated and the field carried a free-scan requester’s email address. Where it is present it was signed, so it must be included when you reconstruct the bytes.
## The verification flow
Three steps. Anyone with the PDF can perform them:
- Read the scan UUID from the “Document integrity” block on the disclaimer page of the PDF.
- Compute the SHA-256 of the PDF on your local machine. On macOS / Linux: shasum -a 256 report.pdf. On Windows: Get-FileHash report.pdf -Algorithm SHA256.
- Visit veracly.app/verify/<uuid> . The page shows the canonical record we signed and the public key it was signed with. You compare the SHA-256 you computed to the one shown. If they match, the signature is valid and the bytes in front of you are the bytes we issued.
The public key is also published at veracly.app/.well-known/veracly-signing-key.json. Anyone who wants to do the full verification themselves, without trusting the rendering of the verify page, can pull the public key, fetch the signed record from veracly.app/api/verify/<uuid>, and run any standard Ed25519 verifier locally against the canonicalization rules above.
To be straight about one thing the security reviewers among you will check: our source repository is not public, and we should not imply otherwise. What is open is the part that matters for this claim, the verify page runs the same verification in your browser, so the code you are asked to trust is the code shipped to your machine, and everything it depends on, the public key, the signed record, and the retention policy, is served from documented, unauthenticated URLs. If you want the canonical-record spec in writing for a vendor review, mail support@veracly.app and we will send it.
## How long the verify URL stays live
This is the part most vendors leave out, so: verification is not permanent. The integrity block on every Veracly PDF states that the Verify URL is valid for 30 days from issue, and that is the number to plan against when you hand a report to somebody.
- Paid reports: no automatic expiry. The anchor is kept independently of the parent scan record, so it outlives the scan data when that is dropped at 12 months and the verify URL keeps resolving; the printed 30 days is a deliberately conservative floor, not the real ceiling.
- Free scans: the anchor is retired by a daily sweep 60 days after signing, and the rendered PDF is deleted from our storage on the same window.
A retired anchor is not a 404, and that distinction is the whole point. The sweep nulls the verification material and stamps the row; the endpoint then returns a record confirming that the report existed, when it was signed, which key signed it, and which retention rule retired it, with a link to the machine-readable policy at veracly.app/.well-known/veracly-retention.json. A regulator who saved the URL months ago gets a policy reference rather than something indistinguishable from a quiet purge.
Be clear about what survives retirement, though, because it is less than it sounds. The digest exists in exactly two places, the ledger anchor and our report record. The sweep clears the first and the same window deletes the second, so once a free-scan anchor retires there is no fingerprint left for anyone to compare against, us included. Proof-of-existence survives; proof-of-integrity does not. Support can reconcile a SHA-256 against the stored fingerprint using the Verification ID for as long as the fingerprint exists, which in practice means paid reports.
Two practical consequences. Do not paste a verify URL into anything that will be read later, a cover letter, a tender response, a trust page, without checking that it still resolves. And if a report is going to matter beyond its window, get it verified while the anchor is live and keep the counterparty’s confirmation, rather than assuming the check will still be there when they get round to it.
## Why this matters for an SMB
Most SMBs will never use the verification flow themselves. The customers that ask for proof of authenticity are downstream: an enterprise procurement team running a vendor security review, a regulator following up on a complaint, an insurer underwriting cyber liability cover, a B2B prospect doing due diligence before signing a contract.
When one of those parties asks, the answer is no longer “here is a PDF, please trust it.” The answer is “here is the PDF and the verify URL, confirm it independently.” That is a categorically different conversation.
## What we deliberately did not do
A few design choices worth naming, because the audit-ledger space has a lot of theater dressed as cryptography:
- We do not anchor to a public blockchain. A regulator does not want to learn about block heights to verify a compliance report. The well-known-URL plus Ed25519 keypair is the simplest construction that meets the actual requirement: independent verifiability without trusting Veracly.
- We do not embed the signature in the PDF. Tempting but circular. Any embedded value would either be a self-reference (the PDF says “my hash is X”, change the hash, change the PDF, mathematically broken) or a detached signature tucked in metadata that PDF viewers routinely strip on re-save.
- We do not require a Veracly account to verify. An authentication wall on a verification endpoint defeats the entire point of public-key cryptography. Authentication-gated audit trails are a controlled-narrative product; ours is not.
- We do not roll our own crypto. Ed25519 is the digital-signature algorithm specified in RFC 8032, standardised for SSH in RFC 8709, for TLS in RFC 8422, and for DNSSEC in RFC 8080. The underlying libraries have been reviewed by people more qualified than we are.
## What is coming next (phase 2)
The current ledger is per-scan: one signature per (scan, language), and it is queryable but not enumerable, you need the scan ID to look a record up. Two things are designed and not yet shipped. Treat them as roadmap, not as product:
- A documented key-rotation playbook published at the well-known URL. Every signing key would carry a validity window, and an old key’s public counterpart would stay published so historical reports remain verifiable. The key_id field already in the signed record exists to make this work.
- A transparency log of issued reports, so the population of signatures is itself auditable rather than only individual records. We would log the (scan_id, sha256, issued_at) triples and not the report contents. Until it ships, “is this the complete set of reports Veracly issued?” is a question our ledger cannot answer, only “is this specific report authentic?”
Not on the list, and consistent with the section above: a blockchain anchor. An earlier draft of this post floated a daily Merkle root posted to OpenTimestamps. It contradicted the design principle two paragraphs up and we dropped it rather than ship the contradiction.
See also: Reading your first Veracly report · Sharing reports with developers, lawyers, and regulators
## Common questions
Why does Veracly sign its reports? +
Because the value of an audit report depends on the reader trusting it. An unsigned PDF can be edited; a signed one cannot, any byte change invalidates the signature. The threat model includes both bad-actor tampering and accidental drift (re-saving a PDF in a viewer that re-encodes it).
Do I need a Veracly account to verify a report? +
No. The verify endpoint uses no authentication, the public key is published at a well-known URL, and the verification runs in your browser against bytes you can inspect. A regulator who has only the PDF can confirm authenticity without contacting Veracly.
How long does the verify URL keep working? +
Not forever, and the report says so itself. The integrity block printed on every PDF states that the Verify URL is valid for 30 days from issue. Behind that: paid-report anchors carry no automatic expiry and are kept independently of the parent scan record, so they outlive it when it is dropped at 12 months and the verify URL and the support fallback both keep working afterwards. Free-scan anchors are retired by a daily sweep 60 days after signing, and the free PDF is deleted from our storage on the same window. A retired anchor does not 404, it returns a record confirming the report existed, when it was signed, which key signed it, and which retention rule retired it, with a link to the published policy at veracly.app/.well-known/veracly-retention.json. But the fingerprint itself is erased at that point, from the ledger and from our report store, so nobody can check byte-integrity afterwards, including us. That is storage limitation working as intended, not a gap. If a free-scan report matters to you beyond 60 days, verify it while the anchor is live.
What changes if a signature does not verify? +
The PDF in front of you is not the one Veracly issued. Either it has been edited (intentionally or by a re-encoding viewer), or it was never issued by Veracly. The verify page tells you which scan UUID was originally signed; if that scan exists in our ledger but the bytes disagree, the file has been altered.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- Multi-jurisdiction
### Multi-jurisdiction website compliance: one site, many laws
EU, UK, US, and Canadian visitors trigger different laws. Here is the practical playbook for satisfying GDPR, EAA, ADA, UK Equality Act, and AODA with one programme.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## WCAG 2.1 vs 2.2: which version applies to me?
URL: https://veracly.app/blog/wcag-21-vs-22-which-applies
Published: 2026-05-12

Accessibility
# WCAG 2.1 vs 2.2: which version applies to me?
WCAG 2.2 is the current standard. EAA cites EN 301 549 which cites 2.1. ADA case law cites 2.0 and 2.1. AODA mandates 2.0. The standard and the law are not the same in 2026, and the gap matters.
By Veracly Compliance Team · 2026-05-12· 7 min read
Three WCAG versions are in active legal play in 2026. WCAG 2.0 (2008) remains the explicit mandate of AODA and Section 508 in the United States. WCAG 2.1 (2018) adds 17 criteria for mobile, low-vision, and cognitive disability access; it is the EAA’s de facto floor via EN 301 549. WCAG 2.2 (October 2023) adds 9 criteria around focus, drag interactions, help consistency, and authentication. Two regimes have already moved to it: UK public-sector bodies have been monitored against WCAG 2.2 AA since October 2024, and Australia’s Digital Experience Policy has required 2.2 AA of Commonwealth entities since 1 January 2025. The EU and the US have not followed yet.
The result: the standard and the law are out of sync, and the gap differs by jurisdiction. A WCAG 2.2 conformance claim is the best-practice posture and a future-proofed legal floor, but the question of which version is required is jurisdiction-specific.
## Jurisdiction-by-jurisdiction map
### European Union, EAA
The European Accessibility Act (Directive (EU) 2019/882, in force since 28 June 2025) does not name a WCAG version in its body. Article 15 directs implementation via harmonized standards. The current harmonized standard for ICT accessibility is EN 301 549 v3.2.1 (March 2021), which references WCAG 2.1 AA for web content.
The next revision is close. EN 301 549 v4.1.0 went to draft in November 2025; the version expected to be cited in the Official Journal is v4.1.1, around October 2026, and it tracks WCAG 2.2. Until that citation lands, the EU legal floor for web content under the EAA is WCAG 2.1 AA, but you are planning against a standard that moves in months, not years.
### United Kingdom, Equality Act 2010 + PSBAR
The Equality Act’s reasonable-adjustments duty does not name a version, and be careful with anyone who tells you a court has settled the point. There is no reported UK judgment on web accessibility, because these claims settle before judgment. What exists is regulatory guidance, principally the EHRC’s, which is not case law but is what a tribunal would be pointed at.
The Public Sector Bodies Accessibility Regulations 2018 (PSBAR) do not name a WCAG version either. They require the A and AA criteria via EN 301 549 “as amended from time to time,” which is a moving reference by design. In practice the Government Digital Service has monitored public-sector sites against WCAG 2.2 AA since October 2024. Private-sector sites remain judged under the Equality Act reasonable-adjustments duty, with 2.1 AA the conservative benchmark and 2.2 AA the direction of travel.
### United States, ADA Titles II and III
ADA Title III itself does not name WCAG. The standard that does exist is a Title II rule, not Title III: the Department of Justice’s April 2024 final rule at 28 CFR § 35.200 (Subpart H) requires WCAG 2.1 AA of state and local government websites and mobile apps. Its compliance dates were pushed back by a DOJ interim final rule on 20 April 2026, to 26 April 2027 for larger public entities and 26 April 2028 for smaller ones. Note the version it locks in: 2.1 AA, not 2.2.
For private-sector Title III defendants there is no rule at all, only litigation. Federal case law has cited both 2.0 and 2.1 AA as the technical standard; the Robles v. Domino’s line works on 2.0 AA as the de facto bar, and more recent cases have moved to 2.1.
### Canada, AODA (Ontario)
Ontario’s Integrated Accessibility Standards Regulation §14 explicitly mandates WCAG 2.0 AA for public-sector and large private-sector organizations (over 50 employees). The regulation has not been amended to track 2.1 or 2.2, so the AODA legal floor is 2.0. Practical posture: target 2.1 AA for parity with the rest of the country’s ACA (Accessible Canada Act) trajectory.
### Australia, DDA + the DTA policy
The Disability Discrimination Act 1992 references no technical standard whatsoever, and there is no statutory WCAG mandate for the Australian private sector. The version question is answered by policy instead of statute: the Digital Transformation Agency’s Digital Experience Policy has required WCAG 2.2 AA of non-corporate Commonwealth entities since 1 January 2025 , and the Australian Human Rights Commission’s April 2025 Guidelines on equal access to digital goods and services point private organisations at 2.2 AA as the benchmark for meeting the DDA. Australia is therefore ahead of the EU and the US on version, not behind them.
## The new criteria in WCAG 2.2
The 9 success criteria added in 2.2:
- 2.4.11 Focus Not Obscured (Minimum) , keyboard-focused elements must not be entirely hidden behind sticky headers, cookie banners, or other overlays.
- 2.4.12 Focus Not Obscured (Enhanced) , AAA version of the above.
- 2.4.13 Focus Appearance , focus indicators must meet minimum size and contrast (AAA, not required for AA).
- 2.5.7 Dragging Movements , any drag interaction must have a single-pointer alternative (a button, a tap).
- 2.5.8 Target Size (Minimum) , interactive targets must be 24×24 CSS pixels or have sufficient spacing.
- 3.2.6 Consistent Help , help mechanisms appear in the same relative order on every page.
- 3.3.7 Redundant Entry , information the user already entered must be auto-populated or available for selection on subsequent forms.
- 3.3.8 Accessible Authentication (Minimum) , no cognitive-function-only authentication (no “solve a CAPTCHA puzzle” without an alternative).
- 3.3.9 Accessible Authentication (Enhanced) , AAA version.
Most of the new AA criteria (2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7, 3.3.8) are cheap to satisfy on most sites. The focus-not-obscured rule is the one that catches most teams off-guard: a sticky header that overlaps a focused link is a 2.4.11 failure that did not exist under 2.1.
## What Veracly tests against
Veracly assesses every scan against WCAG 2.2 AA — the 2.0, 2.1 and 2.2 A/AA rule sets plus axe-core’s best-practice pack, run together as one superset. It is worth being precise about what that buys you, because the honest answer is narrower than the headline.
In the automated toolchain the only machine-testable 2.2 AA criterion is SC 2.5.8 Target Size (Minimum) , and we do score it. A target-size failure deducts from your EAA, ADA, UK Equality Act and AODA scores exactly as a 2.1 failure would. It is not quarantined as an above-floor nice-to-have, so if you are reading a Veracly score against an EU or US legal floor of 2.1 AA, be aware that a 2.2-only finding is already inside the number.
The other eight 2.2 additions — focus-not-obscured, focus appearance, dragging alternatives, consistent help, redundant entry, accessible authentication — are not machine-testable. Every Veracly report carries a version-labelled inventory of all WCAG 2.2 Level A and AA criteria, marking each as partly automated, an automated review signal, or not automated, and stating what a person still has to check. The five Level A and AA criteria among them appear in that inventory as not automated: treat them as your own manual work, and do not read a clean Veracly report as evidence you have met them.
One jurisdiction, and only one, gets a separate legal-floor number: AODA. On that card the headline score is the full WCAG 2.2 AA superset, so it can be compared like for like with your EAA and ADA cards, and next to it sits a legal-floor score that strips the 2.1- and 2.2-only deductions and leaves WCAG 2.0 AA — Ontario’s actual statutory requirement under IASR §14. That paired display is a direct response to this version mismatch: one number is what most readers expect to see, the other is what an Ontario regulator will measure. No other rule pack emits a second number, so on the EAA, ADA, UK and Australian cards there is one score and it is the 2.2 superset.
## Planning recommendation
Target 2.2 AA. In the UK public sector and for Australian Commonwealth entities it is already the requirement rather than the aspiration. Everywhere else the 2.1 AA legal floor is a floor, not a ceiling, and the 2.2 work is small enough that splitting the deployment is rarely worth the engineering coordination. The exception: if your team is already at 2.1 AA and considering whether to budget for 2.2, prioritize the high-leverage 2.2 criteria (focus-not-obscured, target size, accessible authentication) over the others.
See also: WCAG 2.1 AA accessibility audit explained · Does my SMB need to comply with the EAA?
## Common questions
Should I aim for 2.1 AA or 2.2 AA? +
2.2 AA. It is a superset of 2.1, and the additional 9 success criteria are mostly low-effort (visible focus indicator, drag alternatives, consistent help, redundant entry, accessible authentication). Hitting 2.2 satisfies every jurisdiction’s 2.1 or 2.0 requirement plus future-proofs you.
What does the EAA actually require? +
The EAA itself does not name a WCAG version. It defers to harmonized standards, primarily EN 301 549 v3.2.1, which references WCAG 2.1 AA for web content. The next EN 301 549 revision is expected to track WCAG 2.2; until then, the legal floor in the EU is 2.1 AA, with 2.2 strongly recommended.
Why does AODA still mandate 2.0? +
Ontario’s Integrated Accessibility Standards Regulation §14 explicitly requires WCAG 2.0 AA. The regulation has not been amended to reference 2.1 or 2.2. As a result, the AODA legal floor is 2.0, but practical compliance with the spirit of the regulation typically targets 2.1 AA.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Accessibility
### WCAG 2.1 AA accessibility audit explained (for SMB websites)
Level AA is the bar every regime converges on, but no two of them name the same WCAG version. Here is what an audit actually checks, what only humans can verify, and the five fixes that move the needle on most SMB sites.
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## ADA website compliance audit (USA): a 2026 SMB guide
URL: https://veracly.app/blog/ada-website-compliance-audit
Published: 2026-04-27

ADA
# ADA website compliance audit (USA): a 2026 SMB guide
ADA website accessibility lawsuits hit a record in 2025: 5,114 filings, 3,195 of them federal. SMBs are the main target. Here is how the law applies, the WCAG 2.1 AA bar, and the realistic SMB defence plan.
By Veracly Compliance Team · 2026-04-27· 8 min read
The Americans with Disabilities Act of 1990 has become, over the last decade, the single largest source of website-related litigation against SMBs in the United States. 5,114 website accessibility lawsuits were filed in 2025 — 3,195 of them in federal court, the rest in state courts, overwhelmingly New York and California. That is a genuine record; federal filings had dipped in 2024 before climbing back. The plaintiff bar has shifted decisively from large enterprises to SMBs whose insurance and settlement posture is more predictable. An ADA website compliance audit is how you find out where you stand before someone files.
## How the ADA actually applies to websites
The ADA itself does not mention websites, it predates the modern web. Title III requires “places of public accommodation” to be accessible to people with disabilities. The litigation question for thirty years has been whether a website is a “place.”
The current state of the law:
- DOJ position : websites of public accommodations are covered. Reaffirmed in 2022 guidance and consistent in enforcement actions.
- 1st and 7th Circuits : the broad view. A website can be a place of public accommodation on its own, with no physical location behind it.
- 3rd, 5th, 6th, 9th and 11th Circuits : a nexus to a physical place of business is required. The 11th went furthest in Gil v. Winn-Dixie (2021), holding that a website is not itself a place of public accommodation; that opinion was vacated as moot, so it binds no one, but it shows where the panel sat.
- 2nd Circuit : no appellate holding, and the district courts within it are split — which has not slowed anything down, since the Southern and Eastern Districts of New York remain the busiest filing venues in the country.
- 4th Circuit : no controlling holding either way.
- State laws : California’s Unruh Civil Rights Act, New York State and City human-rights laws, and similar laws in Florida and Massachusetts often provide an independent basis for suit, including against online-only businesses, with lower thresholds than the federal ADA.
## The technical bar
The ADA does not specify a technical standard, but DOJ guidance, court rulings, and settlement agreements consistently reference WCAG 2.1 Level AA (sometimes 2.0). The April 2024 DOJ rule for state and local governments (ADA Title II) mandates WCAG 2.1 AA explicitly; while it does not bind Title III, courts and plaintiffs routinely apply it as the de facto standard.
For SMB compliance work, the practical consequence is that the same WCAG 2.1 AA audit that satisfies the EAA, the UK Equality Act, and AODA also satisfies ADA Title III. One technical audit, multiple jurisdictions.
## What plaintiffs actually target
Plaintiff complaints follow a recognisable pattern. The boilerplate alleges a series of specific WCAG failures observed during a screen-reader test, typically:
- Images without alt text or with empty alt on meaningful images
- Links and buttons with no accessible name (icon-only buttons are a major target)
- Form fields without labels
- Insufficient colour contrast
- Keyboard traps in modals or carousels
- Improper heading structure
- Inaccessible PDFs linked from the site
- Video without captions
Half of that list is machine-testable and half is not, and it is worth knowing which half is which before you treat a green scan as a defence.
Caught outright: missing accessible names on links and buttons, and missing form labels. Those are structural facts about the DOM, and axe-core settles them with no judgement call.
Caught in part: alt text and colour contrast. A machine can see that an alt attribute is absent. It cannot see that an empty one has been put on an image that carries meaning — to any automated check, a decorative image and a mislabelled product photo look identical. Contrast is the same story at the edges: text over a photograph, a gradient, or a translucent overlay comes back from axe-core as “needs review” rather than “fail,” and the report lists those as inconclusive and does not score them. Reporting a maybe as a finding would make every other number in the report worth less.
Not caught at all: keyboard traps, heading semantics, PDFs, and captions on embedded video. We never drive the keyboard during a scan, so a trap in a modal or a carousel is invisible to us — SC 2.1.2 sits on our manual-criteria list and scores neutral rather than pretending. Whether an <h3> is the right heading is a question about meaning, not markup. We do not crawl or open linked PDFs. And our caption rule reads native <video> and <audio> elements, so a YouTube or Vimeo embed with no captions produces no finding.
That is the honest shape of it, and it is still a strong position. The automated half is the half the plaintiff bar screenshots into the complaint, and it is the half you can re-check on every deploy for the rest of the site’s life. A site that fails it is a cheap filing. A site that passes it has to be litigated the hard way, by someone who actually sat down with a screen reader. Run the scan first because it is fast and repeatable, then spend your manual hours where the machine is blind: the keyboard pass, the heading outline, and the PDFs.
## The accessibility-overlay trap (US-specific)
US SMBs are the primary market for accessibility overlay vendors, accessiBe, AudioEye, UserWay. The pitch is that a single line of JavaScript creates ADA compliance and immunity from suit. The reality:
- FTC enforcement against accessiBe in January 2025: USD 1 million settlement for misleading marketing about overlay-based compliance.
- Plaintiff targeting : plaintiff firms have publicly stated they specifically target overlay-using sites because the failure pattern is so predictable. The Web Accessibility Initiative and the National Federation of the Blind have both issued statements warning against overlays.
- Litigation against a vendor : BloomsyBox.com LLC sued UserWay in the District of Delaware in July 2024 over its overlay marketing claims. In February 2026 a magistrate judge recommended granting the motion to dismiss only in part: the Delaware Consumer Fraud Act and negligent-misrepresentation claims survive, while breach of contract and the Magnuson–Moss Warranty Act claims do not.
Removing an overlay reduces lawsuit exposure. Adding one increases it.
## The realistic SMB defence plan
Five steps, in order, that close most of the gap.
- Run a baseline WCAG 2.1 AA audit. An automated scan only covers the machine-testable slice — roughly a third of WCAG success criteria are machine-testable at all — but the high-severity defects cluster there. Fix those first.
- Manual screen-reader test of your top 10 pages. Home, product pages, cart, checkout, account, contact. Two-hour exercise with NVDA or VoiceOver.
- Publish an accessibility statement. Specify the standard you target (WCAG 2.1 AA), the date of last review, known limitations, and a feedback channel. The plaintiff bar prefers easy targets; a credible statement and a real feedback mechanism shift the calculus.
- Set up continuous monitoring. A WCAG-clean site stays clean only until the next deploy. Most regressions ship six weeks after the audit.
- Document everything. If a complaint or lawsuit comes in, the audit-and-remediation log is your defence. Settlements depend heavily on whether the defendant can show good-faith effort.
## Cost ranges
From SMBs we work with:
- Defence of a single ADA web lawsuit : USD 5,000 to 25,000 settlement, plus 2 to 6 weeks of remediation work. Repeat suits common after first settlement.
- One-time consultant audit : USD 5,000 to 15,000 depending on site size.
- Continuous scanning + ad-hoc consulting : USD 100 to 500 per month for tooling plus periodic professional review.
The ROI of pre-emptive auditing over reactive settlement is usually clear after the first lawsuit avoided.
## How Veracly approaches ADA
One accessibility analysis, cited against whichever frameworks are actually in scope. Which rule packs run is decided by the visitor countries on the scan: the United States selects the ADA Title III pack, Great Britain the UK Equality Act, Canada AODA, and any of the 27 EU member states the EAA. The underlying accessibility testing is identical across all of them — axe-core against the WCAG 2.2 AA superset, meaning the 2.0, 2.1 and 2.2 A and AA rule sets together, which clears the 2.1 AA bar the ADA plaintiff bar actually applies. What changes is the statute cited and how each regime weights severity. So “all four at once” is not a thing we will promise you: it needs US, GB, CA and an EU state all listed on the same scan. A free scan resolves one country, Starter one, Growth three, and Pro and Agency have no cap.
Every violation cites the relevant WCAG criterion, the legal framework it engages, and the developer-level fix. Two limits worth stating plainly, because the CTA below is for the free tier: a free scan covers one page , explains only its top three findings, and generates no developer fixes at all — those are paid-tier work. And we do not write your accessibility statement — we tell you when one is missing and point you at the W3C generator, because a statement that a scanner drafted is a statement nobody read. What you get for the litigation file is the report itself: dated, reproducible, and worth having a run of. Run a free scan .
See also: WCAG 2.1 AA accessibility audit explained · EAA compliance for SMBs: what changes June 2025 · What is a website compliance audit?
## Common questions
Does the ADA cover websites? +
The Department of Justice has affirmed that ADA Title III applies to websites of public accommodations, and no federal circuit disputes that a website tied to a physical business is covered. They split on online-only businesses. The 1st and 7th Circuits read "place of public accommodation" broadly enough that a website can be covered standing alone. The 3rd, 5th, 6th, 9th and 11th require a nexus to a physical location. The 2nd Circuit has no appellate holding and its district courts are split; the 4th has no controlling holding either. Practically, if your business has US customers, treat your site as covered.
What technical standard does the ADA require? +
There is no formal technical regulation under Title III. Courts and DOJ settlements consistently reference WCAG 2.1 (sometimes 2.0) Level AA. The April 2024 DOJ rule for state and local government (Title II) explicitly mandates WCAG 2.1 AA, same standard the SMB plaintiff bar applies under Title III.
How much do ADA website lawsuits cost? +
Settlements typically run USD 5,000 to 25,000 plus the cost of remediation. Defending one through trial is far more expensive, most defendants settle. Repeat lawsuits against the same business after settlement are common, which is why an audit-and-fix programme matters more than a one-off settlement.
Do SMB businesses really get sued? +
Yes. UsableNet counted 5,114 website accessibility lawsuits in 2025, 3,195 of them federal and the rest in state courts, mainly New York and California. The majority targeted SMB e-commerce, professional services, and hospitality websites. Volume is concentrated in New York, Florida, and California, but plaintiffs have filed nationwide.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.
- Accessibility
### WCAG 2.1 AA accessibility audit explained (for SMB websites)
Level AA is the bar every regime converges on, but no two of them name the same WCAG version. Here is what an audit actually checks, what only humans can verify, and the five fixes that move the needle on most SMB sites.

---

## What is a cookie banner audit? (2026 checklist)
URL: https://veracly.app/blog/cookie-banner-audit
Published: 2026-04-27

Cookies
# What is a cookie banner audit? (2026 checklist)
A cookie banner audit checks design, defaults, dark patterns, and what loads before any consent gesture. The Accept and Reject paths themselves have to be walked by hand. Here is the 2026 checklist.
By Veracly Compliance Team · 2026-04-27· 7 min read
The cookie banner is the single most-audited compliance surface on a website. It is the first thing a regulator sees, the easiest thing for a complainant to screenshot, and the source of most public GDPR fines. A cookie banner audit is the check that tells you whether yours would pass scrutiny.
This article is the 2026 checklist, what auditors look at, the dark patterns regulators have specifically called out, and the design that consistently passes review across the EU and UK.
Run a free cookie banner audit on your own site
Veracly loads your live banner and records the third-party tags, cookies and storage keys that appear before any consent gesture, then inspects the banner markup itself for reject parity and pre-ticked categories, citing CNIL 2020-091 and the EDPB Cookie Banner Taskforce. A free scan covers one page, and we never click your banner, so the Accept and Reject paths in section 5 stay yours to walk.
Scan your website →
## What an auditor checks, in order
### 1. The first impression
- The banner appears before any non-essential script fires. (Verify with a network tab or a scanner.)
- The banner is visible without scrolling on the device the user is on, including narrow mobile viewports. Check this by hand on a real phone width: automated scanners, ours included, render at a single desktop viewport and will never see a banner that only breaks at 375px.
- The banner does not auto-close. Implied consent (closing the banner, scrolling, continuing to use the site) is not consent.
### 2. The choices on the first layer
- Accept all and Reject all buttons appear at the same level, same screen, same prominence, comparable visual weight.
- A third option for granular settings (Manage preferences) is visible but not the only alternative to Accept.
- No pre-checked categories. All non-essential categories default to off until the user explicitly toggles them on.
### 3. The granular layer
- At minimum: strictly necessary , functional , analytics/statistics , advertising/marketing . Many regulators expect finer categories, e.g., separate toggles for personalisation and social media.
- Each category has a plain-language description of what it does and which vendors are involved.
- No legitimate-interest toggle for advertising. The IAB’s TCF v2.0 originally allowed it; the Belgian DPA found that pattern unlawful in 2022.
- A Save preferences button that respects partial choices.
### 4. Withdrawal
- A persistent “Cookie settings” link, ideally in the footer, opens the same banner so the user can change their choice.
- Withdrawal is as easy as the original consent, one click, same modal.
### 5. Behavioural verification (do this one by hand)
This is the step no scanner does for you, and it is worth understanding why rather than assuming a tool has covered it. Testing what happens after Accept or after Reject means clicking Accept or Reject. A click is a consent gesture. An automated crawler that presses the button has destroyed the measurement everyone actually needs, which is what your site loads for a visitor who has not chosen anything yet. Veracly makes that trade deliberately: we take the pre-consent reading and leave the post-consent paths to you. Open a fresh private window and reload after each path:
- Accept all , every script fires; cookies match the cookie policy.
- Reject all , only strictly-necessary cookies; no analytics, no advertising, no third-party widgets that set cookies.
- Granular partial , only the categories the user toggled on fire.
Most banners pass on Accept and fail on Reject. A common failure: a Google Tag Manager container that loads regardless of consent, with individual tags loaded inside it that also fire regardless. The fix is to gate the entire GTM container behind consent or to move the consent check into every tag.
## The dark patterns regulators have specifically called out
The EDPB Cookie Banner Taskforce published a final report in January 2023 setting out where the national authorities found common ground on complaints about banners. It is careful to say what it is not: a common denominator, a minimum threshold, and explicitly not something that prejudges any authority’s own analysis under its national law. Treat the list below as the floor rather than the standard, and check your own regulator for anything stricter.
- No Reject button on the first layer.
- Pre-ticked boxes.
- Deceptive button design, where the styling itself steers the choice. Read the scope here precisely, because it is widely overstated: the taskforce refused to impose any general standard on colour or contrast, and condemns contrast only where the text becomes effectively unreadable. Greying Reject into illegibility is the named defect. “Accept is green and Reject is red” is not, on its own, an EU rule.
- Misleading language, “Accept and visit” vs. “Reject,” or “by clicking, you accept.”
- Categories described in legal jargon that an average user cannot understand.
- Legitimate-interest justification for advertising.
- Cookie wall (you must accept to view content) on services where alternatives are not available.
- Re-prompting the user on every page load after they have rejected.
## What good looks like
A banner that consistently passes audits has the following structure:
- Plain-language summary: “We use cookies to make this site work and, with your permission, to understand how it’s used and improve it.”
- Three buttons of equal visual weight: Accept all , Reject all , Manage preferences .
- Manage preferences opens a modal with toggles for each non-essential category, defaulting to off, with vendor lists and purpose descriptions.
- A Save preferences button alongside the same three top-level choices.
- A persistent footer link labelled “Cookie settings” that re-opens the modal.
- An accessible cookie policy page that lists every cookie, name, purpose, duration, first/third party, and is regenerated when the inventory changes.
## How Veracly audits banners
Veracly visits your site as a fresh user and records the third-party network calls, cookies, and storage keys that appear before any consent gesture. Requests to your own hostname are not recorded, and storage is captured as keys and database names, never values. It then inspects the banner markup itself: reject-button parity against the accept button, rejects hidden behind a “Customize” submenu or pushed off-screen, and pre-ticked category checkboxes. Banner findings carry one citation pair, CNIL deliberation 2020-091 and the EDPB Cookie Banner Taskforce report, plus the developer fix. We do not tailor the citation to your national regulator, and where the banner’s buttons cannot be enumerated at all, the parity verdict is withheld rather than guessed. Run a scan to audit your current banner.
See also: What is a GDPR cookie audit? · Tracking pixel audit: GDPR & ePrivacy
## Common questions
Is a cookie banner legally required? +
Yes, where non-essential cookies or trackers are used and EU/UK visitors can reach the site. The legal basis is Article 5(3) of the ePrivacy Directive plus Article 7 GDPR. The banner is the mechanism through which consent is captured.
What makes a banner non-compliant? +
The most common failures: Reject-All hidden behind a settings link, pre-ticked categories, tracking that fires before the user interacts, no granular toggles, language like "by using this site you consent", and no easy way to withdraw consent later.
Do I need both Accept and Reject buttons on the same level? +
In France, yes: CNIL deliberation 2020-091 requires that where consent can be given at the first level with one click, refusal can be too. The EDPB Cookie Banner Taskforce reported that a vast majority, not all, of national authorities take the view that a refusal option belongs on any layer carrying a consent button. Italy is a partial exception worth knowing: the Garante (provvedimento 231/2021) accepts the X close control as a valid first-layer refusal. The design that satisfies every authority: equal-weight Accept and Reject buttons on the first layer, plus a granular settings link.
What about the "Reject All" button colour? +
There is no EU-wide colour rule. The EDPB Cookie Banner Taskforce expressly declined to impose a general standard on colour or contrast; the only contrast it condemns outright is text that cannot be read against its background. Italy is the strict outlier, where the Garante asks for equivalent visual evidence for both options. The design that is safe everywhere is two controls that both read as buttons, at comparable size and weight, differing in colour rather than in prominence. Greying out Reject or styling it as body text is the pattern that attracts complaints.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Cookies
### Cookie consent in Australia: what the law actually requires
Australian businesses install consent banners because European advice tells them to. There is no Australian rule requiring one for ordinary analytics. But sensitive information is a real exception, and the Privacy Commissioner enforced it against tracking pixels in June 2026.
- Cookies
### GDPR vs ePrivacy: which one actually governs cookies?
GDPR did not invent the cookie banner. ePrivacy did, nine years earlier. Understanding which framework requires what is the difference between a defensible CMP setup and a banner that fails on first inspection.
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.

---

## EAA compliance for SMBs: what has applied since 28 June 2025
URL: https://veracly.app/blog/eaa-compliance-smb
Published: 2026-04-27

EAA
# EAA compliance for SMBs: what has applied since 28 June 2025
The EAA has applied to private companies in the EU since 28 June 2025. Here is the SMB-shaped version: who is in scope, who is exempt, and the four things you actually need to do.
By Veracly Compliance Team · 2026-04-27· 8 min read
The European Accessibility Act (EAA, Directive 2019/882) has applied to private-sector products and services since 28 June 2025 . That is now more than a year ago. Member states have transposed it into national law and are publishing enforcement guidance. The shift it created for SMBs was significant: accessibility, which used to be a public-sector and large-enterprise concern, became a normal product-quality obligation for any company selling to EU consumers.
This article is the SMB version. Who is in scope, who is exempt, what you need to do, and what enforcement actually looks like now that the deadline is behind us.
## What the EAA actually requires
For websites, mobile apps, and digital services, the EAA points to EN 301 549 , the harmonised European standard. EN 301 549 in turn references WCAG 2.1 Level AA for web content. So if your site meets WCAG 2.1 AA, it meets the EAA technical bar for the web.
Beyond the technical conformance, the EAA also requires:
- An accessibility statement describing how the service meets the requirements, what is not accessible and why, and how to provide feedback.
- A feedback mechanism so users can report inaccessibility and request alternatives.
- Documentation showing how the service was designed and tested for accessibility.
- Plain-language descriptions of the accessibility features in the terms of service or pre-purchase information.
## Who is in scope
The EAA applies to specific products and services. For SMBs, the relevant categories are:
- E-commerce , any online store selling consumer products or services to EU consumers.
- Consumer banking services including payment accounts and online banking interfaces.
- E-books and dedicated e-reading platforms.
- Transport services , ticketing, real-time information, websites and apps for air, rail, water, and bus services.
- Electronic communications services and emergency communications (covered separately by the EECC).
- Audiovisual media services , websites and apps for streaming, video on demand, and broadcaster catch-up.
## The microenterprise exemption
Article 4(5) of the EAA exempts microenterprises providing services from the substantive accessibility requirements. The EU definition of a microenterprise: fewer than 10 employees AND annual turnover or balance sheet under €2 million.
Two important caveats. First, the exemption is for service-side obligations only; microenterprises that manufacture products covered by the EAA still must comply, with lighter documentation duties. Second, the exemption does not cover the underlying obligations under the UN Convention on the Rights of Persons with Disabilities, which many member states have transposed into national anti-discrimination law that applies regardless of company size. In Germany, France, and Spain in particular, expect national accessibility law to bite below the EAA threshold.
## What enforcement looks like
Each member state designates national surveillance authorities. Penalties are set in national law and vary widely:
- Germany (BFSG, Barrierefreiheitsstärkungsgesetz): fines up to €100,000 per violation, plus the right of the authority to order the service taken offline.
- France : fines up to €50,000 for repeated breaches, plus per-day penalties for ongoing non-compliance.
- Italy, Spain, Netherlands : variable fines plus injunctions; the Netherlands has been particularly active in pre-EAA enforcement.
The awareness window that many companies were counting on in 2025 has closed. Enforcement so far is predominantly complaint-driven rather than sweep-driven, which is how most EU market-surveillance regimes begin, and authority-initiated checks land first in the highest-volume consumer sectors: e-commerce, banking, travel. For an SMB the decisive factor is usually not the initial finding but whether the complaint was answered in good faith, with a dated remediation plan, or ignored.
## What SMBs should actually do
If you are in scope and not a microenterprise, the practical preparation is short.
- Run a baseline WCAG 2.1 AA audit. Get the list of issues, prioritise the high-severity ones, fix them. Plan for a multi-sprint effort if your site has never been audited before.
- Publish an accessibility statement. Even if the site is not yet fully accessible, the statement is a hard requirement. Be honest about what works and what doesn’t, regulators reward good faith and punish silence.
- Add a feedback channel. A specific email address (e.g., accessibility@yourdomain.com) and a stated SLA (e.g., respond within 5 business days). Document the responses; you may need them later.
- Set up continuous monitoring. The most common failure pattern is not a non-compliant launch, it is an EAA-compliant site that introduces a regression six months later when marketing adds a new component or product launches a new flow. Continuous scanning is how SMBs stay above the line without staffing a compliance team.
## The accessibility-statement template
A workable template covers: which standard you target (WCAG 2.1 AA), the date of your most recent self-assessment, known limitations and the timeline to fix them, the feedback channel, and the alternative methods of access available to users who cannot use the website. Member-state authorities (Germany’s BFIT-Bund, France’s DINUM, the Netherlands’ Logius) publish official templates; pick one and adapt it.
## How Veracly approaches the EAA
Veracly generates an EAA-aligned report from the same scan that produces your GDPR, ADA, and UK Equality Act reports, and each issue maps to the specific clause and the recommended developer fix. Be precise about what that scan is: axe-core run against the machine-testable WCAG 2.1 and 2.2 A and AA rules, at a single 1280×800 desktop viewport. It is not a test against EN 301 549 as a whole — that standard also covers hardware, documentation, support services, and real-time text — and it is not a conformance assessment. Keyboard operation, PDFs, third-party video embeds, and the WCAG criteria that are not machine-testable stay on your manual list, and we say so in the report rather than scoring them silently.
On the accessibility statement, the scan tells you whether you have one, not what it says. We check that a statement exists and is reachable on your own domain; if it is missing you get a critical finding pointing at the W3C’s statement generator. We do not draft the statement for you, because the conformance status, the known limitations, the remediation timeline, and the competent enforcement contact are claims only your organisation can make — and a generated claim about your own conformance is the one thing a regulator will actually test. Run a free scan : it covers one page, on any tier the analyzers are identical, and the paid tiers add pages, AI explanations for every finding rather than just the top three, evidence screenshots and generated remediation.
See also: WCAG 2.1 AA accessibility audit explained · What is a website compliance audit?
## Common questions
Since when has the EAA applied? +
Since 28 June 2025. Two transitional rules in Article 32 are routinely misquoted. Article 32(1) is about service continuity: providers may keep providing services using products they were lawfully using before 28 June 2025, until 28 June 2030, and service contracts agreed before 28 June 2025 may run unchanged until they expire, but no longer than five years from that date. Article 32(2) is an optional member-state derogation for self-service terminals: they may stay in use until the end of their economically useful life, capped at 20 years from entry into use, not a fixed 2045 date. A terminal that entered use in 2012 must go by 2032. Products placed on the market before 28 June 2025 are simply outside the requirements; they are not on a compliance clock.
Are small businesses exempt from the EAA? +
Microenterprises (under 10 employees and under €2M annual turnover) that provide services are exempt from the service-side obligations. Microenterprises that manufacture products are not exempt, they have lighter documentation duties but still need to comply on substance.
Which sectors does the EAA cover? +
Consumer banking services, e-commerce, e-books, electronic communications, audiovisual media services, transport ticketing and information services, and a list of products including computers, smartphones, ATMs, ticketing machines, and TV equipment.
What is the technical standard? +
EN 301 549 is the harmonised standard. For websites and mobile apps, EN 301 549 references WCAG 2.1 Level AA, which is the practical bar most SMBs will be measured against.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- EAA
### Does my SMB really need to comply with the European Accessibility Act?
The EAA microenterprise exemption is widely cited and widely misunderstood. It does exempt a microenterprise online shop from the service requirements. The limits are on the product side, in national law, and in the definition itself.
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## Free website compliance scan: what to look for (and what to ignore)
URL: https://veracly.app/blog/free-website-compliance-scan
Published: 2026-04-27

Multi-jurisdiction
# Free website compliance scan: what to look for (and what to ignore)
Most "free compliance scanners" are lead-gen tools dressed as audits. Here is the difference between a useful free scan and a marketing trick, and what to do with the results.
By Veracly Compliance Team · 2026-04-27· 6 min read
Search for “free website compliance scan” and you will find a hundred tools. Some are useful diagnostic instruments. Many are lead-generation funnels for consulting firms or overlay vendors, designed to produce alarming reports that drive sales calls. This article is the buyer’s guide.
## What a useful free scan should do
A scan that earns the user’s trust does five things:
- Tests against named criteria. WCAG 2.1 AA success criteria, GDPR article references, ePrivacy rules. Not vague labels like “risk score.”
- Captures network traffic on first load. The single most useful GDPR-cookie test only works if the scanner waits no more than a second before snapshotting cookies and requests.
- Differentiates severity. A missing form label is a high-severity accessibility issue with legal exposure; a missing alt on a decorative divider is not. Know the limit here: no automated tool can actually tell those two images apart. Every one of them, ours included, tests whether the attribute is present, never whether the image mattered. Tools that lump all findings together produce useless “500 violations” reports; tools that claim to know which images are decorative are guessing.
- Provides specific remediation. The exact element selector and the code change needed. Not “Improve color contrast.”
- Says what it can’t check. No automated tool catches all WCAG issues; honest scanners say so. Tools that claim 100% coverage are misleading.
## Red flags in free scans
“Your site is X% non-compliant.” A single percentage hides severity differentials. A site with 5 warnings can score lower than one with 1 critical error.
“Your site is at risk of a $75,000 lawsuit.” Threat language designed to drive sales. Real audits cite specific exposure based on jurisdiction-specific fine schedules.
“We can fix all your accessibility issues automatically.” The accessibility-overlay claim. The FTC has fined for this; do not engage.
No mention of WCAG criteria. If the scan does not name 1.4.3 Contrast (Minimum) when it flags a contrast issue, the report cannot be acted on.
No mention of jurisdiction. “You have GDPR violations” is useless if you have no EU visitors and unhelpful if you do not know which articles apply.
## How to read the results
Treat any free scan as a triage signal, not a verdict. The questions that matter:
- What are the high-severity issues? Form labels, missing alt attributes, contrast on body text, unnamed links and buttons, pixels firing pre-consent. Fix these first. Keyboard traps and focus visibility belong on the same priority list, but they will not appear in any automated report, because no scanner presses Tab.
- What does my cookie inventory look like? Compare it to your published cookie policy yourself. Mismatches are the fastest way to fail a regulator audit, and no scanner we know of, ours included, runs that comparison for you.
- Are required legal pages present and reachable? Privacy policy, accessibility statement, and, in Germany and Austria, an imprint. Expect presence checks and nothing more: a cookie policy usually gets folded into the privacy check rather than graded on its own, and no scanner reads any of these documents for content.
- Is the issue list specific enough to action? If your developer cannot fix the issue from the report, the scan was a marketing exercise.
## What to do with the report
One workflow that consistently produces results for SMBs:
- Run the scan, export the issue list.
- Triage: high-severity legal-exposure issues first, then medium, then warnings.
- File one ticket per issue with the specific selector and the developer fix from the report. Do not file “fix all accessibility issues.” That ticket will sit forever.
- Re-scan once the batch is deployed, not after each individual fix. The diff confirms the issues are resolved and catches regressions introduced along the way. Check your tier’s limits first: Veracly’s free scan allows one run per email address per rolling seven days, so a fix-by-fix loop will hit the rate limit.
- Set up a recurring scan cadence. Weekly is the realistic SMB default; daily is valuable for sites with active marketing experimentation.
## Veracly’s free scan
Measured against the list above, here is ours. The free scan covers one page , one run per email address per rolling seven days. It tests against WCAG 2.1 AA via axe-core plus five custom DOM rules, records cookies, storage writes and third-party requests on first load before any banner interaction, matches those requests against a hand-curated registry of 69 tracker vendors, and checks that a privacy policy, an accessibility statement and, in Germany and Austria, an imprint exist on your own domain. Every finding cites the specific WCAG criterion or regulation article.
Which rule packs you are graded against depends on where your visitors are, not on what you paid. A free scan takes the single market you declare on the form and returns the framework that matches it: EAA and GDPR for an EU site, UK Equality Act and UK GDPR for a British one. Multi-country scope, and with it ADA or AODA alongside the European packs, comes from configuring visitor countries on a paid plan. The analyzers, the rule packs and the score formula are identical either way. What the free tier leaves out is AI explanation on every finding rather than only its top three, plus the evidence screenshots and the copy-paste remediation, which are generated on paid scans only.
And since we made it a criterion, here is what the scan cannot detect. No key is ever pressed, so keyboard traps, focus order and focus visibility go untested. PDFs are not scanned at all. Third-party video embeds get no caption check. Checks axe cannot decide are listed in the report as inconclusive and are not scored; contrast on text over images and gradients is the usual case. There is one viewport, 1280×800, so reflow and mobile-only defects are never exercised. Every Veracly report carries a version-labelled inventory of all WCAG 2.2 Level A and AA criteria, marking each as partly automated, an automated review signal, or not automated, and stating what a person still has to check. And we never click your cookie banner, because clicking would itself be a consent gesture and would pollute the pre-consent reading, so we can tell you whether a reject-all control is present and equally weighted, but not whether pressing it actually stops the tags. Run a scan .
See also: What is a website compliance audit? · WCAG 2.1 AA accessibility audit explained
## Common questions
Are free compliance scanners actually useful? +
Some are; many are lead-generation lures that produce alarming reports to drive sales calls. A useful free scan tests against real WCAG/GDPR criteria, links each finding to the regulation, and tells you whether the issue is high or low severity, not just count.
What can a free scan check vs. a paid one? +
A free scan should check what is deterministic from the public DOM and network traffic: WCAG 2.1 AA automated rules, cookies and third-party requests on first load, and the presence of the required legal pages. In Veracly the analyzers, the rule packs and the scoring are identical on every tier; a paid plan adds more pages per scan, more visitor countries in scope, continuous monitoring, AI explanations for every finding rather than just the top three, evidence screenshots and copy-paste remediation. Veracly checks no SEO, TLS configuration or security headers at all, on any tier.
Why do some free scans show wildly different results? +
Two reasons. First, scanners vary in the rules they implement (axe-core vs. proprietary engines vary by 30%+ on real sites). Second, some scanners conflate severity, counting decorative-image alt warnings the same as a missing form label produces inflated, scary numbers without telling you what to fix.
Should I trust an automated compliance score? +
A score is a useful starting point, not a verdict. A "98% compliant" score can still mean a regulator-fineable issue exists. Treat scores as a triage signal, focus on which specific issues exist and how severe they are, not the overall percentage.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- Multi-jurisdiction
### Multi-jurisdiction website compliance: one site, many laws
EU, UK, US, and Canadian visitors trigger different laws. Here is the practical playbook for satisfying GDPR, EAA, ADA, UK Equality Act, and AODA with one programme.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## What is a GDPR cookie audit? (And how to pass one in 2026)
URL: https://veracly.app/blog/gdpr-cookie-audit
Published: 2026-04-27

GDPR
# What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.
By Veracly Compliance Team · 2026-04-27· 9 min read
The GDPR is now eight years old, and yet the most common compliance failure on SMB websites is still the cookie banner. Every regulator in the EU has guidance on it; most have issued at least one fine for non-compliance. The bar is not high, it is just specific, and most banners fail on details that look small but matter.
A GDPR cookie audit is the structured check that tells you whether your site would survive scrutiny from the CNIL, the ICO, the Italian Garante, the Irish DPC, or any of their counterparts. This article walks through what the audit actually does, the rules it applies, and the failures we see most often on SMB sites.
## The legal foundation (in plain English)
Two laws apply. The ePrivacy Directive (Article 5(3), the “cookie rule”) requires consent before any non-strictly-necessary information is stored on or read from a user’s device. The GDPR defines what valid consent looks like (Article 4(11), Article 7): freely given, specific, informed, unambiguous, and revocable as easily as it was given.
Stitched together, the rule is straightforward. Before you set or read a non-essential cookie, before you fire a tracking pixel, before you load a third-party script that does either, you need to ask. The user must be able to refuse without penalty, in one click, and to change their mind later just as easily.
## What an audit checks, step by step
### 1. First-page-load network capture
The audit visits your site as a fresh user and records every cookie set, every localStorage write, and every network request fired before the user interacts with the consent banner. Anything non-essential firing here is a violation. This is the single highest-yield check, it catches the majority of real failures on SMB sites.
### 2. Cookie and storage inventory
The audit lists every cookie your site sets and every storage key it writes, together with the domain that set each one. That is the whole of it: we record names and domains, never values, and a cookie’s declared lifetime and purpose are not visible from the wire, so we do not report duration or purpose. We also do not grade your cookie policy against the list, because a declared-versus-observed comparison is a reading exercise, not a machine check. Do it yourself, with our inventory on one screen and your policy on the other. Most SMB cookie policies are stale templates, and regulators read them.
### 3. Banner-design check
Regulators have called out five banner patterns. Two of them can be judged from the banner’s markup, and Veracly checks those automatically:
- Equal-weight Accept/Reject. If “Accept all” is a prominent button and “Reject” is hidden in a settings link, the consent is not freely given. On 31 December 2021 the CNIL fined Google €150M and Facebook Ireland €60M for exactly this. We compare the two controls as they sit in the DOM, their kind, their visibility, and their visual weight. It is an inspection of the design, not a test of what happens after a click.
- No pre-ticked boxes. Every category, analytics, marketing, functional, must default to off.
The other three matter just as much and cannot be settled from a single snapshot of the page. Walk them yourself:
- Granular categories. A single “accept everything” switch is no longer enough; users must be able to consent to analytics without consenting to advertising.
- Withdrawal as easy as consent. A persistent “Cookie settings” link in the footer, opening the same banner, is the standard.
- No dark patterns. No countdowns, no “continued use of this site means consent,” no “legitimate interest” toggles for advertising.
### 4. Consent-record proof
The GDPR requires you to be able to prove, for every visitor, that consent was given and what it covered. A modern Consent Management Platform (CMP) does this for you; home-rolled banners almost never do.
### 5. Third-party script behaviour
Veracly captures every third-party script, cookie, and storage write that fires before any consent gesture, the pre-consent state regulators care about most. We never click your banner, and that is deliberate: a click is itself a consent gesture, and it would pollute the reading we came for. It also means we run no post-consent pass. To confirm that scripts respect a choice once it’s made, repeat each path yourself, “Accept all,” “Reject all,” and any granular partial consent, in a fresh private window with the Network tab open. The most common failure here: a script that loads anyway after “Reject,” often because a tag manager fires it on the wrong trigger.
## The failures we see most often on SMB sites
Meta Pixel firing on page load. By far the most common. The Meta Pixel installation guide tells you to drop the snippet in <head>; the snippet fires immediately. In the EU, that’s a violation on every visit. The fix is to either gate the snippet behind your CMP or use Meta’s consent-mode tags.
Google Analytics with no consent gate. GA4 has a consent-mode v2 that most SMBs do not configure. The audit catches it because the script fires regardless of the banner’s state.
Hotjar / Microsoft Clarity / Hubspot recording before consent. Session recorders are particularly sensitive, they capture what the user types, where they move the mouse, and personal data revealed in the page DOM. They cannot run pre-consent without a clear ePrivacy violation.
YouTube embeds in privacy mode but not really. youtube-nocookie.com reduces tracking but still sets cookies and contacts Google. Some regulators accept this as “essential” for video content; most require consent for embeds.
The “continued use of this site” banner. Implied consent has been explicitly rejected by every EU regulator. If your banner uses that phrasing, replace it today.
## How to pass the audit
The fix list, in priority order, is the same on most SMB sites:
- Install a real CMP that records consent (not just a banner that hides). Cookiebot, Usercentrics, Iubenda, OneTrust, and Termly all work; pick one that integrates with your stack.
- Move every analytics, advertising, and session-recording script behind the CMP’s consent gate. In Google Tag Manager, this means using consent triggers; in plain HTML, it means deferring the script until the CMP fires its “granted” event.
- Replace the existing banner with one that has equal-weight Accept and Reject, no pre-ticked categories, and granular toggles.
- Add a persistent “Cookie settings” link in the footer.
- Regenerate the cookie policy so it lists what your site actually sets.
- Re-scan for the pre-consent state, then walk the Accept and Reject paths yourself in a private window.
## Why continuous scanning matters here
Cookie compliance breaks silently. Marketing adds a new tag in GTM, a developer drops in a chat widget, a third party updates their script and starts setting a cookie they didn’t before. None of these will trigger an alert in your existing tooling. The audit pattern that works for SMBs is: a baseline scan, fixes, then scheduled re-scans that rebuild the cookie inventory from scratch, so anything new shows up in the next report.
Veracly does this, a free baseline scan of one page, then scheduled re-scans on the paid plans. Be precise about the alerting, because we are: you get an email when a report is ready, and an alert when your average score drops by more than the threshold you set. We do not yet diff finding sets or tracker inventories between scans, so a newly added tracker reaches you as a score drop and as a line in the next report, not as a “new tracker” notification. Run a scan and see your site as a regulator would see it.
See also: What is a cookie banner audit? · Tracking pixel audit: GDPR & ePrivacy · What is a website compliance audit?
## Common questions
What is a GDPR cookie audit? +
A GDPR cookie audit is a structured check of your site to verify that consent is captured before any non-essential cookie or tracker is set. It records the third-party requests fired on the very first page load, and the name and domain of every cookie and storage key written before any consent gesture. Comparing that inventory against your published cookie policy is the manual step that follows.
Which cookies need consent? +
Strictly necessary cookies (session, security, load balancing, remembering consent itself) do not need consent. Everything else does, analytics, advertising, personalisation, A/B testing, session recording, and any third-party widget that sets cookies on its own.
Is Google Analytics 4 GDPR compliant by default? +
No. GA4 still requires explicit consent in the EU before any data leaves the browser, and the data should be IP-anonymised and configured for EU storage where available. Several EU regulators (CNIL, Datatilsynet, the Italian Garante) have ruled specific GA4 configurations unlawful.
What is the fine for a non-compliant cookie banner? +
Fines vary widely. On 10 December 2020 the CNIL fined Google €100M in a single decision (€60M against Google LLC plus €40M against Google Ireland) for advertising cookies set without consent; on 31 December 2021 it fined Google €150M and Facebook Ireland €60M for making refusal harder than acceptance. Enforcement has not slowed: on 1 September 2025 the CNIL fined Google €325M and SHEIN €150M over cookie practices. Smaller controllers are fined far less, the Dutch AP fined AS Watson (Kruidvat) €600,000 in 2024 and that was reduced to €50,000 on appeal in June 2025. Gravity and duration of the breach come first; turnover and the number of affected visitors are aggravating factors, not the starting point.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- GDPR
### Is Google Analytics 4 illegal in Europe? The actual answer in 2026
GA4 is not strictly illegal in the EU, but it is also not a drop-in default. Two distinct questions decide its fate: did you get consent, and does the EU-US Data Privacy Framework still hold?
- GDPR
### Do I need to honor the Global Privacy Control (GPC) signal in the EU?
GPC is a browser signal that tells sites "do not sell or share my data." California treats it as a binding opt-out. The EU has not legislated it, and the draft ePrivacy Regulation that would have was withdrawn in 2025. Honoring GPC in the EU is optional, and defensible on Article 21(5) GDPR alone.
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.

---

## Imprint (Impressum) requirements for German websites in 2026
URL: https://veracly.app/blog/impressum-requirements
Published: 2026-04-27

Imprint
# Imprint (Impressum) requirements for German websites in 2026
Germany and Austria require an Impressum on every commercial website; Switzerland only for sites offering goods or services online. Here is the legal basis, the field-by-field checklist, and the common failures that trigger Abmahnung letters.
By Veracly Compliance Team · 2026-04-27· 7 min read
Among compliance failures, missing Impressums are unique: they are easy to spot, easy to enforce, and have a built-in private-enforcement mechanism in the form of the Abmahnung , a cease-and-desist letter from a competitor or specialised law firm. For SMBs operating in Germany, Austria, or Switzerland (DACH), the Impressum is the lowest-effort, highest-impact compliance fix on the list.
## The legal basis
Germany. Until May 2024 the rule sat in §5 of the Telemediengesetz (TMG). It now lives in §5 of the Digitale-Dienste-Gesetz (DDG) , the German implementation of the EU Digital Services Act. The substance is unchanged, same fields, same enforcement.
Austria. Two duties, routinely confused. The direct analogue of §5 DDG is §5 of the E-Commerce-Gesetz (ECG) : provider identification for anyone offering an information-society service, with a fine ceiling of €3,000 under §26 ECG. Separately, §24 and §25 of the Mediengesetz (MedienG) require ownership and editorial disclosure on any “periodical electronic medium,” which courts have read broadly to cover commercial websites; §27 MedienG reaches €20,000. Most Austrian sites owe both. The required fields differ slightly from Germany’s.
Switzerland. A different basis and a narrower scope: Art. 3(1)(s) UWG (the Federal Act against Unfair Competition) requires a legal notice for sites offering goods or services in electronic commerce, and it names the email address as mandatory. A German-style Impressum satisfies it, but the fields differ (UID and commercial register rather than HRB and USt-IdNr.). See Impressum requirements for Swiss websites for the Swiss-specific checklist.
## The German field-by-field checklist
§5 DDG requires the following information, presented leicht erkennbar, unmittelbar erreichbar und ständig verfügbar (easily recognisable, directly accessible, and continuously available):
- Full company name and legal form (GmbH, UG, AG, e.K., GbR, sole proprietorship, etc.).
- Authorised representative for legal entities (Geschäftsführer, Vorstand).
- Postal address , actual street address, not a P.O. box. This is the one that catches one-person businesses out: a home address is required if there is no business premises.
- Contact details enabling rapid electronic communication and direct contact: an email address (not just a contact form) and telephone or equivalent real-time channel.
- Commercial register entry if applicable: registry court and HRA/HRB number.
- VAT identification number (USt-IdNr.) if the business has one.
- Regulated profession (where applicable): chamber, professional title, country of issuance, professional regulations and how to access them. Doctors, lawyers, tax advisors, architects, real-estate agents fall into this category.
- No ODR platform link. This used to be a required field. It is not one any more, and leaving it in place is now the error — see below.
- Statement on consumer ADR participation: whether the business participates in alternative dispute resolution and where.
- Editorial responsibility (V.i.S.d.P.) where the site contains journalistic-editorial content. A blog with named authors arguably qualifies; this is where most SMBs over-disclose to be safe.
## What auditors check beyond the fields
Beyond the contents, an Impressum audit looks at:
- Link visibility. The Impressum link is in the footer of every page. “Impressum” is the safest label, because it is the word German visitors look for — but it is not legally compulsory. The BGH held in I ZR 228/03 (20 July 2006) that a link marked “Kontakt” satisfied the duty too: the test is whether the information is easy to recognise and easy to reach, not whether one particular word was used. Our own detector accepts imprint, legal notice, mentions légales, aviso legal, colofon and note legali alongside Impressum. What does fail is a label a visitor cannot connect to provider information at all, or an Impressum buried inside a multi-page legal section.
- Number of clicks. Reachable in two clicks (one click is the standard interpretation). Hiding the Impressum behind a nav menu accordion is risky.
- Markup. The link is a real <a> tag, indexable by crawlers, not a JavaScript-only modal that bots cannot follow.
- Consistency with the privacy policy. The controller named in the Impressum is the same as in the privacy policy.
- Mobile presentation. The Impressum is just as accessible on small viewports as on desktop.
## Common failures we see
P.O. boxes instead of street addresses. Common for digital freelancers; also non-compliant. The DDG requires a deliverable street address.
Contact form instead of email address. Courts have repeatedly held that a contact form alone does not satisfy the “rapid electronic communication” requirement. An email address must be provided.
Missing telephone number. §5 requires direct contact details. Telephone is the default; a chat tool that responds in real time during business hours arguably qualifies, but the safer answer is to publish a number.
A leftover ODR link. This one has inverted. Regulation (EU) 2024/3228 repealed Regulation (EU) 524/2013; the European ODR platform was switched off on 20 July 2025 and the Art. 14 trader-link duty ceased with it. Traders were required to take the link down. Most SMB Impressums still carry the boilerplate sentence and a link to ec.europa.eu/consumers/odr, which now points at a service that no longer exists — directing consumers to a dead redress route is itself misleading and actionable. Delete the sentence and the link.
Missing VAT ID. If you have a USt-IdNr., it has to appear. Confusingly, some SMBs add a Steuernummer instead, that is a different identifier and does not satisfy the requirement.
## The Abmahnung pattern, and what changed in 2020
The mechanism is still live: a competitor or a specialised law firm finds a page without a compliant Impressum and sends a template letter demanding a signed, penalty-backed cease-and-desist undertaking. What changed is the money. Since 2 December 2020 , §13(4) no. 1 UWG excludes reimbursement of the warning party’s costs for breaches of information and labelling duties in telemedia — and §5 DDG is precisely such a duty. §13a(2) UWG additionally bars a contractual penalty in a first warning against a business with fewer than 100 employees. The fee-farming economics that made Impressum warnings a business model were legislated out for this exact category of violation.
That is not a reason to leave it broken. The cease-and-desist undertaking is open-ended and survives long after the letter; breaching it later is what actually costs money. Competitors and Wettbewerbsvereine still send these letters, and courts still grant injunctions. The cure is an afternoon of work.
## What Veracly actually checks
Narrower than you might want, and we would rather say so than imply otherwise. Veracly looks for an Impressum link on the pages it crawls and probes a bounded set of conventional paths (/impressum, /legal-notice, /mentions-legales and similar). It reports presence or absence, and the check only runs when the site’s primary country is Germany or Austria.
It does not read the page and tell you whether your legal form, register number, VAT ID or authorised representative is actually there. No §5 DDG field validation exists in the product, so we are not going to claim one. A free scan covers one page; weekly re-scans start at the Growth tier, Starter re-scans monthly. Field-by-field completeness is the checklist above, done once, by a human. Run a scan .
See also: What is a website compliance audit? · What is a GDPR cookie audit?
Live check
### Does this site have a compliant Impressum?
Paste any URL to check whether a reachable Impressum / legal-notice page exists. Results in a couple of seconds.
Automated check of a single page, informational only, not legal advice.
## Common questions
Does my website need an Impressum? +
If your site is reachable in Germany and provides any commercial content, including a one-person freelance landing page or a free product hosted by a business, yes. The legal basis is the Digitale-Dienste-Gesetz (DDG, replacing the TMG since May 2024), §5. Austria has a parallel provider-identification duty in §5 ECG, with §24 and §25 MedienG adding ownership and editorial disclosure on top. Switzerland has no general imprint duty: Art. 3(1)(s) UWG applies only to sites offering goods or services in electronic commerce.
Where does the Impressum link belong? +
In the footer of every page, reachable in two clicks from anywhere on the site. "Impressum" is the label German visitors look for and the safest choice, but it is not legally compulsory: the BGH held in I ZR 228/03 (20 July 2006) that a link marked "Kontakt" also satisfied the duty, because the test is whether the information is easy to recognise and easy to reach. A footer link visible on every page meets that; a link only inside a sub-menu does not. Veracly recognises Impressum, imprint, legal notice, mentions légales, aviso legal, colofon and note legali when it looks for the link.
What is an Abmahnung? +
A formal cease-and-desist letter from a competitor or a specialised law firm, demanding a signed, penalty-backed undertaking. It used to come with a bill for the sender’s legal fees, but since 2 December 2020 §13(4) no. 1 UWG excludes cost reimbursement for breaches of information and labelling duties in telemedia, and §5 DDG is exactly such a duty. §13a(2) UWG also bars a contractual penalty in a first warning against a business with fewer than 100 employees. The undertaking itself is still real and open-ended, and breaching it later is what costs money.
Does an Impressum apply if I run an English-only site from outside Germany? +
If the site is accessible in Germany and targets German users (German-language content, EUR pricing, .de domain, advertising in DE), German consumer-protection courts will apply the DDG regardless of where the company is based. Pure English sites with no DE targeting are usually fine.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Imprint
### Switzerland: Impressum & legal-notice requirements for commercial websites (2026)
Switzerland requires a legal notice (Impressum) on commercial websites under Art. 3(1)(s) UWG, narrower than Germany’s rule, but the email address is explicitly mandatory. Here is the field-by-field checklist and how Swiss law differs from the German DDG.
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## Multi-jurisdiction website compliance: one site, many laws
URL: https://veracly.app/blog/multi-jurisdiction-compliance
Published: 2026-04-27

Multi-jurisdiction
# Multi-jurisdiction website compliance: one site, many laws
EU, UK, US, and Canadian visitors trigger different laws. Here is the practical playbook for satisfying GDPR, EAA, ADA, UK Equality Act, and AODA with one programme.
By Veracly Compliance Team · 2026-04-27· 8 min read
For most modern SMB websites, the practical question is not “which law applies” , it is “which laws apply.” A site sold across the EU, UK, US, and Canada triggers six or seven distinct legal frameworks, each with its own technical requirements, disclosures, and enforcement mechanism. Building seven compliance programmes is impossible for an SMB. Multi-jurisdiction compliance is about doing the right work once and reporting it correctly to each authority.
## The law-by-law summary
### European Union
- GDPR + ePrivacy Directive : opt-in consent for non-essential trackers, lawful basis for personal-data processing, data-subject rights, transparency.
- European Accessibility Act (EAA): WCAG 2.1 AA via EN 301 549, from 28 June 2025, for in-scope products and services. Microenterprise exemption applies.
- Digital Services Act : transparency, content moderation, and advertising disclosures (mostly relevant for marketplaces and platforms).
### United Kingdom
- UK GDPR + PECR : close to the EU regime, but no longer identical. The Data (Use and Access) Act 2025 amended PECR: since 5 February 2026 several low-risk cookie categories are exempt from consent — first-party aggregate analytics among them — and the PECR penalty ceiling rose from £500,000 to £17.5m or 4% of global turnover. The ICO publishes detailed cookie guidance.
- Equality Act 2010 : an anticipatory duty to make reasonable adjustments. The Act names no technical standard, and no UK court has ever ruled on web accessibility — every claim brought so far has settled. WCAG 2.1 AA is named in UK law only by PSBAR 2018, which binds the public sector. Private service providers are assessed against it because it is the practical yardstick everyone uses, not because a judgment says so.
### United States
- ADA Title III : applies to websites of public accommodations. Technical standard de facto WCAG 2.1 AA.
- State privacy laws : California (CCPA/CPRA), Colorado (CPA), Virginia (VCDPA), Connecticut (CTDPA), Texas (TDPSA), and a growing list. Each has notice requirements, consumer-rights workflows, and a sale/sharing opt-out (Global Privacy Control). Penalties vary.
- Section 5 FTC Act : misleading marketing claims about privacy or accessibility (the basis for the 2025 accessiBe enforcement).
### Canada
- PIPEDA (federal): consent and disclosure for personal information.
- AODA (Ontario): WCAG 2.0 AA for organisations with 50+ employees; the threshold is sometimes lower under provincial human-rights law.
- Quebec Law 25 : stricter privacy rules, including DPIA-like assessments for new technologies.
### Australia
- Privacy Act 1988 : Australian Privacy Principles, currently undergoing reform that will tighten consent and bring it closer to GDPR.
- Disability Discrimination Act : case law cites WCAG 2.0/2.1 AA as the practical standard.
## The compliance pyramid: what overlaps
Most of the work is shared across regimes. The diagram a useful audit produces:
- Accessibility : one WCAG 2.1 AA programme serves the EAA, ADA, UK Equality Act, AODA, and the DDA — but for different reasons in each, and the difference matters when someone asks you to justify the target. The EAA names 2.1 AA through EN 301 549; AODA sets a statutory floor of WCAG 2.0 AA, which 2.1 AA clears. The UK Equality Act and ADA Title III name no technical standard at all, so there 2.1 AA is evidence rather than compliance: the yardstick a claim would be assessed against, not a bar written into the law. A single technical baseline is still the right call. Just do not tell a lawyer that 2.1 AA is what the Equality Act requires.
- Cookies and trackers : GDPR + ePrivacy is the strictest consent regime, and meeting the EU bar carries you most of the way through UK PECR and Brazil’s LGPD. It does not carry you into US state law, which runs on a different model. Twelve states now require a Global Privacy Control signal to be honoured server-side, and California requires a separate Notice at Collection. An EU opt-in banner does neither of those things for you. The reverse does not hold either, a CCPA-compliant cookie banner usually fails GDPR.
- Privacy disclosures : a GDPR-compliant privacy policy is over-inclusive for most other regimes. State-specific addenda (California-resident rights, Quebec-resident rights) are the standard add-ons.
- Consumer-rights workflows : a single intake (right of access, correction, deletion, portability, objection) routes to per-jurisdiction handlers.
- Required pages : privacy policy, accessibility statement, cookie policy, imprint (for DACH visitors). Universal.
## The practical playbook
- Adopt the strictest standard as your baseline. For accessibility, WCAG 2.1 AA. For privacy, GDPR-grade consent and disclosures. Other regimes get a jurisdiction-specific overlay.
- Run one technical audit, generate per-regulation reports. The same missing alt text shows up in your EAA report, your ADA report, and your AODA report with the relevant clause and remediation steps. This is how a one-developer SMB compliance team is feasible.
- Localise the front-end of the user experience, not the back-end. The cookie banner the user sees can adapt to their region (banner content, default state, available toggles). The underlying tag manager logic does not need to change.
- Document jurisdiction in the privacy programme. One privacy policy with regional sections beats six separate policies that drift out of sync. A single data-subject request workflow with a routing layer beats six.
- Continuously monitor. Multi-jurisdiction means the surface area for regression is six times what a single-jurisdiction site faces. A new tag, a new widget, a new third-party can break compliance in three regimes simultaneously.
## The trap of single-jurisdiction tooling
Most accessibility scanners only report against WCAG. Most privacy auditors only check GDPR or only check CCPA. An SMB that hires three separate vendors for three jurisdictions ends up with three reports that disagree, three SLAs, three invoices, and no consolidated remediation backlog. A multi-jurisdiction tool reduces this to one audit feed, one ticket queue, one weekly cadence.
## How Veracly approaches it
Veracly was specifically built for this pattern. One scan generates simultaneous reports against five rule packs: EAA, GDPR and ePrivacy, ADA, UK Equality Act, and AODA. Each issue is mapped to the specific clause in each regulation, with one remediation backlog. US state privacy law is not on that list — we do not grade against CCPA, CPRA, or their successors, and the report says so rather than implying coverage we do not have. Reports are localised to the jurisdiction that requires them, German EAA output for the German reporting authority, English ADA output for a US settlement negotiation, French RGPD output for the CNIL. Run a free scan .
See also: What is a website compliance audit? · EAA compliance for SMBs · ADA website compliance audit · Impressum requirements for Swiss websites
## Common questions
Do I need to comply with all of GDPR, ADA, EAA, and AODA? +
Each law applies based on where your visitors are, with one exception worth getting right. If you serve EU visitors, GDPR and the EAA apply. If you serve US visitors, the ADA and applicable state laws apply. AODA does not work that way: it binds organisations with a presence in Ontario and 50 or more employees, so Ontario traffic alone does not pull a foreign site into it. The practical answer is: the union of the laws that apply to your audience and to the places you are established.
Are there overlapping requirements? +
Significantly, though not in the way most summaries put it. Only two of these name a technical standard: the EAA points at WCAG 2.1 AA through EN 301 549, and AODA sets a statutory floor of WCAG 2.0 AA, which 2.1 AA exceeds. The UK Equality Act 2010 and ADA Title III name no technical standard at all, so there 2.1 AA is not a statutory requirement but the practical yardstick claims are assessed against. Build one programme to 2.1 AA and it serves all four. Privacy laws (GDPR, ePrivacy, CCPA, CPA, VCDPA) overlap less but share core principles around consent and disclosure.
What is the simplest way to satisfy all of them? +
Adopt the strictest applicable standard as your baseline. For accessibility, that is WCAG 2.1 AA (sometimes 2.2). For privacy, treat all visitors as if GDPR applied, opt-in consent for non-essential trackers, transparent disclosures, easy data-rights workflows. Strictness flows downhill.
How does jurisdiction-aware reporting work? +
A single technical scan generates a report per regulation, mapping each issue to the specific clause it implicates. The same missing alt text appears in your EAA report, your ADA report, and your AODA report, but with the relevant legal citation in each.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- Multi-jurisdiction
### Website compliance in the Netherlands: cookies, GDPR and accessibility
The Netherlands applies the same EU rules as everyone else, but through its own statutes and regulators. The cookie rule is in the Telecommunicatiewet, where the ACM supervises Art. 11.7a itself and the Autoriteit Persoonsgegevens covers the GDPR side, and accessibility is now law under the Implementatiewet.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## Tracking pixel audit: GDPR & ePrivacy compliance for SMBs
URL: https://veracly.app/blog/tracking-pixel-audit
Published: 2026-04-27

Tracking
# Tracking pixel audit: GDPR & ePrivacy compliance for SMBs
Tracking pixels share visitor data with ad networks the moment they fire. Here is what an audit checks, why pixels are the most-fined item on SMB sites, and how to keep them and stay compliant.
By Veracly Compliance Team · 2026-04-27· 8 min read
On most SMB sites, the highest compliance risk is not the cookie banner itself, it is the tracking pixels behind it. Pixels are how your site reports visitor behaviour to advertising networks, and they almost always fire on page load by default. In the EU and UK, that pattern is non-compliant on every visit.
This article covers what a tracking pixel audit looks at, the platform-by-platform behaviour, and the two installation patterns that actually keep pixels working without breaking the law.
## What a pixel actually does
When a tracking pixel fires, four things happen in roughly 50 milliseconds:
- The browser sends an HTTP request to the platform (e.g. connect.facebook.net).
- The request includes the current URL, referrer URL, IP address, user agent, screen size, and any custom parameters the site attached (cart contents, signup intent, etc.).
- Cookies get set. Some are third-party cookies on the platform’s own domain, but the ones that matter most are first-party: _fbp and _fbc are written by the pixel’s own JavaScript on your domain, which is precisely why they survive third-party-cookie blocking in Safari and Firefox. If the user is logged into Facebook, TikTok, or LinkedIn in the same browser, the platform can tie the visit to that user’s identity regardless.
- The pixel loads its supporting JavaScript, which can fire additional events (PageView, ViewContent, AddToCart, Lead, Purchase) on subsequent interactions.
For an EU/UK visitor, every step beyond the first is a personal-data processing activity that needs a legal basis. The only feasible legal basis for advertising tracking is consent (Article 6(1)(a) GDPR), and that consent has to be given before the pixel fires.
## What an audit checks, platform by platform
### Meta Pixel (Facebook / Instagram)
The default install snippet from Meta’s admin loads fbevents.js immediately and fires PageView on every load. The audit confirms this and reports it as the most common failure on SMB sites in the EU. The Meta-recommended fix is to deploy via Google Tag Manager with consent-mode triggers, or to use the Pixel Helper’s fbq(’consent’, ’revoke’) call before consent and grant after.
### TikTok Pixel
The TikTok pixel similarly fires on page load by default. What Veracly observes is the pre-consent state: whether analytics.tiktok.com receives a pixel hit before the visitor has consented to anything. Whether your CMP then calls ttq.consent(’granted’) correctly is a manual check. We do not click your banner, so we never see the call that follows acceptance.
### LinkedIn Insight Tag
LinkedIn’s Insight Tag fires on every page and stores both a first-party and a third-party cookie. It is particularly common to see it deployed unguarded on B2B SMB sites. The audit reports any first-load fire and any cookie set before consent.
### Google Ads conversion tracking
Google Ads tracking integrates tightly with Consent Mode v2. What Veracly records is whether a conversion or remarketing request reaches googleadservices.com or doubleclick.net before consent. It does not read the consent state inside gtag, and it does not inspect request payloads at all: the finding is that the request happened, not what it contained. If Consent Mode v2 is not deployed, advertising signals fire regardless of the user’s choice, and that is the failure a pre-consent observation catches.
### Pinterest, Snap, Twitter/X, Reddit
All similar in pattern: load on page load by default, set cookies, send page metadata to the platform. All require gating behind consent.
## Why this is the highest-risk item
Pre-consent firing is the failure a regulator can prove without leaving their desk: open the site, open the network tab, watch the request go out before the banner has been touched. No forensics, no disclosure request, no expert witness. The best-documented European example is Swedish rather than French or Italian — in 2024 the IMY fined Apoteket roughly €3.2m over Meta Pixel data sharing.
Earlier versions of this article cited a CNIL 2024 pixel-enforcement priority and a run of small Italian Garante e-commerce fines in the €5,000 to €50,000 band. Neither stood up when we went back to the published sources, so both are gone rather than replaced with something equally convenient. The defensible version is narrower and still uncomfortable: the technical failure is trivial to demonstrate, it is present on a large share of SMB sites, and nothing about being small removes it from scope.
## The two patterns that work
### Pattern 1: CMP-gated script load
The cleanest approach. Your CMP exposes an event when the user has consented to a specific category. Listen for the event and load the pixel script only when it fires.
// Cookiebot example, replace with your CMP’s API
window.addEventListener(’CookiebotOnAccept’, () => {
if (Cookiebot.consent.marketing) {
!function(f,b,e,v,n,t,s) { /* Meta Pixel snippet */ }
fbq(’init’, ’PIXEL_ID’);
fbq(’track’, ’PageView’);
}
});The advantage is total: no script is loaded, no cookie is set, no request is made until consent exists. The disadvantage is that the conversion happens after consent, so you lose visibility into rejected users, which is the whole point.
### Pattern 2: Consent-mode integration
For platforms that support it (Google, Meta, TikTok), consent mode lets the script load but defer or anonymise its behaviour until consent. With Google Consent Mode v2, for example, you load gtag but pass consent: ’denied’ until the user accepts; the platform then receives only aggregated, modelled signals.
Most regulators accept consent mode as a valid implementation; some (notably the Hamburg DPA in 2023 guidance) have raised concerns about whether the “modelled” signals constitute processing without consent. The pragmatic advice for SMBs: pattern 1 is safer, pattern 2 gives you better attribution. Pick based on your risk tolerance and revenue exposure.
## Audit deliverables that matter
A useful pixel audit gives you, for each platform:
- The exact request URL fired, the timing relative to the consent banner, and the cookies set.
- The recommended fix, code snippet, GTM trigger configuration, or CMP setting.
- A re-test after the fix to confirm.
Two things people expect on that list are manual, and any tool claiming to automate them is overselling. Reading the consent state inside gtag, or validating a TCF consent string, means inspecting what a tag sends; Veracly does not inspect payloads. And confirming that the accept and reject paths behave differently means clicking the banner, which Veracly deliberately does not do, because a click is itself a consent gesture and would destroy the pre-consent reading the rest of the scan depends on. Do both by hand in DevTools, once, after you ship the fix.
## How Veracly approaches pixel audits
Veracly matches outgoing requests against a registry of 69 hand-curated trackers (Meta, TikTok, LinkedIn, Google Ads, Pinterest, Snap, X/Twitter, Reddit, Hotjar, Microsoft Clarity, FullStory, HubSpot and the rest). It matches them on their firing endpoints rather than their loader scripts, so a tag that Consent Mode is correctly holding back is not reported as though it had fired. For each match you get the request URL, whether it arrived before the banner was touched, the cookies and storage keys observed, and a copy-paste fix for your CMP or tag manager.
Three limits, up front. The registry is curated by hand between releases, not scraped from a feed, so a tracker nobody has added yet will not be matched. Anything that never reaches the browser is outside what a browser-side scan can see — Meta’s Conversions API, a server-side GTM container, a tagging endpoint on your own domain. And scheduled re-scans run monthly on Starter; weekly and daily monitoring are the higher plans. Run a scan .
See also: What is a GDPR cookie audit? · What is a cookie banner audit?
## Common questions
Do tracking pixels need consent under GDPR? +
Yes. The Meta Pixel, TikTok Pixel, LinkedIn Insight Tag, Google Ads conversion tag, Pinterest Tag, and similar trackers are all third-party trackers that store data on the user’s device and share data with the platform. Consent is required before they fire.
What is the difference between a pixel and a cookie? +
A cookie is a small file stored on the user’s device. A pixel is a small image (or piece of JavaScript) that, when loaded, makes an HTTP request to the platform, sharing the page URL, referrer, IP, user agent, and any data the site decided to attach. Most pixels also set cookies, so both rules apply.
Can I use server-side tracking to avoid consent? +
No. Server-side tracking (e.g. Meta’s Conversions API) still requires consent under GDPR if it processes personal data linked to identifiable individuals. The only thing it changes is how the data is transmitted, not whether the legal basis applies.
How do I install a pixel compliantly? +
Two patterns work. (1) Gate the pixel script inside your CMP’s consent gate, only load it when the user has accepted advertising cookies. (2) Use the platform’s consent-mode integration (Google Consent Mode v2, Meta’s data-processing options, TikTok’s consent API) to send "denied" signals when consent is absent.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Tracking
### Heat maps, session recordings, and the "legitimate interest" grey area
Session recording tools sell themselves on the legitimate-interest argument: "we anonymize, we are GDPR-friendly, no consent required." EU DPAs have consistently rejected this. The recording itself is the storage event, and the storage is non-essential.
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## WCAG 2.1 AA accessibility audit explained (for SMB websites)
URL: https://veracly.app/blog/wcag-accessibility-audit
Published: 2026-04-27

Accessibility
# WCAG 2.1 AA accessibility audit explained (for SMB websites)
Level AA is the bar every regime converges on, but no two of them name the same WCAG version. Here is what an audit actually checks, what only humans can verify, and the five fixes that move the needle on most SMB sites.
By Veracly Compliance Team · 2026-04-27· 9 min read
Level AA is the bar your website needs to clear, whatever jurisdiction you operate in. The version is where the regimes diverge, and the difference is not cosmetic. The European Accessibility Act names no WCAG version in its own text; it reaches WCAG 2.1 AA through the harmonised standard EN 301 549. The Americans with Disabilities Act (Title III) names no technical standard at all, so US settlements and case law have worked from 2.0 and later 2.1 AA as a de facto bar. The UK Equality Act 2010 names none either, although UK public-sector bodies have been monitored against WCAG 2.2 AA since October 2024. Ontario’s AODA still explicitly requires WCAG 2.0 AA (O. Reg. 191/11 §14) and has never been amended.
WCAG 2.2 AA is a strict superset of all of those, which is why it is the sensible thing to aim at and why Veracly scans against it. Which version your regulator will actually hold you to is a separate question, mapped jurisdiction by jurisdiction in WCAG 2.1 vs 2.2: which version applies to me?
A WCAG accessibility audit is the structured check that tells you how far your site is from that bar. This article explains what an audit actually does, the difference between scanning and manual review, and the five fixes that close the gap on most SMB sites.
Run a free WCAG audit on your own site
Veracly scans your live site with axe-core against the WCAG 2.2 AA superset (the 2.0, 2.1 and 2.2 A/AA rule sets together), ranks each issue by severity, and shows the failing CSS selectors so your developer can find them. A free scan covers one page and lists up to three selectors per issue; written developer fixes are part of the paid report, and a free scan explains only its top three findings. No accessibility overlay, no widget.
Scan your website →
## The four WCAG principles
Every success criterion in WCAG falls under one of four principles, POUR.
- Perceivable. Users must be able to perceive the content. Text alternatives for images, captions for video, sufficient colour contrast, content that works at 200% zoom.
- Operable. Users must be able to operate the interface. Keyboard navigation, no time limits that can’t be extended, no flashes that trigger seizures, clear focus states.
- Understandable. Content and operation must be understandable. Page language is declared, navigation is consistent, errors are explained in plain language.
- Robust. Content must be robust enough for assistive technologies. Valid HTML, correct ARIA usage, status messages exposed to screen readers.
## What an automated scan actually catches
A scan running axe-core (the same engine used by Deque, Microsoft, and Google’s own accessibility tools) reliably detects:
- Images with no alt attribute at all. An empty alt="" passes, because no machine can tell a decorative image from a meaningful one
- Insufficient colour contrast (text vs. background)
- Missing form labels or labels not associated with inputs
- Buttons and links with no accessible name
- Page missing a lang attribute
- Empty headings, and paragraphs styled to look like headings
- Iframes without titles
- ARIA attributes used incorrectly or on the wrong element
- Auto-playing media that cannot be paused
That is the machine-testable slice, and it is smaller than vendors imply: roughly a third of WCAG success criteria can be tested by machine at all, which is why every Veracly report carries a version-labelled inventory of all WCAG 2.2 Level A and AA criteria, marking each as partly automated, an automated review signal, or not automated, and stating what a person still has to check. The catch that makes the slice worth running is that those issues account for a disproportionate share of real complaints — they are exactly what a screen-reader user hits in the first 30 seconds on your site.
## What only manual review catches
A scanner cannot tell you whether your content is understandable. It cannot tell you whether your alt text describes the image well; only that alt text exists. It cannot tell you whether keyboard tab order makes sense; only that elements are reachable. It cannot test screen-reader announcements for content that depends on focus, live regions, or modal management.
Heading order belongs in this bucket too. axe-core can see that you jumped from an h1 to an h3, but that is a best-practice signal rather than a failure of any success criterion, so Veracly does not score it against any jurisdiction. Whether your heading structure actually describes the page is a human judgement, and no scanner makes it.
For full WCAG conformance, you need both. The realistic SMB pattern is: weekly automated scans to catch regressions, plus a one-time manual review (internal or consultant) for the issues automation misses.
## The five fixes that move the needle
On most SMB sites, the same five issues account for the majority of automated violations. Fix these and the report looks dramatically different.
- Colour contrast. Body text against background must be at least 4.5:1; large text 3:1. Most brand colour palettes have at least one combination that fails. Run every text/background pair through a contrast checker and adjust hex values; do not introduce a separate “accessibility theme.”
- Form labels. Every <input>, <select>, <textarea> needs a <label for="..."> with matching id. Placeholder text is not a label. Aria-label is acceptable when a visible label is undesired.
- Alt text on every meaningful image. Decorative images get alt=""; informative ones get a description; functional ones (logos that link, icon buttons) describe the action, not the image.
- Visible focus state. Most CSS resets remove the default focus ring. Add it back. Keyboard users need to see where focus is.
- Landmark structure and heading order. One <h1> per page; headings descend without skipping levels; <header> <nav> <main> <footer> wrap the right regions. Screen-reader users navigate by headings and landmarks.
## What an audit report should give you
A useful WCAG audit report does three things:
- Lists every violation against the specific WCAG success criterion it breaks (e.g. “1.4.3 Contrast (Minimum)”), not just “low contrast.”
- Shows the specific element and CSS selector, copy-paste, not a screenshot you have to translate to code.
- Provides a developer fix, not a description of the problem. “Set color: #1a1a1a” is useful; “Improve contrast” is not.
If a scanner’s report stops at the description, the fix takes a developer 10x longer than it needs to.
## The accessibility-overlay trap
Overlay vendors, accessiBe, AudioEye, UserWay, EqualWeb, sell a one-line JavaScript snippet that promises to make your site WCAG compliant. The FTC fined accessiBe USD 1 million in January 2025 for misleading marketing about exactly this claim. The reasoning is consistent: overlays cannot read intent, they cannot know which buttons should announce what, which images are decorative, what tab order makes sense, so they guess, and frequently guess wrong.
For lawsuit avoidance, overlays are worse than nothing. The plaintiff bar in the US has specifically begun targeting overlay-using sites because the failure mode is so predictable.
## How Veracly approaches WCAG
Veracly runs axe-core against your real DOM and scores it against the WCAG 2.2 AA superset, the 2.0, 2.1 and 2.2 A/AA rule sets run together. Every definite violation is reported with the specific CSS selector: up to three failing elements per issue on a free scan, five on a paid one.
Results axe cannot decide are listed in the report as inconclusive and are not scored, because a maybe is not a finding. That decision has a real cost and you should know about it: text sitting over a photograph, a gradient, or a semi-transparent panel usually lands in that bucket, so it is listed as a review item rather than a contrast failure; a human reviewer should check it. Seven further axe-core rules score zero on purpose: four sit on criteria we have already declared manual-review, so scoring them would contradict our own disclosure, and three are already covered by an equivalent custom rule that would otherwise double-penalise the same page.
Multi-jurisdiction reporting is built in: one scan grades against every rule pack in scope for the countries you sell into, the EAA, the ADA, the UK Equality Act and, when Canada is in scope, AODA. A free scan covers one page and takes the single market you declare on the form, so it will not produce all four cards. Written developer fixes are generated on paid scans only; a free scan explains its top three findings and no more. Run a free scan to see your baseline.
See also: WCAG 2.1 vs 2.2: which applies to you? · EAA compliance for SMBs: what changes June 2025 · ADA website compliance audit (USA) · What is a website compliance audit?
## Common questions
What is WCAG 2.1 AA? +
WCAG 2.1 Level AA is the international web accessibility standard published by the W3C. It defines 50+ success criteria across four principles: Perceivable, Operable, Understandable, Robust. AA is the conformance level every regime converges on, but the version differs: the EAA reaches 2.1 AA through the harmonised standard EN 301 549, Ontario’s AODA still requires 2.0 AA, UK public-sector bodies have been monitored against 2.2 AA since October 2024, and the ADA and the UK Equality Act name no technical standard at all.
How much of WCAG can be tested automatically? +
Roughly a third of WCAG success criteria are machine-testable at all; the rest need a human. Our own report says so explicitly: it carries a version-labelled inventory of every WCAG 2.2 Level A and AA criterion, marking each as partly automated, an automated review signal, or not automated. Deque, the makers of axe-core, publish a figure near 57%, but that measures issue volume on their own test corpus rather than how much of the standard a machine can cover, so it is not the number to plan against. What is left is manual work: keyboard navigation, screen-reader behaviour, cognitive load, and content quality.
Do small businesses really need to comply with WCAG? +
Yes, in most jurisdictions. The EAA covers private companies above the microenterprise threshold since June 2025. ADA web accessibility filings hit a record 5,114 in 2025 on UsableNet’s count, 3,195 of them federal, and SMB sites are the main target. The UK Equality Act applies to any service provider regardless of size.
Can an accessibility overlay make my site WCAG compliant? +
No. The FTC fined accessiBe USD 1 million in January 2025 for misleading marketing about overlay-based compliance. Overlays do not fix the underlying code; they layer JavaScript on top, often making things worse for users of assistive technology.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Accessibility
### WCAG 2.1 vs 2.2: which version applies to me?
WCAG 2.2 is the current standard. EAA cites EN 301 549 which cites 2.1. ADA case law cites 2.0 and 2.1. AODA mandates 2.0. The standard and the law are not the same in 2026, and the gap matters.
- Multi-jurisdiction
### What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.

---

## What is a website compliance audit? A practical guide for SMBs
URL: https://veracly.app/blog/website-compliance-audit
Published: 2026-04-27

Multi-jurisdiction
# What is a website compliance audit? A practical guide for SMBs
A website compliance audit checks accessibility, privacy, and tracking practices against the laws that apply where your visitors live. Here is the practical version for small and medium businesses.
By Veracly Compliance Team · 2026-04-27· 8 min read
If you run a small or medium business with a website, the rules you have to follow have multiplied in the last five years. Accessibility laws now reach private companies in the EU, UK, US, Canada, and Australia. Privacy regulators have shifted from warning letters to fines that scale with revenue. Cookie consent enforcement, once an EU-only headache, now appears in California, Colorado, Connecticut, Texas, and a growing list of states.
A website compliance audit is how you find out whether your site actually meets the laws that apply to it. This article walks through what the audit covers, how to run one without burning weeks of consultant time, and what an SMB should actually fix first.
## What a compliance audit actually checks
There is no single global law called “website compliance.” The audit is a checklist drawn from the regulations that apply wherever your visitors live. For most SMBs operating in the EU, UK, or US, the four checklists below cover 90% of real-world risk.
### 1. Accessibility
The working target is WCAG 2.1 Level AA , but which law points at which version is worth getting right. The European Accessibility Act (in force from 28 June 2025) reaches WCAG 2.1 AA through the harmonised standard EN 301 549. The AODA mandates WCAG 2.0 AA , not 2.1 (O. Reg. 191/11 s. 14, excluding success criteria 1.2.4 and 1.2.5). The UK Equality Act 2010 names no technical standard at all; WCAG 2.1 AA is binding on the UK public sector through the 2018 accessibility regulations, and private-sector claims are settled against it by practice, not by statute. And ADA Title III adopts no standard either, the US Department of Justice’s April 2024 rule fixed WCAG 2.1 AA for Title II public entities only. Building to 2.1 AA clears all four, which is why it remains the sensible target.
An automated scan catches the machine-testable part of WCAG, conventionally put at roughly a third of the success criteria: colour contrast, missing alt attributes, broken form labels, unnamed links and buttons, missing page language, ARIA misuse. It does not catch keyboard traps, focus order, focus visibility, reflow, or whether an alt text is any good. Every Veracly report carries a version-labelled inventory of all WCAG 2.2 Level A and AA criteria, marking each as partly automated, an automated review signal, or not automated, and stating what a person still has to check. A scan tells you whether you have the obvious problems; no scan tells you that you are compliant.
Read more: WCAG 2.1 AA accessibility audit explained .
### 2. Privacy & consent
For EU/UK visitors, consent for non-essential cookies and trackers is required before the script fires. A real consent audit captures network traffic on the very first page load, before the user clicks anything. Banners that say “by using this site you consent” or that drop trackers on page load are the most common failure mode, and the easiest for a regulator to spot.
Read more: What is a GDPR cookie audit?
### 3. Tracking and analytics
Auditors look for tracking pixels (Meta, TikTok, LinkedIn, Google Ads), session recorders (Hotjar, FullStory, Microsoft Clarity), advertising tags, and any tool that sends visitor behaviour to a third party. Each one has GDPR, ePrivacy, and increasingly US state-law implications. The fix is rarely to remove them, it is to load them only after consent and to disclose them honestly.
Read more: Tracking pixel audit: GDPR & ePrivacy .
### 4. Required legal pages
The documents the law expects you to publish and link to:
- Privacy policy that matches what your site actually does
- Cookie policy with a current cookie inventory
- Accessibility statement (mandatory under the EAA from June 2025)
- Imprint / Impressum (mandatory in Germany, Austria, and Switzerland )
- Terms of service if you sell anything
Be clear about which half of that list a scanner can actually settle. Veracly checks whether a privacy policy, an accessibility statement, and an imprint exist and resolve on your own domain, and it flags trackers it observed loading that are named nowhere in your privacy text. It does not read the policy for a controller, a legal basis, or a retention period; it does not compare your cookie table against the cookies we saw set; and it does not check terms of service at all. Those are a human read. We would rather say so than let a green tick imply a lawyer signed off.
## Manual audit vs. continuous scanning
A manual audit by a consultancy typically takes 2 to 6 weeks and costs €5,000, €20,000 for a single SMB site. That is fine for a one-off snapshot, but most compliance regressions happen after the audit, during normal product work. A new third-party widget, a redesigned signup form, an analytics tool added by marketing without telling engineering. Continuous scanning catches these the day they ship instead of months later when the regulator’s letter arrives.
The pragmatic combination is one manual baseline (or a thorough scan) and then weekly automated scans that compare against the previous run. Most SMBs do not need a compliance team; they need a scanner that yells when something breaks.
## What an SMB should actually fix first
If you are starting from zero, do these in order. Most teams can finish the list inside a sprint.
- Stop firing trackers before consent. This is the highest-risk and easiest-to-fix issue. Move every Meta/TikTok/LinkedIn pixel and any non-essential analytics behind a consent check.
- Replace the “by using this site you consent” banner. Replace it with a banner that has equally weighted Accept and Reject buttons. The CNIL and the Garante have both fined for the alternative. The ICO has never fined over banner design, but it does run sweeps and write to sites, most recently the UK top 1,000 in January 2025.
- Fix the top WCAG violations. Colour contrast, missing alt text, form labels, focus states, and keyboard traps. These are the 5 issues that account for the majority of accessibility complaints.
- Publish an accessibility statement. The EAA requires one from June 2025 for in-scope products. Even if you are out of scope, having one signals good-faith effort and helps in any subsequent dispute.
- Update your privacy policy to match what your site actually does. Most SMB privacy policies are a template that bears no relationship to the live site. Regulators check.
## Common mistakes to avoid
Trusting an accessibility overlay. The FTC fined accessiBe USD 1 million in January 2025 for misleading marketing about its overlay widget. Overlays do not create legal compliance. They mask issues at runtime; the underlying code still fails for many users and is still a basis for a lawsuit.
Treating compliance as a US-only or EU-only problem. Most SMB sites today serve visitors from multiple jurisdictions. A scan that only reports against one framework will miss issues that matter for the others.
Auditing once and never again. The most common pattern: a thorough audit, a clean report, six months of routine releases, and a regulator letter. Make the audit part of your release process.
## How Veracly approaches this
Veracly was built specifically for the SMB version of this problem. One scan reports against the EAA, GDPR and ePrivacy, the ADA, the UK Equality Act, and the AODA at the same time. US state privacy laws are not in the engine, and we would rather name the gap than pad the list.
The free scan covers one page , once per email address per rolling seven days. It runs the same analyzers, the same rule packs, and the same scoring as a paid scan, so the findings are real, but it deliberately ships with AI explanations limited to its top three findings, without evidence screenshots or copy-paste remediation, and it is a single snapshot rather than continuous monitoring. Those arrive with a paid plan. Run the free scan at veracly.app and see what your site looks like to a regulator before they look at it for you.
## Common questions
What does a website compliance audit cover? +
A full audit looks at four buckets: accessibility (WCAG 2.1 AA at minimum), privacy and consent (GDPR, ePrivacy, state laws like CCPA), tracking and analytics setup, and required legal pages (privacy policy, accessibility statement, imprint where required).
Is a website compliance audit legally required? +
No regulator mandates the audit itself, but the underlying laws, GDPR, the European Accessibility Act, the ADA, the UK Equality Act, are enforceable today. An audit is the practical way to know whether you are exposed before someone files a complaint.
How often should we run an audit? +
Run a baseline audit once, then continuous scans whenever the site changes. Most SMB compliance issues are introduced during routine releases, a new tracking script, a redesigned form, a third-party widget, not during the original build.
How long does an audit take? +
A scanned audit covering accessibility, cookies, and trackers finishes in minutes. A full manual audit by a consultant typically runs 2 to 6 weeks for an SMB site and costs €5,000, €20,000.
### See where your site stands.
Run a free Veracly scan and get a multi-jurisdiction report, EAA, GDPR, ADA, UK Equality Act, AODA, with copy-paste developer fixes.
Run a free scan
## Keep reading
- Multi-jurisdiction
### Multi-jurisdiction website compliance: one site, many laws
EU, UK, US, and Canadian visitors trigger different laws. Here is the practical playbook for satisfying GDPR, EAA, ADA, UK Equality Act, and AODA with one programme.
- Multi-jurisdiction
### Website compliance in the Netherlands: cookies, GDPR and accessibility
The Netherlands applies the same EU rules as everyone else, but through its own statutes and regulators. The cookie rule is in the Telecommunicatiewet, where the ACM supervises Art. 11.7a itself and the Autoriteit Persoonsgegevens covers the GDPR side, and accessibility is now law under the Implementatiewet.
- GDPR
### What is a GDPR cookie audit? (And how to pass one in 2026)
A GDPR cookie audit checks consent before any non-essential cookie or tracker fires. Here is what regulators actually look for, the failures we see most often, and how to pass.