1. European Accessibility Act (EAA)
The EAA is the main EU accessibility pressure point for many customer-facing digital services, including e-commerce journeys, self-service flows and support interactions. For a website or web service, the practical issue is not only whether the page looks accessible, but whether a buyer can understand, navigate and complete the service with assistive technology and keyboard-only use.
Official title: Directive (EU) 2019/882 of the European Parliament and of the Council of 17 April 2019 on the accessibility requirements for products and services (Text with EEA relevance)
- Accessibility requirements can affect digital service flows, product information, e-commerce paths, customer support and user interfaces.
- Web checks should cover labels, headings, keyboard paths, focus states, error messages, form instructions, contrast and completion blockers.
- Evidence should show the affected URL, the observed barrier, the user impact and a clear remediation task.
Checkable signals:
- Automated accessibility signals from axe/Lighthouse-adjacent checks, labels, headings, focus paths, keyboard traps, contrast and form errors.
- Manual or assisted evidence for buyer-flow completion where the issue depends on interaction order, dynamic widgets or third-party checkout frames.
- Accessibility-statement visibility and unsupported accessibility-compliance claims.
2. General Data Protection Regulation (GDPR)
GDPR is the core EU framework for personal-data processing. On websites, it creates practical review pressure around what data is collected, whether tracking is observable before a valid choice, how evidence is retained and whether the service can explain the technical behavior of analytics, forms and third-party scripts.
Official title: Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) (Text with EEA relevance)
- Website reviews often focus on personal-data collection through forms, analytics, advertising tags, logs and embedded third-party services.
- Technical evidence should separate what was observed in the browser from legal conclusions about lawful basis or controller/processor roles.
- Useful remediation work includes reducing unnecessary collection, documenting observed tracking behavior and keeping evidence-retention boundaries clear.
Checkable signals:
- Visible privacy links near data-collection surfaces, personal-data form fields and public evidence-retention boundaries.
- Observable analytics, advertising, tag-manager and third-party requests before and after consent choices.
- Unsupported privacy-compliance claims such as GDPR-compliant guarantees.
3. ePrivacy Directive
The ePrivacy Directive is the source most directly associated with cookies, terminal-equipment access and consent-banner behavior. For a web property, the practical question is whether non-essential storage and tracking behavior can be observed before, after or without a user choice.
Official title: Directive 2002/58/EC of the European Parliament and of the Council of 12 July 2002 concerning the processing of personal data and the protection of privacy in the electronic communications sector (Directive on privacy and electronic communications)
- Reviews commonly inspect cookies, local storage, pixels, consent banners, CMP events, tag managers and post-choice tracking state.
- A browser-based scan can document observable behavior, blocked resources, script requests and consent-state changes.
- Evidence should state its limits because some consent behavior is hidden behind account flows, region targeting, A/B tests or server-side tagging.
Checkable signals:
- Cookie banner visibility, CMP markers, local storage, cookies and browser requests that appear before a user choice.
- Post-choice tag behavior, dataLayer events and consent-mode-like signals where they are exposed to the browser.
- Screenshots and request evidence that state probabilistic limits for regional, server-side or account-only behavior.
4. Digital Markets Act (DMA)
The DMA applies to designated gatekeepers, but it also affects the wider web because advertising, analytics and platform tools changed how they expect consent and user-choice signals to be sent. Many site owners feel the operational impact through Google, ads, analytics and tag-management setup.
Official title: Regulation (EU) 2022/1925 of the European Parliament and of the Council of 14 September 2022 on contestable and fair markets in the digital sector and amending Directives (EU) 2019/1937 and (EU) 2020/1828 (Digital Markets Act) (Text with EEA relevance)
- For ordinary websites, the practical pressure is usually indirect: platform integrations expect cleaner consent signaling and tag behavior.
- Reviews may look at GA4, GTM, Google Ads, consent-mode-like signals and whether tags behave consistently after a consent choice.
- Evidence should focus on the observable implementation, not on whether the website itself is a DMA gatekeeper.
Checkable signals:
- GA4, GTM, Google Ads and consent-mode-adjacent browser signals where the integration is observable.
- Tag firing before consent or missing consent-state evidence for platform integrations.
- Clear boundary notes that WebRiskOps is checking implementation behavior, not gatekeeper status.
5. NIS 2 Directive
NIS 2 raises cybersecurity-risk-management expectations for essential and important entities. Even when a website owner is not directly in scope, customers and procurement teams can ask vendors to show practical security hygiene and evidence that public web surfaces are monitored and remediated.
Official title: Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2 Directive) (Text with EEA relevance)
- Procurement checks often ask for security headers, vulnerability-disclosure handling, incident-process notes, monitoring and remediation evidence.
- Public web evidence should show current findings, dates, severity, affected URLs and whether remediation or retesting is in progress.
- Vendor-readiness work should avoid claiming formal NIS 2 compliance unless a qualified legal and security audit has established scope and obligations.
Checkable signals:
- HTTPS, HSTS, security headers, cookie attributes, mixed content and browser-exposed trust posture.
- Vulnerability-disclosure, security-contact, incident-process and monitoring evidence links where they are public or supplied by the customer.
- Retest history, issue status and remediation evidence for public web findings.
6. Digital Operational Resilience Act (DORA)
DORA is aimed at digital operational resilience in the financial sector, but SaaS vendors and web-service providers can feel it through customer due diligence. Financial customers may ask for evidence that public services are controlled, monitored, resilient and supported by repeatable risk-management processes.
Official title: Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector and amending Regulations (EC) No 1060/2009, (EU) No 648/2012, (EU) No 600/2014, (EU) No 909/2014 and (EU) 2016/1011 (Text with EEA relevance)
- Customer reviews can request ICT-risk evidence, third-party dependency notes, vulnerability handling, incident-readiness material and recurring monitoring proof.
- A useful evidence pack should connect findings, remediation tasks, retest dates and ownership instead of presenting one-off screenshots.
- For vendors, the practical goal is to answer buyer due-diligence questions with technical evidence while leaving formal DORA classification to legal and compliance teams.
Checkable signals:
- Recurring monitoring evidence, finding history, retest outcomes and issue ownership for customer-facing web surfaces.
- Third-party script, request, dependency and browser-runtime evidence that can support ICT-risk questionnaires.
- Security headers, vulnerability-disclosure notes and evidence folders for financial-sector buyer due diligence.
7. Cyber Resilience Act (CRA)
The CRA introduces horizontal cybersecurity requirements for products with digital elements. For software products and connected services, it increases the need for structured vulnerability handling, dependency awareness, update discipline and security evidence that can survive customer or partner review.
Official title: Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act) (Text with EEA relevance)
- Readiness work can involve dependency inventory, vulnerability evidence, security-update notes, SBOM-adjacent records and product-security hygiene.
- Web-service evidence should distinguish public website checks from deeper product, repository, build and release-process evidence.
- CRA claims must be handled carefully because product classification, conformity assessment and manufacturer obligations are legal and product-governance questions.
Checkable signals:
- Public security posture, vulnerability-disclosure links, update/support statements and product-security claims.
- Customer-supplied dependency, SBOM-adjacent, repository and release evidence when CRA readiness is enabled.
- Unsupported CRA, CE-marking or product-compliance claims that require legal/product-governance review.
8. Web Accessibility Directive (WAD)
The Web Accessibility Directive applies to public-sector websites and mobile applications, and it matters commercially because public-sector buyers and procurement teams often expect vendors to understand accessibility evidence, statements and remediation plans. It is not a universal private-sector website law, but it creates a concrete and checkable accessibility evidence pattern.
Official title: Directive (EU) 2016/2102 of the European Parliament and of the Council of 26 October 2016 on the accessibility of the websites and mobile applications of public sector bodies (Text with EEA relevance )
- Public-sector web content should be accessible and supported by monitoring, statements and remediation routes.
- Vendor and procurement readiness often requires showing how accessibility issues are found, fixed, retested and documented.
- The practical web surface overlaps with WCAG-style checks, accessibility statements and evidence of user-impact remediation.
Checkable signals:
- Accessibility barriers in pages, forms, headings, labels, keyboard paths, focus handling and error messaging.
- Accessibility-statement visibility, link placement and statement freshness where the page exposes those details.
- Retest evidence showing that a reported accessibility blocker was corrected or remains open.
9. Digital Services Act (DSA)
The DSA is most relevant when a web service hosts, intermediates, ranks, recommends, advertises or moderates user or trader content. It should not be presented as a generic rule for every brochure website, but it has checkable surfaces for marketplaces, platforms, directories, user-content services and complaint/reporting workflows.
Official title: Regulation (EU) 2022/2065 of the European Parliament and of the Council of 19 October 2022 on a Single Market For Digital Services and amending Directive 2000/31/EC (Digital Services Act) (Text with EEA relevance)
- A relevant service may need transparent terms, contact and notice routes, complaint flows, trader information, recommender or advertising disclosures and content-reporting workflows.
- Many obligations are conditional on service type, size and role, so the first practical step is to identify whether any observable platform function exists.
- Browser evidence can document visible workflows and missing routes, but it cannot decide legal intermediary status.
Checkable signals:
- Visible terms, support/contact routes, report-abuse or notice-and-action entry points on platform-like services.
- Marketplace or trader-information surfaces, user-content flows, content moderation copy, recommender labels and ad labels where exposed.
- Unsupported DSA compliance claims or platform-duty claims that need legal review.
10. Artificial Intelligence Act (AI Act)
The AI Act is not a generic website requirement. It becomes technically relevant when a site or service exposes an AI chatbot, AI-assisted workflow, automated decision flow, AI-generated customer output or AI compliance claim. In that case, WebRiskOps can check bounded evidence around visible disclosures, fallback behavior, input/output traceability and human-review controls where the customer supplies the workflow context.
Official title: Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence and amending Regulations (EC) No 300/2008, (EU) No 167/2013, (EU) No 168/2013, (EU) 2018/858, (EU) 2018/1139 and (EU) 2019/2144 and Directives 2014/90/EU, (EU) 2016/797 and (EU) 2020/1828 (Artificial Intelligence Act) (Text with EEA relevance)
- The checkable surface depends on an AI feature being declared, observed or supplied as workflow evidence.
- Useful evidence includes purpose, scope, prompt/config version, output trace, human review, fallback copy and sensitive-data exclusions.
- Legal AI-risk classification, prohibited-practice analysis and high-risk-system obligations are outside a browser scan.
Checkable signals:
- AI chatbot, AI-assistant, automated-decision or AI-generated-content disclosures visible in the customer journey.
- Customer-supplied AI workflow evidence: purpose, prompt version, input/output trace, human review, fallback and data-minimization records.
- Unsupported AI Act, AI-safe, unbiased or compliant claims that need legal and governance review.
11. Consumer Rights Directive (CRD)
The Consumer Rights Directive is relevant to e-commerce and distance-contract flows because the buyer journey must make important purchase information visible before commitment. WebRiskOps cannot decide legal adequacy, but it can check whether the browser-visible checkout path exposes the practical signals buyers expect before submitting forms or payment steps.
Official title: Directive 2011/83/EU of the European Parliament and of the Council of 25 October 2011 on consumer rights, amending Council Directive 93/13/EEC and Directive 1999/44/EC of the European Parliament and of the Council and repealing Council Directive 85/577/EEC and Directive 97/7/EC of the European Parliament and of the Council Text with EEA relevance
- Distance-selling flows are sensitive to missing or unclear price, terms, cancellation, refund, identity, support and submit-button context.
- Technical review can focus on what is visible in the checkout and pre-checkout journey, not on a legal conclusion about consumer-law sufficiency.
- Evidence should connect the affected URL, the missing or unclear signal and the point in the buyer flow where risk appears.
Checkable signals:
- Checkout CTA, required fields, refund/cancellation links, terms links, support/contact links and pre-submit clarity.
- Blocked submits, unclear field errors, disabled states and payment-adjacent trust signals.
- Screenshots and DOM evidence around the final action text and nearby policy/support context.
12. Unfair Commercial Practices Directive (UCPD)
The Unfair Commercial Practices Directive is relevant to misleading or aggressive business-to-consumer web patterns. A scanner cannot determine deception as a legal matter, but it can find observable UX patterns and risky claims that deserve review before they become buyer complaints or regulator-facing evidence.
Official title: Directive 2005/29/EC of the European Parliament and of the Council of 11 May 2005 concerning unfair business-to-consumer commercial practices in the internal market and amending Council Directive 84/450/EEC, Directives 97/7/EC, 98/27/EC and 2002/65/EC of the European Parliament and of the Council and Regulation (EC) No 2006/2004 of the European Parliament and of the Council (‘Unfair Commercial Practices Directive’) (Text with EEA relevance)
- Web evidence can surface risky claims, unclear cancellation paths, confusing checkout states, hidden costs, countdown pressure and review/testimonial presentation issues where observable.
- Some patterns require legal judgment, product context or complete user journeys, so automated findings must stay framed as review triggers.
- Remediation work should improve clarity and preserve screenshots before and after the change.
Checkable signals:
- Visible claims that use unsupported legal, compliance, security, privacy, AI or accessibility guarantees.
- Checkout friction, unclear submit states, hidden policy/support routes, pressure copy and claims near conversion points.
- Before/after evidence for revised copy, clearer UI states and safer policy placement.
13. Americans with Disabilities Act (ADA)
The ADA is the central US disability-rights pressure point for many public-facing commercial websites, especially where the site is tied to goods, services, booking, support, accounts or transactions. WebRiskOps can check practical accessibility barriers and evidence, while leaving ADA applicability and legal conclusions to counsel.
Official title: Americans with Disabilities Act of 1990, As Amended
- US accessibility reviews often start with whether a customer can perceive, navigate, understand and complete the digital service.
- WCAG-style evidence is useful even when a final ADA legal position depends on jurisdiction, business type and facts.
- A finding should show the affected element, user impact, URL, screenshot or DOM evidence and a concrete fix task.
Checkable signals:
- Accessible names, labels, headings, focus order, keyboard operation, contrast, form errors and blocked customer actions.
- Accessibility-statement visibility and unsupported ADA/WCAG/accessibility-compliant claims.
- Retest evidence for corrected barriers in the same flow.
14. Section 508 of the Rehabilitation Act
Section 508 matters when a website, software product or vendor deliverable is developed, procured, maintained or used by US federal agencies. Even for non-federal vendors, it creates practical procurement pressure around accessible ICT evidence and repeatable remediation records.
Official title: Revised 508 Standards and 255 Guidelines
- The practical web surface overlaps heavily with accessibility testing, public-facing content, documents, software UI and support documentation.
- Procurement workflows often need evidence that accessibility defects are tracked, fixed and retested.
- A vendor should avoid claiming Section 508 conformance unless the proper procurement and conformance review has been completed.
Checkable signals:
- WCAG-adjacent web accessibility signals and user-flow blockers in public-facing web content.
- Accessibility statement, VPAT/ACR-adjacent evidence references and support-documentation paths where supplied.
- Unsupported Section 508 or WCAG conformance claims that need procurement or accessibility review.
15. California Consumer Privacy Act (CCPA/CPRA)
CCPA, as amended by CPRA, is the US state privacy framework most likely to create visible website obligations for consumer privacy notices and opt-out routes. WebRiskOps can check visible privacy-choice surfaces and claims, but cannot decide whether the business is in scope or whether the notice text is legally sufficient.
Official title: TITLE 1.81.5. California Consumer Privacy Act of 2018 [1798.100 - 1798.199.100]
- Public web checks can look for privacy policy links, Your Privacy Choices, Do Not Sell or Share, opt-out and sensitive-personal-information routes.
- The check should be triggered by California privacy claims, CCPA/CPRA mentions, privacy-choice links or customer-declared California consumer coverage.
- Browser evidence should state whether the link or route was visible, not whether the legal notice satisfies the statute.
Checkable signals:
- Visible privacy policy, Your Privacy Choices, Do Not Sell or Share, opt-out and Limit the Use of My Sensitive Personal Information links.
- California privacy, CCPA, CPRA and sensitive-personal-information mentions without a visible privacy-choice route.
- Unsupported CCPA/CPRA compliance claims that need privacy review.
16. Federal Trade Commission Act (FTC Act)
The FTC Act is a US foundation for unfair or deceptive acts or practices. For websites, the checkable surface is not a legal verdict; it is the evidence that public claims, privacy/security statements, subscription flows, checkout copy and user-visible promises are clear enough to route into review before they become risk.
Official title: Federal Trade Commission Act, 15 U.S.C. §§ 41-58, as amended
- Website evidence can flag risky security, privacy, AI, accessibility, health, finance or compliance claims.
- Checkout and subscription surfaces can be reviewed for unclear action text, missing support paths, confusing cancellation context and hidden policy links.
- Security and privacy claims should be backed by technical evidence or reviewed before publication.
Checkable signals:
- Unsupported public claims such as fully compliant, certified, HIPAA compliant, ADA compliant, secure, AI-safe or privacy-safe guarantees.
- Checkout, form, subscription, cancellation, refund and support visibility around conversion points.
- Security headers, trust evidence and policy-link placement that support or contradict public trust claims.
17. Children's Online Privacy Protection Rule (COPPA Rule)
COPPA is relevant when a site or online service is directed to children under 13 or has actual knowledge it collects personal information from children under 13. A generic website scan cannot establish audience targeting, but it can identify visible children-directed signals, child privacy claims, data-collection forms and missing privacy notice routes for review.
Official title: Children's Online Privacy Protection Rule ("COPPA")
- The practical check starts only when children-directed content, COPPA claims, child-account flows, age gates or customer-declared child audience context exists.
- Observable evidence can include privacy links, forms, account creation, age fields, parental-consent copy and child-directed language.
- Legal determinations about actual knowledge, audience targeting and parental consent are outside a browser scan.
Checkable signals:
- Children under 13, COPPA, parental consent, kid account, age gate or child-directed copy near data collection.
- Visible privacy policy and child privacy routes on pages that appear to collect user or account data.
- Unsupported COPPA-compliant or child-privacy guarantee claims.
18. GLBA Safeguards Rule
The GLBA Safeguards Rule is relevant for financial institutions under FTC jurisdiction and customer-information handling. A public web scan cannot review an information-security program, but it can support readiness by checking public security posture, risky financial-data collection surfaces, policy links and evidence packs for financial-services buyer review.
Official title: 16 CFR Part 314 -- Standards for Safeguarding Customer Information
- Full GLBA Safeguards work depends on internal administrative, technical and physical safeguards, not only a website.
- The public web layer can still produce useful evidence about TLS, headers, cookie attributes, mixed content, forms, third-party scripts and security claims.
- Findings should be framed as technical hygiene and questionnaire support, not as proof of a compliant safeguards program.
Checkable signals:
- HTTPS, HSTS, security headers, cookie attributes, mixed content and third-party scripts on financial-data surfaces.
- Visible privacy/security links, customer-information claims and unsupported GLBA or financial-data security claims.
- Customer-supplied evidence folders for vulnerability handling, monitoring, dependency review and remediation history.
19. HIPAA Security Rule
The HIPAA Security Rule is relevant to covered entities and business associates that create, receive, maintain or transmit electronic protected health information. A public web scan cannot determine HIPAA status or review safeguards, but it can identify public technical hygiene, health-data collection surfaces, PHI/ePHI claims and evidence gaps for health-sector review.
Official title: The Security Rule
- HIPAA Security Rule readiness depends on administrative, physical and technical safeguards beyond public website behavior.
- The public web layer can still check browser-exposed security posture, forms that appear to collect health data, third-party scripts and risky HIPAA claims.
- Findings should route to security/privacy owners with clear evidence and a legal boundary.
Checkable signals:
- HTTPS, HSTS, security headers, cookie attributes, mixed content and third-party scripts on health-data or patient-intake surfaces.
- Visible health-data, PHI/ePHI, HIPAA, patient intake or portal claims near data collection.
- Unsupported HIPAA-compliant, HIPAA-certified or health-data security claims.
